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

[Vangelis Fortounas]

Posted on July 17, 2017 at 16:46

hello!

check with stm32 STLINK utility (Menu-> target->option bytes) to see if some option bytes are set to write_protect or read_protect.. try to erase the whole chip.

[Sumeet Kler]

Posted on July 17, 2017 at 16:49

Nothing is write protected, but read protection is at level 1. When i try to reset the option bytes it gives me the error that I have in the question and when I try to erase the entire chip it says that the device is protected so it can't. 

[Vangelis Fortounas]

Posted on July 17, 2017 at 18:04

Hi again. 

For some unknown reason to me i didn't  saw  the second part of your question about STLink actions you made.

So i gave you this incomprehensible answer. 

sorry.

[Vangelis Fortounas]

Posted on July 17, 2017 at 17:23

hello again!!

So try to change the read protection level to zero!!

it will erases  automaticaly the memory but is OK for you.

[Sumeet Kler]

Posted on July 17, 2017 at 17:31

Yes, I already tried that. The outcome of that is in my question. When I do that it says the the byte can not be set.

[Tesla DeLorean]

Posted on July 17, 2017 at 17:34

>>

all of a sudden my chip is unable to be programmed

To be honest, we have less idea about what changed on your end than you do. Try and think a little bit harder about circuit or software changes you may have made recently.

Really not sure how robust the OCD implementation is. The error does look like it failed to program, why that would occur is not clear, but the protection modes may alter what code can be loaded and run from RAM during the programming phase. The error gets reported here with some frequency, but generally seems to be a comms error from the SWD/JTAG side as a potential cause.

Does the problem persist if you pull BOOT0 high so it runs the code from ROM rather than yours?

Have you added code to program flash, options, or low power modes within your own code. Could there be problems with errant execution in your code? What other bug, or failures have you been fighting prior to this failure? Is the chip likely to see large voltage spike on the supply or IO pins? Motors, Relays, etc?

Can you access the system loader via USART (Flash Demonstrator), or USB (DFU)?

[Sumeet Kler]

Posted on July 17, 2017 at 17:51

Thanks for the reply Clive, I have not tried pulling the BOOT0 line high yet but I will give it a go and update you on what happens. I don't alter the flash, options or low power modes in my own code. Before this there have been no bugs to this degree other than logic issues within my own code and failed to program issues that get fixed by clearing all breakpoints in my code. The chip isn't likely to see any voltage spikes due to the voltage regulators on the board. Ya, I've seen the other questions posted here but I am almost certain it not a problem with the communications as it had been programming fine for over a month and I also tried programming the chip with a brand new st-link. 

[Sumeet Kler]

Posted on July 17, 2017 at 18:20

UPDATE: I've pulled the BOOT0 line high and it does not change the situation in regards to being able to program the chip.

[STOne-32]

Posted on July 18, 2017 at 01:00

Dear Sumeet,

Can you please check your Hardware connections, in particular : VDD/VDDA and VCAP pins and monitor at power on that VCAP1 and VCAP2 are at  ~1.2Volts.   if all HW are fine, I may ask you the top marking of the device, picture is appreciated for the date code , Then if St-Link Utility is working to provide the 96-bits Unique ID . if not helping, please contact your nearst ST office or distributor and get contact with our local FAEs to apply for a quality Failure analysis, to understand what happened with your device. I may happen and electrical Over stress at VDDs ( example more than 4 Volts) causing such behavior. 

Cheers,

STOne-32.

[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... ;)

[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.