STM32F103C6T6-Flash Loader Demonstrator

[tom239955_stm1_st]

Posted on May 12, 2008 at 07:25

STM32F103C6T6-Flash Loader Demonstrator

[tom239955_stm1_st]

Posted on May 17, 2011 at 12:30

Has anybody else seen this?

[lanchon]

Posted on May 17, 2011 at 12:30

> I have tried this on 5 differnt uP

> The first stage pass... > However whenever i move to the next step erasing or programming the uP seems to jump out of the boot mode > This does not happen when uploading there's only one thing I can think of that could trigger all this: bad supply. check your overall power distribution, that you're properly connecting and decoupling all power pins, that decoupling caps are routed to power pins with short wide traces, and that you're not daisy-chaining the power pins (ideally power and ground should be length-balanced stars). check that the supply can handle the current while programming. if I had to guess I'd say you forgot to route a power pin altogether or you forgot a decoupling cap. a current spike on a particular power pin during flash programming could trigger the BOR. but then why is it reading BOOT0 as low? what exactly did you connect to BOOT0?

[tom239955_stm1_st]

Posted on May 17, 2011 at 12:30

This show's my design atatched to BOOT0, boot 1 is pulled to Deck via a 10K resistor. The idea of the push button is that it is held down during reset (also triggered by a push button) to allow BOOT0 to be high and BOOT0 to be low at power up. I have used this on many other uP designs and never had a problem.

I have also tried holding the BOOT0 button down for the whole period. so that BOOT0 is high during the whole process of erasing and uploading but still the operation fails.

[tom239955_stm1_st]

Posted on May 17, 2011 at 12:30

The power suppl ythat i am using at the moment is current limited at 2.5A, which should be plenty!?

All voltage regulators on board are decoupled and the uP power pins are also decoupled correctly. All pin's like VSS_1 have been connected to ground.

[tom239955_stm1_st]

Posted on May 17, 2011 at 12:30

Does the boot loader use the HSE or HSI to determin the baud rate, my reason for asking is that my board has a 14.74MHz HSE , which is within the range given on the data sheet, however i have an eval board with an 8MHz crystal and this works with the Flash Loader, i would just try an 8MHz crystal but i do not have any left.

[16-32micros]

Posted on May 17, 2011 at 12:30

Hi all,

Please refer to my new post :

http://www.st.com/mcu/forums-cat-6720-23.html

. Cheers, STOne-32.

[16-32micros]

Posted on May 17, 2011 at 12:30

Hi Tom,

The bootloader is using internal RC (HSI) and is fully compatible with all HW proving the right boot pins and USART1 pins as described in AN2606. I believe it is a the v1.0 flasher software issue, could you try the new v1.1 -alpha and tell me if it resolves your issue ? Thx. Cheers, STOne-32.

[tom239955_stm1_st]

Posted on May 17, 2011 at 12:30

Hi,

I thought it was best to reply on this page , this intially worked, i was able to erase one uP and the download the code again using a .hex. However after the first atempt it has not work again, i have tried several times and i just keep getting ''FAIL:Unable to Erase Flash'' , the first stage pass's ok with the green traffic light letting me know that the device is readable (a nice improvement!).

[tom239955_stm1_st]

Posted on May 17, 2011 at 12:30

One thing to note is that one the step with the traffic lights stating my target is readable the flash size is 128Kb and RAM 20Kb but i am using a STm32F103C6 with only 32Kb of flash, is this a problem?

[tom239955_stm1_st]

Posted on May 17, 2011 at 12:30

i have just tried a second uP and the intial erase again worked but as before i can not reprogramme or erase after reprogramming on Keil, could it be the case that the erase is removing the boot loader code?