cancel
Showing results for 
Search instead for 
Did you mean: 

SPI debugging stops after around 125 bytes being send

johantheking
Associate II

Hi STM forums,

I use a stm32f205rct6tr for this project

in my project i need to send 1024 clock signals to the slave, the message inside is not inportant.

but after sending around 125 bytes it stops debugging entirely, i checked it out with the oscilloscoop. And i'm not sure why it can't send more. plz take a looks at the screenshot and if there is more information needed let me know.

 

Screenshot_159.pngScreenshot_160.pngScreenshot_161.png

 

Thanks for the help.

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
johantheking
Associate II

To everyone,

The isSue has been solved. i had used the ST-LINK V2 that was not a original product from ST (see picture). I have recently bought the ST-LINK V3SET and all of the problems that caused the debug to crash have been resolved.

 

Once again thank you everyone for your suggestions on how to solve it.

 

Johan

 

View solution in original post

10 REPLIES 10
TDK
Guru

1024 bytes is a lot for the stack. Might want to define that as a global variable, or to ensure you have defined enough stack space in the linker file (_Min_Stack_Size variable).

If you feel a post has answered your question, please click "Accept as Solution".

Perhaps it stalls or underflows because you're debugging. Don't park a peripheral view over an active peripheral that clears registers, or has a FIFO.

SPI is driven by output, not input. Use Transmit or TransmitReceive methods.

Use a static buffer, not a local/auto variable.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Combining what both gentlemen have contributed, you don't need ontvangenbuffer[] at all.  You mentioned the data content of your SPI frame doesn't matter, only the SPI clocks.  So definitely use HAL_SPI_Transmit() but since the data doesn't matter the address of the buffer passed to ..._Transmit() can be *any* address, e.g., the base of RAM.  Don't forget to include a very descriptive comment!

Try  bitbanging the SPI.

JW

johantheking
Associate II

Hi everyone,

I would like to thank everyone in this conversation for there suggestions on how to fix this issue. Unfortunately none of them worked. but while i was digging deeper to find where it caused the problem, i found out that after sending 125 bytes, in the file stm32f2xx_hal_spi.c the program keeps looping forever between line 1272 to 1307, check the picture pls. If there are anymore suggestions let me know.

 

Screenshot_162.png

 

Johan

Note, what @Tesla DeLorean said above:

Perhaps it stalls or underflows because you're debugging. Don't park a peripheral view over an active peripheral that clears registers, or has a FIFO.

JW

Check what's flagging when it gets stuck in the loop. Seems to assume RXNE / TXE and not any potentially for error / failure conditions.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

it appears to be that the RXNE is constantly enable in a loop, any idea on how to fix this, or what it may cause to be stuck on this loop?

> SPI_DIRECTION_2_LINES

I don't use Cube, does this mean Bidir or Rx-only modes of SPI? If yes, don't use them.

JW