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.

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

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

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

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

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

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