We have managed to ''Brick'' an STM32F437ZGT.

[Jim Whitehouse]

Posted on March 28, 2018 at 11:34

Hi, after running some software tests, we have locked the processor. In the past, I have managed to use a uLink2 debugger to unprotect the flash, and re-gain access.

This time, the debugger won't even connect

'Cannot access Memory (@ 0xe00ffff0), Read, Acc Size 4 Byte'.

I suspect we might have enabled the full protection level that locks out JTAG. Does this seem likely, or can you suggest a workaround?

Thanks Jim

[Tesla DeLorean]

Posted on March 28, 2018 at 12:34

Have you tried connecting with BOOT0 high?

If you have been fiddling with the protection level and removed access, you will need to replace the chip or access via the code you already have programmed in the device. Usually best to have code to probe, query, etc while doing development.

[Tesla DeLorean]

Posted on March 28, 2018 at 12:51

>>I suspect we might have enabled the full protection level that locks out JTAG.

Is that what you were doing? Doesn't occur 'randomly', and is not reversible.

Do stupid things, win stupid prizes, you'll need to replace the part if you've provided no alternate means to communicate with it.

[Jim Whitehouse]

Posted on March 28, 2018 at 14:48

Someone was experimenting with software test case generation software. It looks like it thought it would be fun to test the HAL then nothing worked anymore.

[Uwe Bonnes]

Posted on March 28, 2018 at 13:18

There are attacks published against fully read protected STM32. but probably not worth a try...