2024-12-09 12:14 AM - last edited on 2024-12-09 1:45 AM by Andrew Neil
Hello,
While debugging STM32H5 SPI2 (slave and master) in receive mode, the debug suddenly stopped and somehow I can't work in debug again.
Solved! Go to Solution.
2024-12-11 9:08 PM - edited 2024-12-11 9:15 PM
Hello,
I tried another debugger (J-Link) and it worked, then I tried connecting with ST-Link V2 again and it worked too.
Thanks to everyone who tried to help.
2024-12-09 1:27 AM - edited 2024-12-09 1:59 AM
You're going to need to give a lot more detail for anyone to be able to help!
See the Posting Tips:
@redsire wrote:the debug suddenly stopped
What debugger (software & hardware) were you using?
What is your target hardware?
What, exactly, were you doing before it "stopped"?
What, exactly, happened? Were there error messages? Was there smoke?
@redsire wrote:somehow I can't work in debug again.
So what, exactly, does happen when you try to debug?
Can you debug any other target(s)? Can you load other firmware?
Have you reset and/or power-cycled the target before trying again?
2024-12-09 1:50 AM
> You're going to need to give a lot more detail for anyone to be able to help!
Correct.
"Doesn't work anymore" contains nothing to really work with.
I would suspect a core lock-up, due to a faulty exception handler.
2024-12-09 4:32 AM
I'm sorry its my mistake, i should to give a lot more detail.
What debugger (software & hardware) were you using? I'm using IAR Embedded Workbench IDE 9.40 and ST-LINK V2
What is your target hardware? My target hardware is NXP MKM34Z256VLL7. I tried ST as master and also ST as slave but I got the same problem in receive mode in both.
What, exactly, were you doing before it "stopped"? In the last one, I put the code 'DATA_TransferCompleteRx();' in the comment line of the DMA interrupt and tried to restart the debugger. Details below:
void DATA_TransferCompleteRx(void) {
LL_SPI_DisableDMAReq_RX(DATA_SPI);
LL_DMA_DisableChannel(GPDMA1, LL_DMA_CHANNEL_0);
LL_SPI_Disable(DATA_SPI);
if(LL_DMA_IsActiveFlag_TC(GPDMA1, LL_DMA_CHANNEL_0)) {
LL_DMA_ClearFlag_TC(GPDMA1, LL_DMA_CHANNEL_0);
}
LL_DMA_DisableIT_TC(GPDMA1, LL_DMA_CHANNEL_0);
//LL_SPI_EnableIT_EOT(DATA_SPI);
gRxCompleted = true;
LL_SPI_Enable(DATA_SPI);
for(uint8_t i = 0; i < 4; i++) {
DATA_Send(gTxBuffer[i]);
}
}
What, exactly, happened? Were there error messages? Was there smoke? The error massage: "Target is running, Failed to stop the target. Maybe the target needs to be reset. Try again?"
So what, exactly, does happen when you try to debug? If i try again debug ?? It freezes in busy mode until I press the cancel button and when i press cancel the same massage coming: "Target is running, Failed to stop the target. Maybe the target needs to be reset. Try again?"
Can you debug any other target(s)? Can you load other firmware? Yes, i can debug MKM or another ST mcu in another project.
Have you reset and/or power-cycled the target before trying again? I did try pulling the BOOT pin to HIGH.
2024-12-09 5:10 AM
I don't know the H5, to put this upfront. Although I think this is not especially significant.
Trying to wrap my head around this issue and code ...
> In the last one, I put the code 'DATA_TransferCompleteRx();' in the comment line of the DMA interrupt and tried to restart the debugger.
void DATA_TransferCompleteRx(void) {
...
DATA_Send(gTxBuffer[i]);
...
}If I got that right, you trigger interrupt-driven transfers from within an interrupt handler.
Which doesn't strike me as a good idea.
Have you tried to observe the realtime SPI bus signals involved with a scope / logic analyser ?
If so, seems the code to "freeze" at about the same location ?
> My target hardware is NXP MKM34Z256VLL7. I tried ST as master and also ST as slave but I got the same problem in receive mode in both.
Are both MCUs on the same board & power supply ?
In other words, have you ruled out an electrical issue ?
2024-12-11 9:08 PM - edited 2024-12-11 9:15 PM
Hello,
I tried another debugger (J-Link) and it worked, then I tried connecting with ST-Link V2 again and it worked too.
Thanks to everyone who tried to help.
2024-12-13 12:03 AM
Some (or most) SWD/JTAG debug pods have the capability to supply power to the debuggee.
Check this option is not enabled, unless you really want to use it.
We’re moving the ST Community to a new platform to give you a better and more reliable community experience.