STM32F3 discovery board bootloader

[arganasss]

Posted on January 07, 2014 at 17:12

Hello everyone, i want to get bootloader working through USART protocol. I looked to the datahseet and it says, that BOOT0 should be 1, and BOOT1 0. Since BOOT1 here isnt and I/O pin, it has to be programed and i found out, that it is an optinional byte, but by default it should be 0. So all i need to do is to connect BOOT0 pin to 3V supply and push reset button, and system memory boot mode should be selected. I downloaded the STM flash loader program but i cant get that to work because i always get an answer: No response from the target, the Boot loader cannot be started. Could someone explain me what im doing whrong here and why bootloader doesn't start? Thanks in advance.

#!telegraphing

[Tesla DeLorean]

Posted on January 07, 2014 at 18:14

Which USART/pins are you using?

Has the USART/serial connectivity been tested with application code? The boot loader needs EVEN parity. You can manually test the loader by using something like RealTerm at 9600 8E1, sending the 0x7F hex byte, and observing if an 0x79 is returned.

[arganasss]

Posted on January 08, 2014 at 15:22

yeah my bad. I mixed the rx & tx pin's of the USART'1. But still can't to make flash loader work. Normally(as i've seen on youtube or read tutorials) after u press reset and select in flash demonstrator program  port, baud rate, and even parity, u can click next , and the green light should light up flash loader should connect to stm32. However, i get a red light and it says: Warning, then u click ''Remove protection'' button, the flash will be mass erased and all data will be lost. I have never seen that on any tutorials or documents which i was reading, so any ideas why this happens? thanks.

[Tesla DeLorean]

Posted on January 08, 2014 at 16:21

I don't know, are you using the current version of the tool?

Does the manual test work? The protocol is simple, and the tools is pretty useless at providing much diagnostic information. Get the protocol manual and probe the device. Try a different serial port, ideally an on-board one, if you just have dongles try a different one. The 0x7F pattern is used to auto-baud the connection, if it gets this wrong further communication is useless. Can you use the USB connector and DFU mode, when BOOT0=High?

[arganasss]

Posted on January 08, 2014 at 16:55

I'm using 2.6.0 version of the tool. As for the manual test, when i set BOOT0 i went to Docklight and send 0x7F command to the controller, and receive 0x79, so i guess everything works as it should, just for some reason i cant connect to it through flash loader tool.

''Can you use the USB connector and DFU mode, when BOOT0=High''? : I'm sorry, i'm new to programming controllers and don't know how to check this. How can i do that?

[Tesla DeLorean]

Posted on January 08, 2014 at 19:23

http://www.st.com/web/en/catalog/tools/PF257916

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Attachments/21697/DFUse%20User%20Manual.pdf

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/CD00202pdf

[arganasss]

Posted on January 12, 2014 at 01:30

Well, i've been struggling for a few days now, and here is what i can say: STM32F1 discovery board that i got works well. I send 0x7F to the bootloader and recieve 0x79. I can whrite to the flash memory of this board with no problems using STMFlashloader program. STM32F4 discovery board that i have also works, i can whrite to the flash memory of this board also with the flashloader program.(Only dont kno'w why, but through USART'1 i can communicate with bootloader only with very small baud rates < 4800. Any idea's why?) , and when it comes to F3 discovery board, i get this: 

Pressing remove protection button doesn't give anything, just says that device will reset, but stilll after that i can only press back or close. I also didn't manage to make work F3 in DFU mode when BOOT0 is high. Tried to use V2.5 and V2.0 of the tool and F1 and F4(with small baud rates) works and F3 give\s the same result as in the picture above. Is there any other ways to program flash memory using USART via PC? Or any ideas where the problem could be? Thanks very much in advance for your help and comments.BTW: Manual test works for all three boards.

[Tesla DeLorean]

Posted on January 12, 2014 at 02:08

You can't use PA9 on the STM32F4-Discovery because there's a bloody great capacitor attached to it, surprised it even works at 4800, 1200 seemed about about the only thing that worked.

Not sure what version is required for the F3, GUI applications are next to useless to diagnose protocol level issues. You want to either talk to the chip directly via the serial port, or put a serial port monitor on your system and observe the to-and-fro between the software and the chip. Perhaps the command line app (and the source) would provide more insight.

[arganasss]

Posted on January 13, 2014 at 00:57

As for F4 discovery board, i meant to say it only worked for me with baud rates lower than 4800. I mean i only got it to work on 2400 or less. But here is the thing that really confused me now. I re-installed the Flashloader tool and for the first time, it allowed me to connect to the controller and program it's flash memory. When i'm done and quit the flash GUI and enter it again, it gives a warning (the picture in above post) and i can't get any further. The same happens with 2.5 and 2.4 version of the tool, after i install it for the first time, i can do everything right, after one time it gives a warning (the picture in above post), so i'm thinking now maybe its not GUI protocol level issues? Maybe processor lock's somehow his flash memory after it is programmed? Do you have any idea's abut this Clive? Or am i talking complete nonsense here? As always - thanks for your help and comments.

[Tesla DeLorean]

Posted on January 13, 2014 at 01:56

I don't have much mileage on the F3, I have a couple of the DISCO boards but haven't wired up a USART to them.

The auto-bauding is a one shot deal, so the main method to remedy things is to reset the board and try to reconnect. USB-to-RS232 serial dongles are sometimes more problematic than on-board serial ports. Without seeing what transactions are going on it's hard to diagnose, but generally communication failures tend to come up as complaints about option bytes, or protection settings.