SPI debugging stops after around 125 bytes being send
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-12 09:26 AM
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.
- Labels:
-
SPI
-
STM32F2 Series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-22 04:38 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-12 10:11 AM
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-12 10:54 AM
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.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-12 12:32 PM - edited ‎2023-08-12 05:24 PM
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-12 02:11 PM
Try bitbanging the SPI.
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-12 07:00 PM
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.
Johan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-13 12:05 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-13 02:08 PM
Check what's flagging when it gets stuck in the loop. Seems to assume RXNE / TXE and not any potentially for error / failure conditions.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-13 02:43 PM
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-13 11:10 PM
> 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