Flashing STM32 via serial line on Linux – stm32flash

For Windows users there is a tool called “Flash Loader Demonstrator”. This obviously does not run on Linux, but there is also a possibility to natively flash a binary (or hex file) in case you cannot use the WIZnet update tools that use the bootloader. So this is basically needed when you want to upgrade the bootloader. In case you don’t have subversion installed you need to do the following in a console:
tw@kallisto:~# sudo apt-get update && sudo apt-get install subversion

After that you have to first checkout the latest sourcecode of the tool

tw@kallisto:~$ svn checkout http://stm32flash.googlecode.com/svn/trunk/ stm32flash

Then you can compile and install the tool

tw@kallisto:~$ cd stm32flash && make && sudo make install

Bildschirmfoto vom 2015-03-18 14:17:16

Now you have to bring the board into boot mode. There is usually some BootEnable pin. Hold that booten pin during power up or reset of the module. After that, the module is waiting for the following command:
tw@kallisto:~$ stm32flash –w combine.bin –v /dev/ttyS0

Bildschirmfoto-Namenloses Fenster

Generate Padding for the Bootloader

There is one important difference between the Windows version of Flashloader Demo and the stm32flash. In the current version of the stm32flash the complete flash is erased before programming. As long as you have only one binary for the application this is no issue. But in case you have a bootloader and an application the bootloader is erased when you flash the application.
As a workaround for this you have to combine the two files.
How to combine Bootloader and Application file.

As an example i’ll show how to combine the bootloader and application file of WIZ550web. As per note on http://wizwiki.net/wiki/doku.php?id=products:wiz550web:wiz550web_download the bootloader shall go to the adress 0x8000000 and the application shall go to 0x8006000. So as we will copy both files together the bootload needs some padding to be exactly 0x6000 = 24576 in size.

Bildschirmfoto vom 2015-03-18 14:30:56So first we find out the size of the bootloader. In this example it is 23312 bytes in size. So we just calculate 0x6000 – 23312 = 1264. To get the padding we just dump 1264 bytes from the device /dev/zero which contains an unlimited number of zeros into some file, e.g., zeroes.bin.

tw@kallisto:~$ dd if=/dev/zero of=zeroes.bin bs=1 count=1264

After that, we just add these zeroes.bin to the bootloader file.

tw@kallisto:~$ cat zeroes.bin >> WIZ550web_Boot.bin

If you check now with ls, you can see that the size is now exactly 0x6000 = 24576 bytes.

Bildschirmfoto vom 2015-03-18 14:48:01

Now we can combine bootloader and application file in the same way. Later when you compile only the application, you can reuse the padded bootloader file, and only need this last step.

tw@kallisto:/tmp$ cp WIZ550web_Boot.bin combine.bin && cat WIZ550web_App.bin >> combine.bin

Bildschirmfoto vom 2015-03-18 14:55:16

tw@kallisto:~$ stm32flash –w combine.bin –v /dev/ttyS0

There is one important difference between the Windows version of Flashloader Demo and the stm32flash. In the current version of the stm32flash the complete flash is erased before programming. As long as you have only one binary for the application this is no issue. But in case you have a bootloader and an application the bootloader is erased when you flash the application.
As a workaround for this you have to combine the two files.

How to combine Bootloader and Application file.

As an example i’ll show how to combine the bootloader and application file of WIZ550web. As per note on http://wizwiki.net/wiki/doku.php?id=products:wiz550web:wiz550web_download the bootloader shall go to the adress 0x8000000 and the application shall go to 0x8006000. So as we will copy both files together the bootload needs some padding to be exactly 0x6000 = 24576 in size.

Bildschirmfoto vom 2015-03-18 14:30:56So first we find out the size of the bootloader. In this example it is 23312 bytes in size. So we just calculate 0x6000 – 23312 = 1264. To get the padding we just dump 1264 bytes from the device /dev/zero which contains an unlimited number of zeros into some file, e.g., zeroes.bin.

tw@kallisto:~$ dd if=/dev/zero of=zeroes.bin bs=1 count=1264

After that, we just add these zeroes.bin to the bootloader file.

tw@kallisto:~$ cat zeroes.bin >> WIZ550web_Boot.bin

If you check now with ls, you can see that the size is now exactly 0x6000 = 24576 bytes.

Bildschirmfoto vom 2015-03-18 14:48:01

Now we can combine bootloader and application file in the same way. Later when you compile only the application, you can reuse the padded bootloader file, and only need this last step.

tw@kallisto:~$ cp WIZ550web_Boot.bin combine.bin && cat WIZ550web_App.bin >> combine.bin

Bildschirmfoto vom 2015-03-18 14:55:16

by TW

Advertisements

WIZ550WEB-EVB controls power supply of WIZ107SR-TTL-EVB – part #2

First we need to determine the command that will be sent to the webserver to toggle one of the outputs. We therefore make use of the wireshark program to capture the http stream that will be sent to the webserver after having clicked a button on the WIZ550WEB-EVB website.

Picture 1: Screenshot of wireshark
Picture 1: Screenshot of wireshark

After having found the right tcp stream we can figure out, that we simply have to send this POST request to our webserver (IP: 192.168.111.182):

“pin=6&val=0” http://192.168.111.182/dout.cgi

 This can be done with the use of the cURL package – this package can send HTTP POST requests from the command line and act as if it was a user clicking on a web page. The simple. but complete command to send a HTTP POST request with cURL is:

curl –silent –output out.txt –data “pin=6&val=1” http://192.168.111.182/dout.cgi

This command forces the relay on output #6 of our WIZ550WEB-EVB to close. In the same way the relay can also be forced to open again by simply changing the value of “val” to 0. If the relay is closed, the WIZ107SR-TTL will be powered on. Including these requests into a small bash script can automate the power cycling really easy – we just have to add some wait states for the right timing and everything can be read in our PuTTY log clearly. As an example a bash script could look like this:

while [ true ]; do
echo “module on”
curl –silent –output out.txt –data “pin=6&val=0” http://192.168.111.182/dout.cgi
sleep 15
echo “module off”
curl –silent –output out.txt –data “pin=6&val=1” http://192.168.111.182/dout.cgi
sleep 5
done

In this screenshot you can see our bash script toggling the WIZ107SR-TTL operating voltage and the PuTTY log for the serial console, as well as the 550WEB Demopage that shows us the state of the relay #6:

screenshot1
Picture 2: Overview

Our primary goal was to check the long-time functionality of the WIZ107SR-TTL dns functionality – we can clearly see that if the DNS does not resolve properly or cannot be reached, that there are plenty of error messages on the serial interface of the WIZ107SR-TTL-EVB:

DNS fail log
Picture 3: DNS fail log

Using the log functionality of PuTTY we can write every boot sequence of the WIZ107SR-TTL to a text file. There are plenty of tools that can easily analyse this log file for error messages. In our first testing sequence of 600 power cycles of the WIZ107SR-TTL we did not have one failure.

Please feel free to contact us  at support AT wiznet DOT eu in case you have any questions regarding this article – fk.