I can not find a solution for why STM32F427ZIT6 clock changes during operation. I am using external 8 Mhz crystal.

Should I rather look for a error in software or hardware?

I have a little code, which just toggles LEDs on the board with GPIO. Sometimes they are toggled with correct speed, as defined in software. I have seen 3 different speeds, 2 of them are in the video below and the third speed is between them. It is really messed up. And it will happen at random times. Sometimes it's fast when turned on, sometimes slow..

Parameters at the moment for sysclock:

#define HSE_VALUE    ((uint32_t)8000000) 
#define PLL_M      8
#define PLL_N      360
#define PLL_P     2

I also tried to put PLL_P to 4, in order to reduce the clock. Still the same.

EDIT: I measured CAN with logical analyzer and at first it sends data with 1 Mbits as needed, but then drops to 113 kbits when LEDs start to flash slower. CAN is driven by APB1 clock.

EDIT2: I think I may have found the cause of the problem - the crystal. I did not do any changes in code. I desoldered the 8 Mhz crystal and measured CAN and SPI with logic analyzer using internal clock. All the measurings seemed to be OK for many tests so I soldered a new 8 Mhz crystal on the board. So far so good. Have not seen any strange behaviour since.

Full code:

pastebin.com/6jwYFVPB - main.c

/* Includes */
#include "stm32f4xx.h"
#include "gpio.h"
#include "uart.h"
#include "can.h"

UART debug;

/* Private macro */
/* Private variables */
/* Private function prototypes */
/* Private functions */

**  Abstract: main program
int main(void)
    //UART_init(&debug,  USART1_PA9_PA10, 9600, 64, 2048);      //UART variable is defined in debug.h to make it global.
    //uart_putline(&debug, "BMS has started.");
  int i = 0;
  //char msg2[512];
  *  The symbol VECT_TAB_SRAM needs to be defined when building the project
  *  if code has been located to RAM and interrupts are used. 
  *  Otherwise the interrupt table located in flash will be used.
  *  See also the <system_*.c> file and how the SystemInit() function updates 
  *  SCB->VTOR register.  
  *  E.g.  SCB->VTOR = 0x20000000;  

  /* TODO - Add your application code here */

  /* Infinite loop */

  //uart_putline(&debug, "Entering loop:");
    CAN_message msg;
    msg.id = 0x303;
    msg.data_or_request = CAN_RTR_DATA_FRAME;
    msg.standard_or_extended = CAN_IDE_STANDARD;
    msg.length = 8;
    msg.data[0] = 0x00;
    msg.data[1] = 0x01;
    msg.data[2] = 0x02;
    msg.data[3] = 0x03;
    msg.data[4] = 0x04;
    msg.data[5] = 0x05;
    msg.data[6] = 0x06;
    msg.data[7] = 0x07;

  while (1)
//    if (uart_inbox_count(&debug) > 0) {
//          uart_getstr(&debug, msg2);
//          //echo that message back
//          uart_putline(&debug, msg2);
//    }

      for (i=0;i<500000;i++);

pastebin.com/sf1FM9T7 - gpio.h

pastebin.com/rqiBTQ4c - gpio.c

pastebin.com/xE6zcPEg - can.h

pastebin.com/DSTHMRcz - can.c

Video of behaviour

  • 3
    \$\begingroup\$ Why do you think this is a clock issue, and not some code problem? Reduce the issue to its simplest reproducible form, then post code. \$\endgroup\$ Feb 18 '16 at 12:19
  • 1
    \$\begingroup\$ Because I measured CAN with logical analyzer and at first it sends data with 1 Mbits as needed, but then drops to 113 kbits when LEDs start to flash slower. CAN is driven by APB1 clock. \$\endgroup\$
    – Skiller
    Feb 18 '16 at 13:31
  • 1
    \$\begingroup\$ Wouldn't you think that this information might be valuable in understanding and answering the question? I still don't think that your problem is with the clock changing frequency, and CAN isn't my bag, but without code, this is an unanswerable question. \$\endgroup\$ Feb 18 '16 at 14:04
  • 1
    \$\begingroup\$ Instead of just uploading your code, can you reduce it to a minimal implementation that reproduces your issue? Eight times out of ten, that exercise, all by itself, will point you right to a solution for your own problem. Please include what remains in your post as part of your question. \$\endgroup\$ Feb 18 '16 at 15:04
  • 1
    \$\begingroup\$ For debugging, consider enabling a clock output pin so that you can measure the system clock directly instead of relying on possibly erroneous code. \$\endgroup\$
    – uint128_t
    Feb 18 '16 at 15:26

I've also seen strange things happen with MCU clock in STM32F1 and STM32F4 series but only in high count pin configurations like LQFP144 and more. It is likely that your external crystal becomes unstable for some reason and the MCU automatically switches to internal clock. Check the 8MHz crystal pins on oscilloscope to be sure. Try switching to internal oscillator if you dont need much accuracy in your main clock.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.