|
![](static/image/common/ico_lz.png)
楼主 |
发表于 2008-5-25 10:28:04
|
显示全部楼层
唉,刚在baidu搜了一下
http://62.193.238.133/forums-cat-6284-23.html,这人似乎与我遇到同样的问题
我用上面提供的那个stm32boot.exe,是命令行模式,换了所有芯片,似乎都好使
看来,不是挑芯片,而是st的那个软件挑机器
这是地址
http://dalewheat.com/STM32boot/stm32boot.exe
一楼或是哪位大虾有空有条件能测试一下吗,多谢了
下面是那个帖子全文
command line boot loader utility available?
Moderated by : ? STOne-32
Author beginning argument ( Replies received: 8 )
dale Posted 27-01-2008 at 18:45
Registered on :
01-11-2008
Messages : 18
OFF-Line
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 Wheat
Profile Quote
STOne-32 Posted 28-01-2008 at 11:55
Registered on :
05-29-2007
From STMicroelectronics
Messages : 226
OFF-Line
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.
Profile www Quote
dale Posted 28-01-2008 at 17:05
Registered on :
01-11-2008
Messages : 18
OFF-Line
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 Wheat
Profile Quote
togrady Posted 30-01-2008 at 22:24
Registered on :
12-07-2008
Messages : 26
OFF-Line
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.
Profile Quote
Squonk Posted 30-01-2008 at 23:45
Registered on :
10-15-2006
From Germany
Messages : 32
OFF-Line
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
Squonk
Profile Quote
togrady Posted 06-04-2008 at 01:27
Registered on :
12-07-2008
Messages : 26
OFF-Line
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
Trevor
Profile Quote
paul.archer Posted 07-04-2008 at 07:30
Registered on :
03-10-2008
Messages : 6
OFF-Line
The protocol has been documented at
http://www.st.com/mcu/familiesdocs-110.html
"AN2606" or can be found at http://www.st.com/stonline/products/literature/an/13801.pdf
Another alternative for programming the device is via JTAG.
Profile Quote
togrady Posted 08-04-2008 at 00:15
Registered on :
12-07-2008
Messages : 26
OFF-Line
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
Trevor
Profile Quote
dale Posted 08-04-2008 at 05:11
Registered on :
01-11-2008
Messages : 18
OFF-Line
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.
dalewheat.com/STM32boot/main.c
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:
dalewheat.com/STM32boot/stm32boot.exe
Use at your own risk. It's not my fault if you blow stuff up with it.
Thanks,
Dale |
|