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