CAN bus issues after extended uptime

[rishabhsareen]

Posted on July 23, 2015 at 16:36

I'm using the STM32F042C6T6 processor as nodes in a CAN bus. Each are attached to aMCP2551T-E/SN CAN transceiver. For the firmware, I am using the HAL drivers provided by ST to transmit/receiveCAN frames. Communication works fine initially and even for many hours. However, after a few hours of uptime one of the nodes is completely unable to write to the bus (consider this the ''master'' node). All nodes have their system clocks set to the HSE, with the same prescalar value, below is the code being used to set the clock:

void
SystemClock_Config(
void
)
{
RCC_OscInitTypeDef RCC_OscInitStruct;
RCC_ClkInitTypeDef RCC_ClkInitStruct;
// set up the oscillators
// use external oscillator (16 MHz), enable 3x PLL (48 MHz)
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.HSI14State = RCC_HSI14_ON;
RCC_OscInitStruct.HSI14CalibrationValue = 16;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL3;
RCC_OscInitStruct.PLL.PREDIV = RCC_PREDIV_DIV1;
clock_setting = HAL_RCC_OscConfig(&RCC_OscInitStruct);
// set sysclk, hclk, and pclk1 source to PLL (48 MHz)
RCC_ClkInitStruct.ClockType = (RCC_CLOCKTYPE_SYSCLK |
RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_PCLK1);
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
clock_setting = HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0);
__SYSCFG_CLK_ENABLE();
}

HSI14 is also enabled because the ADC's are being used on the STM32s. The setup for the HAL CAN drivers is also the same between nodes and occurs in the following two functions:

void
can_init(
void
) {
uint32_t status;
filter.FilterIdHigh = 0;
filter.FilterIdLow = 0;
filter.FilterMaskIdHigh = 0;
filter.FilterMaskIdLow = 0;
filter.FilterMode = CAN_FILTERMODE_IDMASK;
filter.FilterScale = CAN_FILTERSCALE_32BIT;
filter.FilterNumber = 0;
filter.FilterFIFOAssignment = CAN_FIFO0;
filter.BankNumber = 0;
filter.FilterActivation = ENABLE;
hcan.Instance = CAN;
hcan.Init.Prescaler = 48;
hcan.Init.Mode = CAN_MODE_NORMAL;
hcan.Init.SJW = CAN_SJW_1TQ;
hcan.Init.BS1 = CAN_BS1_4TQ;
hcan.Init.BS2 = CAN_BS2_3TQ;
hcan.Init.TTCM = DISABLE;
hcan.Init.ABOM = ENABLE;
hcan.Init.AWUM = DISABLE;
hcan.Init.NART = DISABLE;
hcan.Init.RFLM = DISABLE;
hcan.Init.TXFP = DISABLE;
bus_state = OFF_BUS;
}
void
can_enable(
void
) {
uint32_t status;
if
(bus_state == OFF_BUS) {
hcan.Init.Mode = CAN_MODE_NORMAL;
hcan.pTxMsg = NULL;
status = HAL_CAN_Init(&hcan);
status = HAL_CAN_ConfigFilter(&hcan, &filter);
bus_state = ON_BUS;
}
}

I don't see why the bus runs fine for quite a while before seemingly crashing. The only way to recover full communication is to power cycle the entire bus. I double checked that the clock and bit timing/bitrate settings between all nodes are the same and they are all the same. If anyone has evey had similar issues or knows of something I may be missing in setting up the CAN bus, any help would be greatly appreciated. Thanks #code #stm32 #can #debug

[pmoore]

Posted on August 03, 2015 at 19:47

Rissar:

Have you checked the error and drift of your HSE clock source?  If the HSE clock source is drifting too far away from the ideal value over time (often due to heating,  electrical stress {in the case of an over-driven crystal}, or crystal loading changes {commonly thermal drift on loading caps...+/-0.5pF tolerance (or better) values of NP0 /C0G dielectric type are normally best}), this could happen. I've had very good luck with 2.5mm x 3.2mm and 2.0mm x 2.5mm ''low cost'' 50ppm -40C to 85C 8 MHz oscillator ''chips'' (both crystal & MEMs based types) for STM32F105 based CAN nodes.  (Although at volume STM32F042 prices, 60 to 80 cents for an oscillator source might be too much for a low-cost bill of materials...or draw too much power if your power budget is very tight.)