Open source *nix based flasher

geoff2399 · ‎2010-06-29

Posted on June 29, 2010 at 13:54

simonqian2 · ‎2011-05-17

Posted on May 17, 2011 at 13:56

I've read your code, here is some recommendation:

1. don't put everything in main.c

2. setup abstract layer for com port so that it can simply have a version for windows, here is an example:

http://code.google.com/p/vsprog/source/browse/trunk/src/driver/comport/comport.c

3. setup a file-parser module to parse files(bin, hex......).

4. you can use getopt.h to process input parameters

5. I find malloc in read_str, but no free() found.

Of course, you don't call read_str.

6. you can add an option to define the address to execute after programming.

geoff2399 · ‎2011-05-17

Posted on May 17, 2011 at 13:56

Thanks for the feedback,

I have begun making the changes you suggested, the code is still in its infancy and priority was to just get it to read/write successfully. It now has an abstracted serial interface and I am still cleaning up the stm32 code.

The new serial interface has not been tested yet and requires someone to write a windows implementation for it, I don't use windows thus the need to write this program.

geoff2399 · ‎2011-05-17

Posted on May 17, 2011 at 13:56

Now has a -g option to start execution, can be combined with any other options.
Uses getopt now
Replaced atoi with strtoul
Added examples to help text

domen23 · ‎2011-05-17

Posted on May 17, 2011 at 13:56

Don't want to rain or your parade, but you know there are existing projects?

http://mercurial.intuxication.org/hg/stm32loader

http://sourceforge.net/projects/sloadhost/files/

geoff2399 · ‎2011-05-17

Posted on May 17, 2011 at 13:56

I had found stm32loader, but it is written in perl and I do not use perl at all on my systems.

As for sloadhost, after a quick look at it's code base, it is messy, does not configure the serial port properly, and is targeting more then just the stm32.

Eg: ''bzero (&serialport1.newtio...''

that should never be done as it can/will clobber kernel parameters/flags set by the driver.

geoff2399 · ‎2011-05-17

Posted on May 17, 2011 at 13:56

New Features

Can resume an already initialized connection
Detects Intel HEX or raw binary input
Can parse Intel HEX and verify checksums
Modular parser API so support for other formats can be added.

geoff2399 · ‎2011-05-17

Posted on May 17, 2011 at 13:56

Another new feature

Software reset from the bootloader when finished (this makes it possible to re-use the flash utility without physically re-setting the device, or specifying the -c swith)

alexalex9 · ‎2011-05-17

Posted on May 17, 2011 at 13:56

Hi,

I could fix the bzeroing business if it's a problem. I got it from one of the Linux Documentation Project Howtos:

http://tinyurl.com/3vaxa3

I suppose I could copy the old termios into the new one, then make changes???

I do save and restore original serial port configuration on close.

Too bad ST didn't release portable source code for their flash loader host. I wonder how that looks?

Cheers,

Alex

geoff2399 · ‎2011-05-17

Posted on May 17, 2011 at 13:56

Hi Alex,

bzeroing is a major issue, it can and will stomp on driver flags that may/will be set by the serial driver in the kernel, you should AND/OR the existing values to setup the structure. Have a look at serial_linux.c in stm32flash for an example of how to properly configure the device.

I am also restoring the old configuration on close, but that does not fix the problem, your code may fail to run on some systems as you are stomping on flags in the structure you don't know about.

I found this site much more complete and up to date:

http://www.easysw.com/~mike/serial/serial.html

, that howto you linked is very old.