2024-12-09 12:14 AM - last edited on 2024-12-09 01: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 09:08 PM - edited 2024-12-11 09: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 01:27 AM - edited 2024-12-09 01: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 01: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 04: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 05: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 09:08 PM - edited 2024-12-11 09: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.