2008-05-27 12:33 PM
command line boot loader utility available?
2011-05-17 03:22 AM
STOne-32,
By 'version', I meant a different PC application that would run from the command line with all of its parameters included, and not the version of the bootloader installed on the chip. The Windows GUI version works just fine, but I use what can best be called an ''empirical method'' of software development: make a tiny change, compile, download, test. This is repeated hundreds of times (yes, hundreds) a day. Here are the steps that I must follow to accomplish the ''download'' portion of the cycle: [First time] 1. Start the ''Flash loader demonstrator (v1.0)'' program. I am greeted by the Butterfly Girl. 2. Click the ''Next >'' button, because I am done reading about the Flash loader demonstrator (v1.0). 3. Here I am presented with all the communication options. To save time, I rearranged all my serial cables so that I could use ''COM1'' (the default) without having to change it to ''COM2'' or whatever every time I start the program. To save even more time, I change the ''Timeout(s)'' from the default of ''5'' to ''1'', because if it's not going to work the first time, it's generally not going to work subsequently. This takes six mouse clicks to change from ''5'' to ''1''. When I am satisfied, I click the ''Next >'' button again, hoping that I have remembered to power up the STM3210B-EVAL and set the BOOT0/BOOT1 switches properly and press the reset button. If not, I do so at this time. 4. If all goes well, I am presented with the ''target selection'' page. I find everything to my satisfaction so I click the ''Next >'' button to continue. 5. Now I see the ''requested operation and related parameters'' page. ''Erase'' is the default operation. I change this to ''Download''. 6. I click the ''...'' browse button and find my image file. The program's recollection of previously selected files and subdirectories is puzzling to me. The first time I run the program after turning on my PC, it begins browsing in the ''My Documents'' folder, which sort of makes sense. If I select a file for downloading from another folder, then subsequently close the application and then re-open it, it (or Windows) seems to retain the location of the folder correctly. It would be nice to have it consistently remember the location of at least the last file selected for download. 7. I changed my project's default output file type from Intel HEX (*.hex) to binary (*.bin) to save yet more mouse clicks, as ''*.bin'' is the default file type offered by the ''Open'' dialog box. I select my output file for downloading. 8. I select the ''Verify'' option. 9. I select the ''Jump to the user program'' option rather than change the BOOT* switches and reset the board every time. This is a nice option. 10. I cross my fingers for good luck and click the ''Next >'' button. The code usually gets programmed into the chip. Sometimes it doesn't, and the only explanation I get is that the ''operation failed''. OK, that describes the first time. Now that it's all set up, I can use the following steps to repeat the download process without having to start from the beginning: [Subsequent times] 1. Click on already opened ''Flash loader demonstrator (v1.0)'' application. 2. Click on the ''< Back'' button three (3) times. 3. Wait for the program to do whatever it does between the ''requested operation page'' and the ''target selection page'' when going backwards. Perhaps it is reloading and parsing the ''Flash mapping'' grid control contents? This takes 3-4 seconds on my computer (2.4GHz Intel, 1GB RAM). 4. When I can confirm that the ''communication port page'' is being displayed, I press the reset button on the STM3210B-EVAL board to return the chip to bootloader mode. I generally leave the BOOT* switches in the downloader position (BOOT0=1, BOOT1=0). By now I don't even look; I know what they are supposed to feel like. 5. When I see that the LCD backlight is illuminated (the first thing my programs do is to turn this output off) I know that the part is back in bootloader mode. 6. I click the ''Next >'' button three (3) times to breeze through the already-populated pages and start the actual download process. If all goes well, I get the green progress bar and my application starts. So you can see that my ''optimized'' usage of the Flash loader demonstrator (v1.0) saves me four (4) steps. In contrast, I have, in the past, used command line applications that took all their parameters up front and could be invoked from a makefile. I would type ''make'' to recompile my source files and see if I made any sort of syntactical errors then, upon successful completion of that step, I would type ''make prog'' which would send my newly-minted bytes to the chip and restart it for me. This is faster and more convenient. These command line utilities presently exist for the AVR, NXP's LPC21xx parts (lpc21isp), Luminary Micro's LM3S series (LMFlash.exe) and the STM32 if you are using Raissonance's RLink (Cortex-pgm.exe). The AVR and LPC software is open source and cross-platform. I hope I have made my point clearer. I did not mean to impugn the quality or usefulness of the ST product in any way. Thanks, Dale Wheat2011-05-17 03:22 AM
Has anyone seen a command line version of the flash bootloader? If not, would anyone be interested in something like this? I'm finding the Windows application a bit cumbersome for repeated usage.
Thanks, Dale Wheat2011-05-17 03:22 AM
Hi dale,
The bootloader version is sent in the get ID command. Could you please detail what do you mean by ''bit cumbersome for repeated usage'' ? and if possible to give some enhancements we can highlight to ST to implement. Thx, STOne-32.2011-05-17 03:22 AM
I agree with Dale.
Also, for production where you want to run many programming sessions at the same time a command line version that runs from a batch file would be invaluable. Maybe the existing GUI type tool could be made work from a command line? I always make my GUI programs work in this way -- and always return a result so that a batch file can know if it worked or not. It is usually very little extra work.2011-05-17 03:22 AM
I also agree with Dale and togrady. I made a command line programming tool for an ST10. This one is being used in production, development and in the field. For production and development it is used via command line and for ''dumb'' customers in field it is used via GUI.
Regards Squonk2011-05-17 03:22 AM
As I get nearer to my project going into mass production I still do not know how it will be programmed in production. What are people using for production programming? Surely not the ST flash loader or I'll have to buy the production people lots of mice as they'll wear out the buttons :(
Have ST made the protocol public yet? If so I'd consider writing a command line loader that could be run from a batch file (in production). Regards Trevor2011-05-17 03:22 AM
The protocol has been documented at
http://www.st.com/mcu/familiesdocs-110.html ''AN2606'' or can be found at Another alternative for programming the device is via JTAG.2011-05-17 03:22 AM
Thanks Paul for this -- I never knew it has been published. I can't rely on JTAG as it will not be in the final production version.
I'll probably implement a command line version in a few weeks. I'd be happy to share it and/or make open source. It will be windows only unless others get involved. Regards Trevor2011-05-17 03:22 AM
Trevor,
You're welcome to use this to help get you started. I got it as far as identifying and programming parts but haven't finished all the options that I originally had in mind for it. It's very Windows-specific at this point. It should not be hard for a clever unix-programmer to convert to some other platform. I used Dev-C++ and GCC to compile it. A Windows binary is located here: Use at your own risk. It's not my fault if you blow stuff up with it. Thanks, Dale