STM32F4 chip erase through DFU

[jerome2399]

Posted on February 20, 2014 at 12:26

Hi,

I have a board based on the STM32F429ZIT6, same as on the STM32F429I-Discovery. The board is wired so that the MCU can be reprogrammed via USB DFU. There is no ST-Link since this is a custom prototype board.

While playing with the ''DfuSe Demonstration'' tool, aka. ''DfuSe Demo (v3.0.3)'', I accidently programmed the option byte containing the SPRMOD bit to 0xFF, enabling by mistake the ''Proprietary code readout protection (PCROP)'' feature of the MCU.

If I understand correctly, the only way to disable PCROP is to perform a full chip erase. I found how to do that on a discovery board using the ST-Link utility, but I cannot use that tool with my custom board. And I can't find how to do that with the DfuSe Demo tool. Can anyone point me in the right direction?

Regards,

Doub.

#stm32f4-chip-erase-dfu

[Tesla DeLorean]

Posted on February 20, 2014 at 13:06

So I'll assume you mean you have no JTAG/SWD connectivity either?

The DFU tester application permits protocol level commands to the part, there is an Erase option, and there may be other mass erase commands. You'd need to review documentation.

If you have access to USART1/USART3 then you could use the Flash Loader Demonstrator, and mass erase via that.

[jerome2399]

Posted on February 20, 2014 at 17:03

I have a 10 pin JTAG connector, and an adapter to a cheap Olimex 20 pin JTAG probe. So if you can tell me how to fix the issue with OpenOCD or another tool that can use the Olimex probe, it would be nice.

But I'd still want to know how to fix the issue through DFU, as my final boards won't have the JTAG connector soldered on.

What is the documentation you're referring to? The PDF files coming with the Dfu tool make no mention of a mass erase function. The only erase I can see is in the ''DFU Tester'' app (not ''DfuSe Demo''), but if I select it and hit go nothing happens. I tried checking all sectors in the ''Mapping'' list, or only the ''Boot options'' sectors, but the device stays in readout protection mode.

[Tesla DeLorean]

Posted on February 20, 2014 at 17:28

Honestly I can't help you with OpenOCD, you'll need to seek help via their community. If you had an

http://www.st.com/web/en/catalog/tools/FM146/CL1984/SC724/SS1677/PF251168

and

https://www.olimex.com/Products/ARM/JTAG/ARM-JTAG-20-10/

then you could use the features of ST-LINK utilities.

Ok, so you don't plan on populating a header, you could presumably use probe points, and not write invalid settings to the part?

The

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00264379.pdf

documentation.

That said there are protection settings in the STM32F4 that can't be un-done, you'll need to work through the available tools and understand how to resolved what you have done.

[jerome2399]

Posted on February 20, 2014 at 17:51

I was considering purchasing a ST-Link, but I wasn't sure if it would be compatible with my 10 pin header. I have the exact adapter you link, so I guess it is. But at best I won't get it before many days.

The non-populated header case is for when my ''users'' have the problem and don't have anything but the USB cable to solve it.

What I've done is enable the read protection, which I believe can be undone on the STM32F429. I didn't switch the protection level to 2 (which AFAICT is the only non-reversible operation along with OTP programming). I've found several references to the DFU_DNLOAD command associated with the code 0x92 to trigger an ''unprotect'' operation.

What I'd like to know is whether I can send that command with the pre-built ST DFU tools, or whether I must build my own DFU application using either the STDFU.dll or directly implementing the DFU protocol on USB.

[Tesla DeLorean]

Posted on February 20, 2014 at 17:59

What I'd like to know is whether I can send that command with the pre-built ST DFU tools, or whether I must build my own DFU application using either the STDFU.dll or directly implementing the DFU protocol on USB.

Without wading too deep here, I believe the DFU Tester app is designed to allow you to send custom command/data sequences to the part.

[jerome2399]

Posted on February 24, 2014 at 13:28

I think I kind of managed to understand how to send the chip erase command through the Dfu Tester app, but it didn't work.

So I tried to directly write to the Flash controller registers, with a combination of OpenOCD mdw and mww commands. At first it didn't work, and I started to believe the read out protection could not be disabled. But at some point I remembered reading somewhere (can't remember where exactly) that the PCROP could only be disabled while at the same time switch the protection level from 1 to 0.

So I switched my chip from protection level 0 to 1 (which is reversible as opposed to level 2), and then I switched it back to 0 while changing the PCROP bit, and it worked.