Program flashed in reverse (MSB LSB)

[PSicl.2]

Hello, I am using an STM32F427ZIT6 on a custom board for my project and it was working perfectly until now. I was able to programming it with an ST-Link V2 + ST-Link Utility as expected.

I was working on adding DMA to my code but one day my chip stopped working and I was unable to flash code in it. In fact, I could flash data to the chip but it was flashing it in reverse order MSB LSB instead of LSB MSB.

I tried updating and changing my ST-Link V2. I also tried using another similar board but I did not encounter the same problem. However, I did had strange behavior when flashing my other board (doesn't boot at start address when after power cycle).

Here is the error message from St-Link Utility (Programming error @ 0x08000000!) :

Here is the error message from STM32CubeProgrammer (Error: Data mismatch found at address 0x08000000 (byte = 0x8D instead of 0x00)) :

Here is the difference between the data flashed in the chip and the data from the binary file I tried to flashed. As you can see the data are in reverse order.

Could you please help me understand what is causing this problem and how to solve it.

Additional details :

I don't know if it is helpful but I was working on DMA at this moment. I was saving large data coming from UART to a single buffer (24KB) to then process it. It is possible that I overflowed my buffer. I did not change my linker file which was working great before.

[Tesla DeLorean]

Not sure how you achieved this.

Perhaps check the Option Bytes / Banking settings

[AScha.3]

jepp. try "erase" everything...mark all memory, erase also all option bytes (just be careful, not touch the RDP level ! ) to get it back to "delivery state" .

if not successful - replace chip.

[PSicl.2]

Thank you guys for your answers.

Somehow the problem vanished during the weekend. I let the board off-power (battery unplugged, no USB cable, no JTAG) and when I tried flashing it this morning it was working.

If this problem is happening to someone else, here are some details that might explain the issue.

1) I was working with DMA to save UART stream in RAM and I might overflowed my memory which causes the problem → I don't think it is the explanation since ARM core certainly have security bound so that DMA doesn't write in unauthorized addresses.

2) Wrong timing during flashing or debug with STM32CubeIDE. I remember that the problem appeared after flashing the board with ST software so it might just be wrong flashing timing.