Debugging with ST LINK V3 aborts when accessing external SRAM via FMC.

[DSaff.1]

Hello all,

I have a very strange problem with Debugging. I am using a STM32H723xx microcontroller for my project. I have some debuggers like ULINK ME, ULINK2, JLINK, ST-LINKV2 and V3. All debuggers show the same issue.

I access the external SRAM via FMC as shown below:

volatile __attribute__((at(0x60000000))) SRAM_DATA sram ;
 
[...]
SRAM_DATA lram;
sram_to_ram ( &lram, &sram, sizeof( SRAM_DATA ) );
[...]
 
static __inline void sram_to_ram ( uint16_t *dst, volatile uint16_t *src, uint32_t size)
{
  while ( size-- )
  {
    *dst++ = *src++;
  }
  __ISB();
  __DSB();
}

The access probably works. I have no problems here. 

The function is called in the interrupt context. It can block for up to 100 µs. 

The cache is active, so I used __ISB() and __DSB(). The MPU settings of the SRAM are set correctly.

I am using Keil V5 IDE for this project. 

When the above code is in my code, after a few seconds I get the following message: 

"Debugger - Cortex-M Error - Cannot access target. Shutting down debug session."

If I comment out line 12. everything works fine. The program runs in debug mode and no access errors occur.

The program also runs without debugger without problems, even if line 12 is there.

What am I doing wrong? Does anyone have the same problem? 

I have tried many things but nothing has helped:

• other debugger
• changed "performance profile" of ST-Link
• Changed debugger clock
• rebuild project and full chip erase
• enabled/disabled debug description
• added SRAM to linker file
• checked MPU settings
• enabled / disabled I-Cache and D-Cache
• Comment the whole program without SRAM access

If I add a delay of 1 ms behind line 12 like that:

  while ( size-- )
  {
    *dst++ = *src++;
    HAL_Delay ( 1 );
  }

everything works fine. But it is not possible for me here to put a delay because of my timing requirements.

Do you have any ideas?

Thanks in advance,

Daniel

[DSaff.1]

One more piece of information. I have checked all signals with an oscilloscope and together with a logic analyzer. These look very good. That can not be the problem. 

[DSaff.1]

To exclude a misconfiguration of the MPU, I mapped the external SRAM from 0x6000 0000 to 0xC000 0000. 

The access works so far. But in the debugger the connection is lost again. That can't be the reason.

In the next step I check the hardware, in order to exclude hardware disturbances.

[DSaff.1 · Accepted solution]

I have found the problem. It was indeed due to the hardware. In the debug line the resistors were wrongly dimensioned.