Flash Loader Demonstrator v1.1 Alpha Posted for testing

[16-32micros]

Posted on June 24, 2008 at 13:14

Flash Loader Demonstrator v1.1 Alpha Posted for testing

[16-32micros]

Posted on May 17, 2011 at 12:30Dear all Forums users and active posters, We are pleased to give you as a premium a Flash Loader Demonstrator v1.1 Alpha version for Testing before we release the official version on :

http://www.st.com/stm32

This version (v1.1-Alpha) includes some enhancements and resolve some limitations seen on v1.0 : 1) Supports of all STM32 products and STR75x products 2) Saves the last used configuration for the serial communication 3) Saves the last used file names for upload and download operations 4) Resolves a limitation of the Upload operation in a binary file 5) Resolves a limitation of Download, Upload and erase operations with Flash size (>32k). 6) Resolves a limitation when Erasing Sectors/Pages. 7) Enable/Diable the Read/Write protection commands are added 8) New Friendly icons and windows are re-designed for better usage. I'm very pleased to receive your feedbacks on this version so I can escalate it to our SW designer group for analysis. PS: Please Un-install the previous version before installation of this new v1.1 -alpha, as we have changed the installation procedure including a license agreement file and acceptation process. Enjoy it :) Cheers, STOne-32. :o

[bob239955]

Posted on May 17, 2011 at 12:30

Thankyou for doing this, the effort is appreciated.

Here is some quick initial feedback. Uninstall of v1.0 worked OK, so did install of v1.1. Great. Windows XP sp2 was used. Target: stm32 Primer modified with boot links, an rs232 chip on uart1, a reset button. Serial connection to the target also worked (but on my hardware only at 9600 baud as with v1.0). The parity setting (still) made no difference. my own target applications work fine at 115200 baud. I did not want to change my target flash memory just yet so I tried an upload in order to download the 128k flash to the PC. Maybe upload should be called download. see wiki on

http://en.wikipedia.org/wiki/Upload

. I set my new 'upload' file name to x.bin (which did not exist) so it sensibly asked if I wanted to create it. I said yes. But when I clicked yes to start the upload it said; file does not exist! So I created the file myself with notepad editor and it worked OK. 8-) The upload initially seemed faster than v1.0 taking 2min 30sec to reach 100% at 9600baud for 128k instead of 3min 12sec, but when it got to 100% the clock kept running as it spent about 30 seconds doing something before the bargraph went green and the [Finish] button ungreyed and the [Next] button text quaintly flickered between grey and black. It was still 10s faster than version 1.0, v1.1 took 3minutes 2seconds. The ability to remember settings is most welcome and the padlock icons are nice. ;) [ This message was edited by: bobz on 18-04-2008 18:47 ]

[lanchon]

Posted on May 17, 2011 at 12:30

> Maybe upload should be called download.

definitely.

[bob239955]

Posted on May 17, 2011 at 12:30

More feedback. All good. 8-)

This time I used another eval board which does work at 115200 baud. (Raisonance reva2.0 + STM32103 DB - modified with extra boot1 link for system boot mode evaluation) Upload took 15s for 128k. (minimum theoretical time @115k is about 11s - good) Download+erase+program+verify took 39s for 128k. (Good considering file passes through uart1 twice). Notes 0) I use the terms Upload/Download as they are used by the Demonstrator v1.1. 1) The first 32k of the 128k accessed was not 0xff, the rest 96k was 0xff. 2) [ ] Optimise download duration (Remove some FFs)' was NOT activated! 3) Take care using 'Download' to program a device because by default '[x] Enable read protection' is enabled which means you will not be able later to confirm the content for yourself by reading back from the device using the 'Upload' option. If you will later want to 'Upload' the device then you should uncheck '[ ] Enable read protection' when specifying the 'download' file. This checkbox is good because it demonstrates how easy it is apply read protection. 8-) 4) 230400 baud setting 'seemed' to work but times were the same.[ This message was edited by: bobz on 18-04-2008 11:54 ]

[bruce]

Posted on May 17, 2011 at 12:30

This is working well for me, better than the old version.

But I'd love to see a command line method to run it all, rather than the wizard style gui. I'd like to embed it into a makefile. Currently, I'm using it on an IAR STM32-SK board, onto which I added com1 support. The only problem programming I had was when I was using the Jlink to power the board. In that case, I was getting flash erase failures. When I switched to a seperate power supply, it started working. :o

[jj]

Posted on May 17, 2011 at 12:30

> using the Jlink to power the board. In that case, I was getting flash erase failures.

Thank you Bruce - different set-up - same problem - SOLVED w/''Bruce fix!'' I second the command-line > makefile suggestion/request.

[jas]

Posted on May 17, 2011 at 12:30

Well I got the RS232 flash loader working, now onto the USB version !

:D

[16-32micros]

Posted on May 17, 2011 at 12:30

Hi Arm_Wrestler,

What do you mean by the USB version ? Did you want to get another bootloader with USB instead of RS232.... STOne-32.

[jas]

Posted on May 17, 2011 at 12:30

Hi STOne-32,

I want to explore the DfuSe project as you described here: http://www.st.com/mcu/forums-cat-6792-23.html since many new laptop PC's do not have RS232 com ports and our customers will want to upgrade firmware using USB. I have also added ethernet MAC & PHY SPI device (Microchip enc28j60) to my STR32 pcb but firmware upgrade using TCP/IP is probably beyond my s/w ability ? :-[ Maybe just remote control via mini web pages stored in external SPI flash ? Regards, Julian.