STM32H563 Debug mode stopped working

redsire · ‎2024-12-09

Hello,

While debugging STM32H5 SPI2 (slave and master) in receive mode, the debug suddenly stopped and somehow I can't work in debug again.

Andrew Neil · ‎2024-12-09

You're going to need to give a lot more detail for anyone to be able to help!

See the Posting Tips:

https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/ta-p/575228

@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?

Ozone · ‎2024-12-09

> 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.

redsire · ‎2024-12-09

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.

Ozone · ‎2024-12-09

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 ?