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.
Thanks for the help.
Solved! Go to Solution.
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.
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).
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.
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!
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.