SRAM2 read error from DAP in STM32L496

[IIvan.22]

When reading SRAM2 memory in STM32L496 using ST-Link V2 debug probe, incorrect values are received when read crosses 1k (1024 bytes) boundary. For example, when I try to read 32 bytes starting from 0x100003F0, last 16 bytes that start from 0x10000400 will be incorrect. Multiple reads from the same location return same (incorrect) values.

Reading other memories - for example flash memory - with the same probe, do not have such issue.

 

[Peter BENSCH]

I have just tested a board with the STM32L496 on it and found no problems.

• What software did you use to read SRAM2?
• Can you upload a photo of the ST-LINK/V2, preferably with front and back?

Regards
/Peter

[IIvan.22]

> What software did you use to read SRAM2?

I used libusb and stlink from github. It boils down to calling _stlink_usb_read_mem32. Originally was 2022 version, then updated to latest 2024 without any difference in results.

> Can you upload a photo of the ST-LINK/V2, preferably with front and back?

Please see attachments. I bought few from Digikey and ST directly once they become available on the market; I believe they are original. Firmware is of course the latest.

Other details:

1. The error read value happens only if I use fast reads at SWD clock 1.8MHz. When I reduce SWD to 125kHz, no errors. I don't think it is a line noise as the error value is the same after multiple reads. When I read from STM32H743 ETF buffer at same 1.8MHz speed and same hardware, no such errors.

2. Errors happen not only when I cross 1k boundary. I split reads so they don't cross 1k, but errors still happen. It is about 1 out of 1000 32-bit words that are wrong. Instead of giving me SRAM value, it often gives me 0xF000F85F.

3. STM32L496 core and bus clocks are all 64MHz.

4. A sort of similar problem was with STM32H743 when buses were running at 24 MHz and heavy DMA from USART to SRAM. But at that time I was reading internal 4k ETF buffer. Changing bus clocks to 200MHz reduced the errors.

5. There is a work around for the problem to reduce SWD clock to 125 kHz. Anyway, it is a development phase, not the production issue. But my big, big concern is: if STM32L4 bus will become loaded with legitimate production traffic, will be there a chance of such errors, say between core and peripherals, silently happening?  

[Peter BENSCH]

Thanks.

If you do not necessarily have to use an ST-LINK/V2 ISO, you could also check the behaviour with a non-isolated ST-LINK. The cable length between ST-LINK and target also plays a very important role.

You can also check the behaviour with the STM32CubeProgrammer to rule out software problems.

If you mean errors between the core and internal peripherals with your last question, I can completely reassure you - the STM32s are used in annual quantities of billions, so something like this would have been noticed long ago.

Regards
/Peter

[IIvan.22]

Is there any documentation for the protocol between ST/LinkV2 device and the host computer? If there is a software error then with the documentation I will fix it. Will benefit others too.