STM32F405: Unable to program

[Sumeet Kler]

Posted on July 17, 2017 at 16:07

Hi guys, 

I've been working with my STM32F405 for over a month now and all of a sudden my chip is unable to be programmed. When I attempt to program my chip using SW4STM32 I get this following error: 

   Open On-Chip Debugger 0.10.0-dev-00275-gd486ac2-dirty (2017-03-06-15:22)

   Licensed under GNU GPL v2   For bug reports, read

https://community.st.com/external-link.jspa?url=http%3A%2F%2Fopenocd.org%2Fdoc%2Fdoxygen%2Fbugs.html

   Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD   adapter speed: 2000 kHz   adapter_nsrst_delay: 100   srst_only separate srst_nogate srst_open_drain connect_assert_srst   srst_only separate srst_nogate srst_open_drain connect_assert_srst   Info : Unable to match requested speed 2000 kHz, using 1800 kHz   Info : Unable to match requested speed 2000 kHz, using 1800 kHz   Info : clock speed 1800 kHz   Info : STLINK v2 JTAG v27 API v2 SWIM v6 VID 0x0483 PID 0x3748   Info : vid/pid are not identical: 0x0483/0x374B 0x0483/0x3748   Info : using stlink api v2   Info : Target voltage: 3.247337   Info : STM32F405VGTx.cpu: hardware has 6 breakpoints, 4 watchpoints   Info : Unable to match requested speed 2000 kHz, using 1800 kHz   Info : Unable to match requested speed 2000 kHz, using 1800 kHz   adapter speed: 1800 kHz   STM32F405VGTx.cpu: target state: halted   target halted due to debug-request, current mode: Thread    xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc   configuring PLL   ** Programming Started **   auto erase enabled   Info : device id = 0x10076413   Warn : STM32 flash size failed, probe inaccurate - assuming 1024k flash   Info : flash size = 1024kbytes   STM32F405VGTx.cpu: target state: halted   target halted due to breakpoint, current mode: Thread    xPSR: 0x61000000 pc: 0x20000046 msp: 0xfffffffc   wrote 49152 bytes from file Debug/G3_Working_Proto.elf in 8.144894s (5.893 KiB/s)   ** Programming Finished **   ** Verify Started **   STM32F405VGTx.cpu: target state: halted   target halted due to breakpoint, current mode: Thread    xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc   Error: checksum mismatch - attempting binary compare   diff 0 address 0x08000000. Was 0xff instead of 0x00   diff 1 address 0x08000001. Was 0xff instead of 0x00   diff 2 address 0x08000002. Was 0xff instead of 0x02   diff 3 address 0x08000003. Was 0xff instead of 0x20   diff 4 address 0x08000004. Was 0xff instead of 0xe1   diff 5 address 0x08000005. Was 0xff instead of 0xa3   --> this continues until diff 127 where all say it is 0xff instead of...   More than 128 errors, the rest are not printed.   ** Verify Failed **   shutdown command invoked

I then attempted to use the ST Visual Programmer and ST-Link utility. In there I can see that my read out protection has been set to level 1 but when I attempt to set the byte to level 0 i get the following error: 

   Could not set Option bytes!

   Please reset target and retry.

The issue happened to me the other day but after a few minutes I was able to program it again, it then happened again a few hours later and I have not been able to do anything since. I have tried resetting the chip but it has no effect. I do not believe it is the ST-Link as I have tried using two different ones. It seems to me that the flash may have been corrupted/died out, so I have ordered a new chip,  but I can not seem to think of a reason for this to happen as I have been using it for over a month with no issue. Any suggestions/tips for what may have caused this would be great so I can avoid this issue in the future or fixes so I can get this chip up and running again. 

Thanks in advance, 

Sumeet

#stm32f405 #flash

[Sumeet Kler]

Posted on July 19, 2017 at 17:04

Thank you for the reply, so I have replaced the chip on my board and everything seems to be functioning normally. In the process of removing the old chip some pins have been bent and been broken off. Is it still worth sending the chip in? 

Thank you again,

Sumeet

[Willem La Grange]

Posted on July 20, 2017 at 12:03

I also have experienced this problem many times before and this is how I solved it:

Firstly, update you software and firmware of your STLINK.

Secondly, go to settings and change the STLINK setting from SWO to JTAG or visa versa.

You should also ensure that you reset line in the MCU is stable (disable external watchdogs)

Now attempt to change the read-out protection to level 0 again

I found that it now works most of the time.

Your last step is to do a full chip erase - If not, you may have problems the next time around again.

What I also experienced is that a different STLINK solved the problem although both STLINKs were in perfect working order (Which is a bit weird)

Hope that helps... ;-)

[re.wolff9]

Posted on July 20, 2017 at 16:25

Does your device normally do USB? Then when you boot with boot0 high, you should see that it booted into DFU mode. 

[Tesla DeLorean · Accepted solution]

Posted on July 20, 2017 at 16:39

I think it has been reasonably established that there is some hw issue here, ST asked for the part, and this seems to be a limited, but recurrent issue.

[Tesla DeLorean]

Posted on July 20, 2017 at 16:47

Yes, I encounter locked parts occasionally, but not as a result of hw damage, Sumeet seems to have a device that's got into some problematic state. The number of credible reports suggests some other mechanism is at play, most likely high voltages getting into the power ring, either directly, or via the GPIO. This may be due to exceeding spec/absolute maximums or ESD, but the parts really need to get to ST's QA department to get more conclusive findings.

[re.wolff9]

Posted on July 20, 2017 at 17:10

I have a project with an STM32F072C. Instead of 100k/10k as the voltage divider for measuring 'battery voltage' my colleague mounted 100/10k. With over 13V on the battery, that should cause about 100mA to run into the IO pin... The chip gets hot but doesn't fail.... (it would've been annoying to blow up several devices before we'd found it). 

Hmm. The pin is '5 tolerant', so from the datasheet I suspect there is a 4V nominal zener to 3.3V as a protection diode That would put the voltage on the pin at 7.3V, still about 50mA and 250mW in the zener... 

Anyway... yes the '405 seems a bit more fragile than the '072. 

[Willem La Grange]

Posted on July 20, 2017 at 18:58

My experiences were with STM32F205's, STM32L151's and STM32F051's where I locked the parts deliberately to protect my design. I don't think that I ever experienced the problem where the part does not want to unlock in the LAB environment but I had a few returning from the field that either does not want to unlock in SWO mode, and some that does not want to unlock in JTAG mode. But it is also very rare where I had to replace any devices. In fact, I found the STM32 devices generally more robust than processors from other manufacturers.

I just learned theses tips and tricks from all the many designs that I made with STM32's and it is not really that big of a problem to me.

Since the option bytes are also accessible from inside the MCU, maybe the chip could also be locked inadvertently by a firmware glitch.

[re.wolff9]

Posted on July 21, 2017 at 12:01

Isn't there a 'not by accident' unlock procedure for that just like for flash. 

Of course, If your code needs to write (either flash or option bytes), you will have a 'unlock it' function in your code. If things go wrong, that will have been called. But most applications won't write to the option bytes, so won't have the unlock 'magic' aboard. So if the code has failed 1000 times and accidentally wrote to the option bytes after following the unlock procedure with two random values... then you'd have a 1000/2^64 chance of finding one weirdly locked part. Not going to happen. 

(The system memory is occasionally referred to as factory programmed by ST. I think it's just normal flash, possibly with the 'erase' circuitry removed. I suspect that especially if they didn't remove the 'erase' circuits, there is an unlock sequence that will unlock the system memory for erasing and writing..... Nobody has found it yet.... )

[Willem La Grange]

Posted on August 10, 2017 at 12:27

Hi, Sorry I did not see your question. There are several methods to 'Lock' a device - The readout protection (LEVEL 0,1 and 2) as well as locking memory areas for accidental writing using the STlink. I would not suggest writing to the OPTION BYTES within your code but it is a good idea to READ the option bytes in your code to see if it was programmed as you intended. You can still change the memory protection areas after the readout protection was set to '1' (I strongly advise against using level 2 - unless you are 100% sure that your code is not going to change) but if you change the readout protection to LEVEL 0, the chip performs a FULL ERASE.

Here is a useful snippet to ensure that the readout protection was set to level 1 on a STM32F205 device:

&sharpifndef DEBUG

&sharpwarning Checking option bytes - readout protecting     OptionBytes = (*(uint32_t*) 0x1FFFC000);                if( (OptionBytes & 0xff00) == 0xAA00)           //Readout protection not enabled    {        //Now you do not run at all        while(1);    }&sharpelse&sharpwarning Device is not locked for production!!!&sharpendif