CAN bootloader's Write Unprotect command doesn't work

[charlesmao]

Posted on December 03, 2013 at 03:39

Hi All,

I need help on the following two questions. Thanks for your inputs.1. The Write Unprotect command described in the application note ''AN3154 CAN protocol used in STM32 bootloader'' doesn't work at all. Is there any other method to disable all write protection on the whole flash memory? Here are the steps I was taking: I first enabled write protection on a few sectors using command 0x63. After a system reset, I tried to issue 0x73 command to disable write protection. The device responded with the correct acknowledgement, but those sectors were still write protected.2. After those sector have been write-protected, I tried to erase the whole chip using Keil IDE, but it failed. My second question is how I can disable write protection under Keil? #can-bootloader-write-unprotect

[Tesla DeLorean]

Posted on December 03, 2013 at 15:41

There are generally very few people here using the CAN boot loader, so the answers might not come quickly.

What specific STM32 part family are we talking about here, and what data patterns are you sending to the chip? With Keil, you might want to check if you have the ''STM32Fxx Options Bytes'' flash algorithm provided under the Flash configuration pane. Alternatively you could try the ST-Link and it's utilities, or the Flash Loader Demonstrator via a serial port. Finally these are also things your own code in the device could read or modify.

[charlesmao]

Posted on December 03, 2013 at 16:34

Clive, thanks for your reply. I am using STM32F4Discovery board, so the MCU is STM32F407VGT6. The data pattern (command format) I sent to the bootloader was strictly following the application note. For example: once the communication with bootloader is built, I sent the first CAN message as following, CAN ID = 0x73, DLC=0x01, DATA[0]=0x00. Two CAN messages (acknowledgement from the bootloader) received: CAN ID=0x73, DLC=0x01, DATA[0]=0x79.

It seems everything goes smoothly as the application note states except the bootloader doesn't disable the write protection at all.

[Tesla DeLorean]

Posted on December 03, 2013 at 17:35

Are you doing anything with the NRST pin? If you put it on a scope do you observe the board reset after you send the UNPROTECT?

[charlesmao]

Posted on December 03, 2013 at 19:00

No, I did nothing to NRST pin other than what the discovery board has. I haven't probed the pin, but I think it resets after UNPROTECT command because I have to send a CAN message to build communication with the bootloader after UNPROTECT command: CAN ID=0x79, DLC=0x00 and received an acknowledgement message from the bootloader: CAN ID=0x79, DLC=0x01, DATA[0]=0x79.

[Tesla DeLorean]

Posted on December 03, 2013 at 19:26

Ok, just checking a hunch.

How are you checking the write protection is still in effect, can you query the device using the ST-Link Utilities? One trap with the loader is that addresses are sent big-endian. You should also be able to output diagnostic data via the SWV mode supported by the ST-Link. You could dump out the option byte values.

http://www.arm.com/files/pdf/mcbstm32c_lab.pdf

http://www.keil.com/download/files/labst.pdf

[charlesmao]

Posted on December 03, 2013 at 20:34

I didn't use ST-Utilities, but I read option bytes using the bootloader's READ MEMORY command. Since I didn't enable READOUT protection, I have no problem to read back the option bytes content. Yes, I am aware of big-endian numbers used in bootloader. And all data read back makes sense so I am quite sure the endianness I was using was right.

[charlesmao]

Posted on December 04, 2013 at 19:25

Any one encountered the same issue - WRITE UNPROTECT command doesn't work? I have two discovery boards and the same problem occurs on both boards.

I filed a support ticket and so far the answer I got from ST says ''I'm unaware of any errata related to the CAN bootloader. Please double-check the baudrates, command sequences and hardware connections.'' I am pretty sure there's a bug in the CAN bootloader, but I jsut need another person confirm this is the case.

[charlesmao]

Posted on December 05, 2013 at 02:55

Finally my technical support ticket got updated, but anyone knows what it really means?

My tickets:

Request ID Creation Date Status

R13480085

12/2/2013 12:00:00 AM REJECTED