# STM32F4 clock behaves very strangely

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)
{
gpio_initialize();
//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.");
CAN_init(CAN_PINS_GPIOA);
int i = 0;
//char msg2[512];
/**
*  IMPORTANT NOTE!
*  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.
*  SCB->VTOR register.
*  E.g.  SCB->VTOR = 0x20000000;
*/

/* 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++);
//gpio_toggle_output(GPIO_MCU_OK);
CAN_transmit(msg);
gpio_toggle_output(GPIO_BMS_ERR_LED);
gpio_toggle_output(GPIO_CUR_OK);
gpio_toggle_output(GPIO_UART_OK);
}
}


pastebin.com/sf1FM9T7 - gpio.h

pastebin.com/rqiBTQ4c - gpio.c

pastebin.com/xE6zcPEg - can.h

pastebin.com/DSTHMRcz - can.c

Video of behaviour

• 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. Feb 18 '16 at 12:19
• 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. Feb 18 '16 at 13:31
• 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. Feb 18 '16 at 14:04
• 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. Feb 18 '16 at 15:04
• For debugging, consider enabling a clock output pin so that you can measure the system clock directly instead of relying on possibly erroneous code. Feb 18 '16 at 15:26