STM32 UART stops receiving after writing w. SPI to FRAM

[Stefan Meyre]

Posted on December 04, 2017 at 08:30

Hello everybody,

I do use UART on a STM32F405 just fine (receiving and transmitting).

(while (HAL_UART_Receive_DMA(&huart4, receiveBuffer, UARTRECEIVEDBUFFERSIZE) != HAL_OK);)

.

Now I added an external FRAM (FM25V02A) to my circuit and use SPI to read and write to it. Reading works fine. But after writing to the FRAM (transmit completes, data is stored away) the UART does no longer receive data !? The UART however still transmits data like before.

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) {...}

The interrupt callback is not going to be fired anymore.

This is how I do write to the FRAM.

opcodeWREN[0] = 0b00000110; opcodeWRITE[0] = 0b00000010; HAL_GPIO_WritePin(GPIOC, GPIO_PIN_1, GPIO_PIN_RESET); //chip select HAL_SPI_Transmit(&hspi2, opcodeWREN,1,5); HAL_GPIO_WritePin(GPIOC, GPIO_PIN_1, GPIO_PIN_SET); HAL_GPIO_WritePin(GPIOC, GPIO_PIN_1, GPIO_PIN_RESET); HAL_SPI_Transmit(&hspi2, opcodeWRITE,1,5); HAL_SPI_Transmit(&hspi2, sendFRAMBufferByte,240,5); //transmitting 240byte of data HAL_GPIO_WritePin(GPIOC, GPIO_PIN_1, GPIO_PIN_SET);

I did have the same problem writing with I2C to an EEPROM.

Whats going on? Any ideas what I should look at? Thanks! Stefan

#uart #stm32 #hal_i2c_mem_write #fram #fm25v02a

[Tesla DeLorean · Accepted solution]

Posted on December 26, 2017 at 22:10

The USART and SPI peripheral are unrelated.

Watch for code blocking or jamming in the CallBack (interrupt context). The interrupt will keep reentering if the source is not properly cleared, other lower priority code and foreground code will not execute.

Check what code is getting executed. Check for error paths where commands fail. Check peripheral states in debugger. Check interrupt priority and preemption levels.

[Stefan Meyre]

Posted on December 27, 2017 at 17:21

Thx Clive. I was too much focusing on interrupt priorities and preemption issues, that I did not see (the most obvious) a blocking code in the data input parser. The data send to the UART in combination with the 'store to fram' command did block the parser. Your answer helped me to look into an other direction... Thank you.

[Matthew Staben]

Posted on January 02, 2018 at 17:31

My platform on a custom STM32F769II uses SPI FRAMs as well as I2C FRAMs and operates six UARTs, ethernet, all simultaneously without error, using HAL.  Only change to HAL was in the ethernet so I know the UART handling code in the HAL works (very) well without modification!

The trick is to use a circular RX DMA channel on the UARTs.  Set it to callback on a single receipt, store the character in whatever buffer you like - resetting the Receive_IT ( ).  Process the buffer in a subroutine of your making.

In short, the HAL UART code works fantastically with RX Circular DMA - all six channels hammering at various baud rates using common callback functions (Receive_IT and Transmit_IT) that handle all the UART interrupt processing.