STM32H723 - SPI stop working randomnly

[rdelarosa]

Hi people,

Im working on STM32H723 module and using SPI6 with LL and/or registers. Even when using HAL libraries I have same issue. SPI stops working randomly

I need to send several messages every (e.g.) 25 ms, (I tried 50 ms). Main Clock is set to max speed, 550 MHz, SPI 6 clock is 137.5 MHz and using a clock divider of 16 it downs to 8.6 MHz

Two timers running, 1 ms ( run time tracking) and 25 ms (used for SPI6)

No other peripheral is active in this experiment (I have a bigger code with several peripherals enabled but run into SPI problems so I decided to test SPI only in this experiment)

This is SPI TxRx function

SPI is working in 8-bit mode. This function is called for every byte that needs to be transmitted. For example, a packet of 10 bytes will call this function 10 times. There are faster ways of doing that, I agree. For now, Im debugging SPI peripheral problems. Initialization of SPI is the one provided by IDE Init function. Basic one, no need to go deep into this section. Cache D and I is also disabled

It transmits bytes one-by-one. After reading errata info one of potential workaround is to enable/disable SPI. As you can see, it does that but issue is still present. This code is working fine for x amount of time (logic analyzer evidence) and then suddenly it goes stuck somewhere. I have a LED to toggle at TIM interruption (25 ms) to have a visual evidence SPI is working. When SPI fails, LED remains in last state (on or off)

As also, I added a delay after CSTART is set. Not working as well

I tried to add a while loop until EOT is set to one. This is causing nothing to transmit. Maybe it is at wrong line of code. But so far it is commented out

SPI is a basic peripheral, so I need this to move on

Have you guys found the solution to this problem?

[TDK]

You're writing 32-bits into TXDR, not 8, which is no double the source of a lot of issues. And also reading 32 bits from RXDR. There is a FIFO. LL has a function to send 8 bits use that or copy what they're doing, or what HAL is doing.

[rdelarosa]

First, thank you for your time

Now, we can notice there is an (uint8_t) typecast

SPI6->TXDR = (uint8_t)( *lp_tx_data ); <== we are loading 8 bits only

same is for reading

l_dummy = (uint8_t)SPI6->RXDR;

do you think this is the incorrect way?

even that, this code works for some amount of time and then something happen. Still I can not find where it goes (lack of lab equipment)

I can see this is going crazy cuz I have an SPI display/TFT which need to send data @ 25 ms

sometimes it works for some seconds, sometimes for some minutes

I have disabled everything to isolate problem to SPI communication

[TDK]

The (uint8_t) cast isn't doing anything useful in your code in that spot. See how it's done in the LL library:

__STATIC_INLINE void LL_SPI_TransmitData8(SPI_TypeDef *SPIx, uint8_t TxData)
{
  *((__IO uint8_t *)&SPIx->TXDR) = TxData;
}

The byte-access instruction is created by modifying the pointer, not the data.

[rdelarosa]

I got your point, thanks for clarification

I have updated source code to use either LL or whatever is in LL function as follow;

As additional info, these are interrupt priorities

I see pretty much same behavior. SPI does something weird

I have tried using HAL, LL and registers for this problem

Originally, HAL libraries were used until I observed this issue. Then I tried LL ones with same problem. Now using registers is same story

If you remember, I have an LED toggling at TIM interrupt (every 25 ms)

When SPI/TFT stop refreshing, there is no LED activity (TIM interrupt problem???). Some time later, LED is toggling again, SPI apparently comes to life (maybe is a MCU reset) and TFT is back (new "image" is loaded) to life but with incorrect data (maybe initialization was lost, display shows weird data/image)

Even more, if there is only one TIM enabled (no other TIM or peripheral is enabled), same behavior. One Timer, @ 25ms, SPI6 and two LEDs, nothing else

[TDK · Accepted solution]

> Originally, HAL libraries were used until I observed this issue. Then I tried LL ones with same problem. Now using registers is same story

So maybe the SPI code isn't the issue. Have you done any debugging to isolate when the problem happens? If SPI is "not working" you can debug and pause the code at that point to understand why. It should not be a guessing game. At a minimum, if you expect SPI should be transmitting but it is not, examining the SPI registers along with where code execution is at should help you understand why.

I feel the underlying issue is probably in a part of your code that you are not showing. The SPI is not known to start and stop working randomly. This suggests something else is the problem.

Perhaps create a UART debug stream or have some other information for getting information out. If your chip may be resetting, output information at startup which would help you understand why.

Simplify the code by taking out portions until you have a minimal example which shows the problem. Then work to debug, understand, and fix the underlying issue there.

[rdelarosa]

Thanks for those fresh ideas

I unplugged SPI display to see SPI traffic/packets. This is to even isolate even more the problem

I noticed SPI and TIM (25 ms) is working perfect. Software is working fine, SPI driver is working fine and TIM interrupt is working fine. So this points me to hardware, harness or something else

I haven't explored this scenario yet but your suggestion is what I needed

By using logic analyzer and doing analysis of SPI packets (byte-by-byte) I found evidence everything is working good

Thanks for your fresh ideas, sometimes happens that you are stuck and need some easy advice like yours

[rdelarosa]

Thanks TDK... your ideas and suggestions are valuable

By replacing damaged IDC cable, everything is working good.

Code was not the problem. SPI is not the culprit (with fixes as errata document suggests). TIM is not the culprit. Application is not the problem

I dont recall when was last time I had an harness problem but something to keep in mind

Either of these 3 options is working as expected. You and I were ok with any of these ones

ret_val = (uint8_t)SPI6->RXDR;

//ret_val = (*((__IO uint8_t *)&SPI6->RXDR));

//ret_val = LL_SPI_ReceiveData8(SPI6);