STM32F769 DISCO with FatFS SD makes UART5 and 7 unusable

[Joerg Wagner]

Posted on January 11, 2018 at 23:24

I use CubeF7 1.8.0 and the BSP drivers for SD support. Working (reading and writing files) with SD card is fine.

After initializing SD with:

static void SD_Initialize(void)

{

  if (isInitialized == 0)

  {

    if (BSP_SD_Init() == MSD_OK)

    {

      BSP_SD_ITConfig();

      isInitialized = 1;

    }

    else

    {

      /* wait until the uSD is plugged */

      while (BSP_SD_IsDetected() != SD_PRESENT) {}

    }

  }

}

UART5 and UART7 are not usable anymore.

Interrupt does not occur anymore and even a simple

    HAL_StatusTypeDef  hscs = HAL_UART_Receive(&huart5, rxdata, 10, 0x1000);

ends with HAL_TIMEOUT. (A 2nd board sends a string continously)

I also omitted 4 Bit SD, just for testing.

When I make my SD stuff, i.e. reading a config file and then calling

    BSP_SD_DeInit();

UART5 and UART7 can properly used, with IT or without.

UART6 for instance is not affected by the SD functions.

Other UARTs are not accessible with STM32F769-DISCO, so I don't know if they work or not.

The goal is an application with SD, 3x UARTs, STEmWin, Ethernet. Everything works nice except the

combination of SD and UART5/7.

Any idea?

Thank you, Joerg

#uart5 #uart7 #sd #bsp #stm32f769-disco

[Tesla DeLorean]

Posted on January 12, 2018 at 00:31

NVIC Interrupt Grouping and Preemption?

Mindless blocking in interrupt/callback routines?

With HAL you really want SysTick to preempt everything

Next level down USART, service and leave.

If the SDIO/SDMMC is simply flagging completion, or error, it doesn't need to preempt more time critical code.

[Joerg Wagner]

Posted on January 12, 2018 at 01:25

 ,

 ,

Hi Clive.

I use no FreeRTOS and using a plain

HAL_StatusTypeDef , hscs = HAL_UART_Receive(&,huart5, rxdata, 10, waiting),

returns with a HAL_TIMEOUT, no interrupts are used in this case.

Baudrate is 4800 only!

When I initiate the mechanism with

 , , , HAL_UART_Receive_IT(&,huart7, &,rx7_ch, 1),

 ,

 , ,  ,HAL_UART_Receive_IT(&,huart6, &,rx6_ch, 1),

 ,

 , ,  ,HAL_UART_Receive_IT(&,huart5, &,rx5_ch, 1),

it works with interrupts unless SD is activated. Priorities of SD and UART Interrupts are different.

Pins of UARTs:

♯ define UART5_RX_Pin GPIO_PIN_9

 ,

♯ define UART5_RX_GPIO_Port GPIOB

 ,

♯ define UART5_TX_Pin GPIO_PIN_8

 ,

♯ define UART5_TX_GPIO_Port GPIOB

♯ define UART7_RX_Pin GPIO_PIN_6

 ,

♯ define UART7_RX_GPIO_Port GPIOF

 ,

♯ define UART7_TX_Pin GPIO_PIN_7

 ,

♯ define UART7_TX_GPIO_Port GPIOF

There is no collision with SD pins noticeable.

No SD=No Problems

[Tesla DeLorean]

Posted on January 12, 2018 at 02:12

Does it corrupt the data, do the USART give an overrun or framing type error, or just time out?

If things are timing out it is indicative of some blocking code, perhaps in interrupt context (ie call back, theirs or yours)

Assume 0x1000 is around 4 seconds, so should be enough time, wouldn't expect SD code to block for that long unless reads/write are being chained endlessly, or the SD card traffic is being generated in an interrupt.

Not sure there are any design conflicts that would cause the hardware not to function properly.

[Joerg Wagner]

Posted on January 12, 2018 at 17:57

To initiate the UART reading via Interrupt you have to clear Overrun and Timeout flag

if incoming data fills up the receiver:

    __HAL_UART_CLEAR_IT(&huart7, UART_CLEAR_OREF|UART_CLEAR_NEF|UART_CLEAR_RTOF);

    HAL_UART_Receive_IT(&huart7, &rx7_ch, 1);

    __HAL_UART_CLEAR_IT(&huart5, UART_CLEAR_OREF|UART_CLEAR_NEF|UART_CLEAR_RTOF);

    HAL_UART_Receive_IT(&huart5, &rx5_ch, 1);

There is no relationship between SD and UART functions. Side-effect.