Bootloader Flash write issue

[dclark9]

Posted on August 06, 2012 at 12:08

Hi,

We are having some issues with previously validated bootloader code on an STM32F103RG processor.What is strange is that the bootloader is responding correctly to all commands that we are sending to it, and yet it appears that the flash memory isn't being written to.Any ideas?Thanks, Dave #stm32f103 #bootloader

[Tesla DeLorean]

Posted on August 06, 2012 at 14:19

How well does it report error conditions, blank check, or verify after write?

Writing problems often stem from it not being erased, or being write protected. Check you have an appropriate page size for the device being used. Check supply voltages.

[dclark9]

Posted on August 06, 2012 at 15:45

Unfortunately the error checking in the code is pretty awful - I've picked this code up from someone who left, and the only real checks in there are the ACK and NACKS.

In terms of erasing, I try to erase the memory, but get a NACK back indicating that ROP protection is on, so I try and clear this but still get the same problem.What's odd is that we have tested this to death before, but are looking at it on new hardware and are just getting problems. Is there any way the write protect could be getting toggled by a line etc?Thanks,Dave

[Tesla DeLorean]

Posted on August 06, 2012 at 16:10

You have to be pretty purposeful to get ROP enabled/disabled. I found I needed to cycle the power after changing the setting. Turning it off should mass erase the part.

New parts reporting this would suggest other issues, either in the soldering or communications. I believe it generates the ~8V VPP internally using a charge pump, the supply usage would differ from normal operation, check the bulk capacitance placed close to the part. Generally when porting between STM32F1 parts, the various potential flash page sizes is the biggest trap. Unlike other flash parts you can't program a cell a second time getting 1 bits to 0. You want to write 16-bit values, on aligned boundaries, and hex files might not follow those rules. Also be cognizant that writing/erasing the flash while running out of a different section will stall the processor, certainly to the point that the USART can overflow. Without reviewing the code I can't offer much more, if you want to discuss privately please email me at sourcer32@gmail.com