UART Glitch On Startup Causes Hardfault in FreeRTOS

Partners & Sponsors ST
6

Jeff,

  1. Went from 1k to 4k+ task stack size. Ozone reports we are about 120 bytes deep into the stack when it hardfaults. No change.

  2. Technically, it’s a FRAMING ERROR due to the lack of stop bit for this guy. DMA processes it as a regular 0 byte. A more clever implementation would find a way to skip past the byte in the DMA buffer. Alas, at this point in the error isr, the null byte is not yet in the DMA buffer.
    I am not sure what else to check on the DMA chain for what it might be affecting.

  3. It is tricky, but the error flags are getting cleared. SR is read in the calling function and DR in the error function. TRM: “The FE bit is reset by a USART_SR register read operation followed by a USART_DR register read operation.”

  4. v10 is dropped in and ported. A few definition tweeks and it worked out of the box. No change. Still hardfaults and no new configASSERT issues to see.

Regarding interrupt priority assignments and preemption priority bits per https://www.freertos.org/RTOS-Cortex-M3-M4.html
I copied from a CORTEX-STM32F407 example FreeRTOSConfig.h from the v10 DEMOs for the priority bits making the following additions/modifications:

  • configPRIO_BITS = 4 // from stm32f4 CM4F example
  • configKERNEL_INTERRUPT_PRIORITY was 255 0xff is now 240 0xf0
  • configMAX_SYSCALL_INTERRUPT_PRIORITY was 191 0xbf is now 80 0x50

Added prior to FreeRTOS init:
NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 ); - no change

Checked that the interrupt priorities are logically lower, numerically higher than the FreeRTOS thread (4):

  • DMA IRQ priority 10 - NVIC_SetPriority(DMA2_Stream2_IRQn, 10);
  • USART IRQ priority 10 - NVIC_SetPriority(USART1_IRQn, 10);
  • TIM2 IRQ priority 12 - NVIC_SetPriority(TIM2_IRQn, 12);

Reading through https://freertos.org/FAQHelp.html reminded me to try this:

portENTER_CRITICAL();
tmp2 = CalcAuth(((uint32_t)crc ^ fbuf->fbufb[i]) & 0xff);
portEXIT_CRITICAL();

As expected, this guard resolves the issue. Why?

Build-wise, this function call CalcAuth() is to a library.

When I trace the hardfault, it does appear to always be at the BL branch asm or similar.

Cheers,
Joe