dm00160659

AN4656
Application note
Bootloading procedure for STLUX™ and STNRG™ digital
controllers
Max Cortiana, Ambrogio D’Adda
Introduction
This specification contains the description of how to load a code on STLUX and where not
differently specified also on STNRG devices through the bootloader embedded in the
system memory of the device (the ROM memory). Through this firmware, the device
memory can be erased and programmed using a standard communication interface.This
code allows the memories, including the program, code and RAM, to be written into the
device through the standard serial interface UART.
Following a step-by-step guided procedure, it is possible through the standard “Flash loader
demonstrator” application released by STMicroelectronics to download an application code
into the device and it is also possible to specifically configure STLUX features.
For further information on the STLUX family features, pinout, electrical characteristics,
mechanical data and ordering information, please refer to the specific STLUX device
datasheet.
Reference document
For hardware information on the STLUX controller and product specific SMED
configuration, please refer to the STLUX and STNRG product datasheets.
December 2015
DocID027487 Rev 2
1/32
www.st.com
32
Contents
AN4656
Contents
1
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3
Bootloader protocol interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1
Peripherals settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2
Commands description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1
Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2
GET command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3
Read Memory command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.4
Erase Memory command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.5
Write Memory command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.6
GO command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4
Memory model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5
Software model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6
Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7
Error management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Error management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8
Erase/Write EEPROM routines in RAM . . . . . . . . . . . . . . . . . . . . . . . . . 25
9
How to bootload your code to a STLUX device . . . . . . . . . . . . . . . . . . 26
10
2/32
9.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2
Bootloading in AutoDetect mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.3
Bootloading with ST Flash loader demonstrator . . . . . . . . . . . . . . . . . . . 26
9.3.1
Configuring the desired UART channel . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.3.2
Checking the memory content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.3.3
Running the Flash loader demonstrator . . . . . . . . . . . . . . . . . . . . . . . . 27
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
DocID027487 Rev 2
AN4656
List of tables
List of tables
Table 1.
Table 2.
Table 3.
Table 4.
Table 5.
Table 6.
Table 7.
List of acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Allowed commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Sector codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Valid addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Initial checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
DocID027487 Rev 2
3/32
32
List of figures
AN4656
List of figures
Figure 1.
Figure 2.
Figure 3.
Figure 4.
Figure 5.
Figure 6.
Figure 7.
Figure 8.
Figure 9.
Figure 10.
Figure 11.
Figure 12.
Figure 13.
Figure 14.
Figure 15.
Figure 16.
Figure 17.
4/32
Synchronization: Host side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Synchronization: STLUX side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
GET command: Host side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
GET command: STLUX side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Read Memory command: Host side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Read Memory command: STLUX side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Erase command: Host side. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Erase command: STLUX side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Write Memory command: Host side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Write Memory command: STLUX side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
GO command: Host side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
GO command: STLUX side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Running the Flash loader demonstrator - step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Running the Flash loader demonstrator - step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Running the Flash loader demonstrator - step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Running the Flash loader demonstrator - step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Running the Flash loader demonstrator - step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
DocID027487 Rev 2
AN4656
1
Acronyms
Acronyms
A list of acronyms used in this document:
Table 1. List of acronyms
Acronym
Description
BL
Bootloader- used to load the user program without the emulator
DAC
Digital-to-analog converter
DALI
Digital addressable lighting interface
ECC
Error Correction Code
FSM
Finite state machine
FW
Firmware loaded and running on the CPU
GPIO
General purpose input/output
HSE
High-speed external crystal - ceramic resonator
HSI
High-speed internal RC oscillator
I2C
Inter-integrated circuit interface
IAP
In-application programming
ICP
In-circuit programming
ITC
Interrupt controller
IWDG
Independent watchdog
LSI
Low-speed Internal RC oscillator
MCU
Microprocessor central unit
MSC
Miscellaneous
PM
Power management
RFU
Reserved for future use
ROP
Read-out protection
RST
Reset control unit
RTC
Real-time clock
SMED
State machine event driven
STMR
System timer
SW
Software, is the firmware loaded and running on the CPU (synonymous of FW)
SWIM
Single-wire interface module
UART
Universal asynchronous receiver/transmitter
WWDG
Window watchdog
DocID027487 Rev 2
5/32
32
Description
2
AN4656
Description
The bootloading can be operated either with a user developed downloader application or
with the “Flash loader demonstrator” (loader) available from STMicroelectronics.
Before trying to load your code through the UART interface using the bootloader, a series of
checks should be performed (checks are not needed if you use a brand new STLUX
device).
The bootloader is able to accept connections on different configuration of the UART device.
By default the devices are delivered from the factory configured to enable the bootloader on
all the available channels.This means that during the initial synchronization phase the
bootloader performs polling for the synchronization character on each channel for 1/Nth of
the available time where N is the number of enabled channels. In this condition it is possible
that when the external loader sends the synchronization character to the physically
connected channel, the bootloader is checking one of the other channels. As
a consequence the bootloader does not detect the synchronization character and then the
external loader signals a missing connection.
6/32
DocID027487 Rev 2
AN4656
Bootloader protocol interface
3
Bootloader protocol interface
3.1
Peripherals settings
This section describes the hardware setting of the communication peripherals:
The UART setting:

Data frame: 1 start bit, 8 data bit, even parity bit, 1 stop bit

Automatic speed detection - min.: 4800 bps - max.: 460.8 kbps
Mandatory: in order to perform the automatic speed detection the RX lines shall be
stable in the application board.
Note:
All communication is verified by:
Checksum: all received bytes are XORed. A byte containing the computed XOR of all
previous bytes is added as the last byte of the data field (checksum byte). By XORing all the
received bytes, data + checksum, the result, at the end of the packet, must be 0x00;
According to the protocol established between the Host and BL (see Section 3.2 to
Section 3.2.6) there will be a byte accepted - ACK answer, or discarded - NACK answer.
ACK = 0x79
NACK = 0x1F
SYNCHR = 0x7F
3.2
Commands description
The supported commands are listed in Table 2:
Table 2. Allowed commands
Command
Command
code
GET
0x00
Gets the version and the allowed commands supported by the
current version of the BL.
Read Memory
0x11
Reads maximum 256 bytes of memory starting from an address
specified by the Host.
GO
0x21
Jumps to an address specified by the Host to execute
a loaded code.
Write Memory
0x31
Writes maximum 128 bytes to the RAM or the EEPROM starting
from an address specified by the Host.
Erase Memory
0x43
Erases from one to all the EEPROM sectors.
Command description
DocID027487 Rev 2
7/32
32
Bootloader protocol interface
3.2.1
AN4656
Synchronization
Figure 1. Synchronization: Host side
4UBSU
TZODISPOJ[BUJPO
4FOE4:/$)3 CZUF
8BJU TZODISPOJ[BUJPO
&OE
TZODISPOJ[BUJPO
".
Figure 2. Synchronization: STLUX side
4ZTUFNSFTF U
Y
$POGJHVSFDMPDL
BOEJOQVUQJOT
1SFTZODISPOJ[BUJPO
4
8SPOHTZODI
8BJUGPS4:/$)3
T5JNFPVU
4ZODI0,
4ZODISPOJ[BUJPO
GBJMFE $POGJHVSFTFMFDUFEEFWJDF
TFOE "$,
FOBCMF&&130.XSJUF
&&130.WJSHJO
:FT /P
$
8BJUGPS
DPNNBOET
&&130.SFTFU
Y
".
The Host sends the SYNCHR byte as follows:
UART
SYNCHR byte: 0x7F
8/32
DocID027487 Rev 2
AN4656
3.2.2
Bootloader protocol interface
GET command
By this command the Host gets the version of the BL and the supported commands.
Figure 3. GET command: Host side
4UBSU
(&5DNE
4FOEYY''
/BDL
8BJUGPSBOTXFS
"DL
(FUOVNCFSPG$.%TY
(FU#-WFSTJPOY
(FU(&[email protected]
(FU3&"[email protected]
(FU([email protected]
(FU83*5&[email protected]
(FU&3"4&[email protected]
8BJUGPSBOTXFS
&OE
(&5DNE
".
The Host sends the bytes as follows:
UART
Byte 1: 0x00 - command ID
Byte 2: 0xFF - complement
DocID027487 Rev 2
9/32
32
Bootloader protocol interface
AN4656
Figure 4. GET command: STLUX side
4UBS U
(&5DNE
(FUYY ''
4FOE "D L
4FOE/BDL
4FOE OVNCFS PG
BWBJMBCM F DNE T 4FOE#PPU-PBEFS
WFSTJP O Y
4FOEDPNN BOE
JEFOUJGJFSDPEFT
CZUFT
4FOE "DL
&OE
(&5DNE
".
The STLUX sends the bytes as follows:
Byte 1: ACK
Byte 2: N = 5 = the number of bytes to be sent -1 (1 ≤ N +1 ≤ 256)
Byte 3: version of the BL (0 < Version ≤ 255)
Byte 4: 0x00 - GET command
Byte 5: 0x11 - Read Memory command
Byte 6: 0x21 - GO command
Byte 7: 0x31 - Write Memory command
Byte 8: 0x43 - Erase Memory command
Byte 9: ACK
10/32
DocID027487 Rev 2
AN4656
3.2.3
Bootloader protocol interface
Read Memory command
This command allows reading from the memory (RAM, EEPROM or registers). When the BL
receives a Read Memory command it answers by an ACK byte and then waits for an
address (4 bytes; the 1st received is the MSB one) and a checksum byte. The BL checks
this address: if it is a valid address and the checksum is OK then the BL sends an ACK byte
otherwise sends a NACK byte and ends the command. When the address is valid and the
checksum is correct the BL waits for the number of bytes to be transmitted minus 1 (N) and
for its complemented byte (checksum of N); if the checksum is correct then the BL sends to
the Host the requested data [(N+1) bytes] starting from the received address, otherwise
sends an NACK before ending the command.
Figure 5. Read Memory command: Host side
4UBSU
3.DNE
4FOEYY&&
8BJUGPSBOTXFS
/BDL
"DL
4FOEBEESFTTCZUFT
BOEDIFDLTVN
8BJUGPSBOTXFS
/BDL
"DL
4FOEMFOHUICZUF
BOEDIFDLTVN
8BJUGPSBOTXFS
/BDL
"DL
3FDFJWFEBUB
GSPN UBSHFU
&OEU
3.DNE
".
Note:
Table 5 on page 24 shows the valid addresses. If the BL receives a not valid address an
ADD_ERROR occurs (see Table 4 on page 24).
DocID027487 Rev 2
11/32
32
Bootloader protocol interface
AN4656
Figure 6. Read Memory command: STLUX side
4UBSU
3.DNE
/P
(FUYY&&
:FT
4FOE"DL
(FUBEESFTT CZUFT
BOEDIFDLTVN
"EESFTTBOEDIFDLTVN
BSFWBMJE /P
:FT
4FOE"DL
(FUMFIHUICZUF
BOE DIFDLTVN
$IFDLTVNJTWBMJE
/P
:FT
4FOE"DL
4FOE/BDL
4FOEEBUBUPIPTU
&OE
3.DNE
The Host sends the bytes as follows:
UART
Byte 1: 0x11 - command ID
Byte 2: 0xEE - complement
Byte3 to Byte 6: the start address
Byte 3: MSB
Byte 6: LSB
Byte 7: checksum: XOR (Byte 3, Byte 4, Byte 5, Byte 6)
Byte 8: the number of bytes to be read - 1 (0 < N ≤ 255)
Byte 9: checksum: NOT Byte 8
12/32
DocID027487 Rev 2
AN4656
3.2.4
Bootloader protocol interface
Erase Memory command
The Erase command allows erasing the EEPROM memory sector by sector. When the BL
receives an Erase command, it answers by an ACK byte and then waits for the number of
sectors to erase (one byte), the sector codes and a checksum byte; if the checksum is
correct then the BL erases the memory and sends an ACK byte to the Host, otherwise
sends a NACK byte to the Host and ends the command. Some details:
1.
N is the number of sectors to erase: 0 ≤ N ≤ 32.
2.
The TBL receives N+1 bytes (see Table 3).
Figure 7. Erase command: Host side
4UBSU
&.DNE
4FOEYY#$
/BDL
8BJUGPSBOTXFS
"DL
5PUBMFSBTF
/P
:FT
4FOEOVNCFSPG
TFDUPSTUPFSBTF
4FOEY''Y
4FOETFDUPSDPEFT
4FOEDIFDLTVN
8BJUGPSBOTXFS
&OE
&.DNE
".
Note:
1. The “Total Erase” erases PROGRAM EEPROM and DATA EEPROM (33 KB). The BL
erases the memory sector by sector and not by a “Global Erase operation” because it
doesn't work in user mode.
2. A sector is 1 kbyte; therefore the granularity with the Erase command is 8 blocks.
DocID027487 Rev 2
13/32
32
Bootloader protocol interface
Warning:
AN4656
If the Host sends a sector code not allowed (see Table 3) the
command fails, therefore also the correct sector code will be
ignored.
Figure 8. Erase command: STLUX side
4UBSU
&.DNE
(FUYY#$
/P
:FT
4FOE"DL
(FUOVNCFSPGTFDUPST
:FT
/VNCFSY''
/P
(FU TFDUPSDPEFT
BOEDIFDLTVN
$IFDLTVNWBMJE $IFDLTVNWBMJE
/P
:FT
5PUBMFSBTF
&SBTFSFRVFTUFE
TFDUPST
4FOE"DL
4FOE/BDL
&OE
&.DNE
".
The Host sends the bytes as follows:
UART
Byte 1: 0x43 - command ID
Byte 2: 0xBC - complement
Byte 3: 0xFF or number of sectors to erase (0 ≤ N ≤ 32); if N > 32 a CMD_ERROR occurs.
Byte 4 or N+1 Bytes: 0x00 or [N+1 bytes and then checksum: XOR (N, N+1 bytes)]
14/32
DocID027487 Rev 2
AN4656
Bootloader protocol interface
Table 3. Sector codes
Sector code
EEPROM Addr<15:0>
0x00
8000h → 83FFh
0x01
8400h → 87FFh
0x02
8800h → 8BFFh
0x03
8C00h → 8FFFh
0x04
9000h → 93FFh
0x05
9400h → 97FFh
0x06
9800h → 9BFFh
0x07
9C00h → 9FFFh
0x08
A000h → A3FFh
0x09
A400h → A7FFh
0x0A
A800h → ABFFh
0x0B
AC00h → AFFFh
0x0C
B000h → B3FFh
0x0D
B400h → B7FFh
0x0E
B800h → BBFFh
0x0F
BC00h → BFFFh
0x10
C000h → C3FFh
0x11
C400h → C7FFh
0x12
C800h → CBFFh
0x13
CC00h → CFFFh
0x14
D000h → D3FFh
0x15
D400h → D7FFh
0x16
D800h → DBFFh
0x17
DC00h → DFFFh
0x18
E000h → E3FFh
0x19
E400h → E7FFh
0x1A
E800h → EBFFh
0x1B
EC00h → EFFFh
0x1C
F000h → F3FFh
0x1D
F400h → F7FFh
0x1E
F800h → FBFFh
0x1F
FC00h → FFFFh
0x20
4000h → 43FFh
DocID027487 Rev 2
15/32
32
Bootloader protocol interface
3.2.5
AN4656
Write Memory command
This command allows writing the memory (RAM, EEPROM or registers). When the BL
receives a Write Memory command, it sends an ACK to the Host and then waits for an
address (4 bytes; the 1st received is the MSB one) and a checksum byte. The BL checks
this address: if it is a valid address and the checksum is OK, the BL sends an ACK byte
otherwise it sends a NACK byte and ends the command. If the address is valid and the
checksum is OK, the BL will receive the following next bytes in sequence:

N (one byte), which contains the number of data bytes to be received minus 1

N+1 data bytes and the checksum (XOR of “N” and N+1 data bytes).
The incoming data are always written in the RAM before being loaded in the final location.
At this point, the BL:

Checks whether the Host wants to write in the RAM or in EEPROM

Programs the Host data to the memory starting from the received address

Reads the programmed data and calculates the checksum in order to check if the
programming operation was successful.
Finally, at the end of the command, the BL sends the ACK byte if the write operation is
completed successfully otherwise sends a NACK byte and ends the command.
Even if the Host receives an NACK, and IF THIS ERROR IS NOT DUE TO N > 127, the
memory is being programmed with “something”, BUT in any case it is necessary to
reprogramm it because there has been an error during the transmission or
programming. If the error is due to N > 127 the memory is not programmed.
The Host can send a Write command with at most 128 data bytes (N = 127). In order to write
the data in the EEPROM memory locations, the BL can performs two different write
operations:

Note:
Even if the BL writes a byte the hardware write operation executed is a WordWrite.

16/32
WordWrite: writes a word in the EEPROM. It is used when the bytes number (N+1)
sent from the Host is less than 128, in this case the BL will perform this operation
N+1 times.
BlockWrite: writes a block in the EEPROM. It is used when the bytes number (N+1)
sent from the Host is 128 AND the destination address is an integer module of 128, in
other words, in order to use this operation the block sent from the Host shall be aligned
with a memory block.
DocID027487 Rev 2
AN4656
Bootloader protocol interface
Figure 9. Write Memory command: Host side
4UBSU
8.DNE
4FOEY Y$&
8BJUGPSBOTXFS
/BDL
"DL
4FOEBEESFTTCZUFT
BOE DIFDLTVN CZUF
8BJUGPSBOTXFS
/BDL
"DL
4FOEEBUBBOE
DIFDLTVNUPUBSHFU
8BJUGPSBOTXFS
&OE
8.DNE
".
DocID027487 Rev 2
17/32
32
Bootloader protocol interface
AN4656
Figure 10. Write Memory command: STLUX side
4UBSU
8.DNE
(FUYY$&
/P
:FT
4FOE"DL
(FUBEESFTTCZUFT
BOEDIFDLTVNCZUF
"EESFTTBOE
DIFDLTVNWBMJE /P
:FT
3FDFJWFEBUBGSPN
IPTUBOETUPSFJO
NFNPSZCVGGFS
/P
"EESFTTJO&&130.
:FT
8SJUFCVGGFSUP3".
8SJUFCVGGFSUP&&130.
:FT
$IFDLTVNWBMJE
4FOE"DL
/P
4FOE/BDL
&OE
8.DNE
".
The Host sends the bytes as follows:
UART
Byte 1: 0x31 - command ID
Byte 2: 0xCE - complement
Byte 3 to Byte 6: the start address
Byte 4: MSB
Byte 7: LSB
Byte 7: checksum: XOR (Byte 3, Byte 4, Byte 5, Byte 6)
Byte 8: Bytes number to receive (0 ≤ N ≤ 127); if N > 127 a CMD_ERROR occurs in the BL.
N+1 data bytes: (max. 128 bytes)
Checksum byte: XOR (N, N+1 data bytes)
Note:
1. Table 5 on page 24 shows the valid addresses. If the BL receives a not valid address an
ADD_ERROR occurs (see Table 4 on page 24).
2. In order to download an application into the EEPROM the Host shall send more
consecutive “Write commands”. The only way to accomplish fast writing is to send as much
as possible “Write commands” aligned to the EEPROM data block.
18/32
DocID027487 Rev 2
AN4656
Bootloader protocol interface
As a reference value, to program the full 32 kByte EEPROM memory with the BL connected
at 115200 bps transferring data blocks of 128 bytes aligned to memory sectors, the following
timing should apply:
3.2.6

128 data bytes + 10 overhead protocol bytes = 138 bytes corresponding to 1518 bits

32 kbyte / 128 bytes = 256 data packets

1518 x 256 / 115200 = 3.373 s minimum transfer time

256 x 3.5 ms = 0.896 s programming time (with typical block programming time)

3.373 + 0.896 = 4.269 s total memory programming time (typical value).
GO command
This command allows running the application downloaded in the EEPROM or any other
code by making a branch to an address specified by the Host. When the BL receives a GO
command, it answers by an ACK byte and then waits for an address (4 bytes; the 1st byte
received is the MSB one) and a checksum byte; if it is a valid address and the checksum is
OK, the BL sends an ACK byte otherwise it sends a NACK byte and ends the command.
When the address is valid and the checksum is OK, the BL removes the Erase and Write
routines from the RAM and then the program counter of the CPU jumps automatically to this
address.
Figure 11. GO command: Host side
4UBSU
(0DNE
4FOEYY%&
8BJUGPSBOTXFS
/BDL
"DL
4FOE BEESFTTCZUFT
BOEDIFDLTVNCZUF
8BJUGPSBOTXFS
&OE
(0DNE
".
Note:
Table 5 on page 24 shows the valid addresses. If the BL receives a not valid address an
ADD_ERROR occurs (see Table 4 on page 24).
DocID027487 Rev 2
19/32
32
Bootloader protocol interface
AN4656
Figure 12. GO command: STLUX side
4UBSU
(0DNE
/P
(FUYY%&
:FT
4FOE"DL
(FUBEESFTTCZUFT
BOEDIFDLTVNCZUF
"EESFTTBOE
DIFDLTVNWBMJE /P
:FT
4FOE"DL
3FNPWF8SJUFBOE
&SBTFSPVUJOFT
4FOE/BDL
(PUPBEESFTT
&OE
(0DNE
".
The Host sends the bytes as follows:
UART
Byte 1: 0x21 - command ID
Byte 2: 0xDE - complement
Byte 3 to Byte 6: the start address
Byte 3: MSB
Byte 6: LSB
Byte 7: checksum: XOR (Byte 3, Byte 4, Byte 5, Byte 6)
20/32
DocID027487 Rev 2
AN4656
4
Memory model
Memory model
The STLUX microcontroller has:

2-kByte RAM split to:
–
Short addressing zero page, 256 Bytes
–
16-bit addressing, 1.25 kbytes
–
Stack, 512 Bytes
–
(16-bit addressing, 2048 Bytes)

1-kByte data EEPROM

2-kByte boot ROM

32-kByte EEPROM split to:
–
32x4 Bytes interrupt vector
–
All remaining Host programming area
For more information see the STLUX family memory map in the specific device datasheet.
The STNRG microcontroller has:

6-kByte RAM split to:
–
Short addressing zero page 256 Bytes
–
16-bit addressing, 1.25 kBytes
–
Stack, 512 Bytes
–
(16-bit addressing, 6144 Bytes)

1-kByte data EEPROM

2-kByte boot ROM

32-kByte EEPROM split to:
–
32x4 bytes interrupt vector
–
All remaining Host programming area
For more information see the STNRG family memory map in the specific device datasheet.
DocID027487 Rev 2
21/32
32
Software model
5
AN4656
Software model
The boot code can download up to 128 byte at a time. The first 130 bytes of the RAM
(from 0x00) will be used to store the data coming from the serial interface, thus allowing the
boot using the stack. Moreover, other 26 bytes are used by the BL as temporary variables.
The RAM memory contains the Erase routine starting from 0x00A0 and the Write routine
starting from 0x0150; total memory space allocated for both routines is 304 bytes.
The usage of the stack is limited to less than 16 bytes for internal function calls with
the maximum nesting of three levels.
The Boot code does not use in any case interrupt functions, and all the internal devices are
handled in the polling mode.
Resuming, the RAM memory allocated by the BL is from 0x0000 to 0x01CF, plus 16 bytes
allocated before the default address of the stack pointer (0x07FF).
Note:
1. The peripheral (UART) used during the boot phase remains in power on when the user
leaves the boot to execute an application.
2. The ROM part not used from the bootloader (“empty”) shall be filled by 0x71 in order to
avoid that the BL falls in an infinite loop without any reset if it jumps into these “empty”
locations.
22/32
DocID027487 Rev 2
AN4656
6
Timing
Timing
This section reports some information about the timing of the bootloader. In order to use
correctly the bootloader is necessary to respect some temporal intervals as described in
following paragraphs.
After the hardware reset the bootloader goes in an initialization phase before going into the
synchronization phase. Therefore the user shall wait a time of at least 10 ms before sending
a synchronization message.
If the EEPROM memory has been at least once already programmed and the user wants to
reprogram it (see Table 6 on page 27) then he shall send the synchronization message
within 1 second from the hardware reset.
After a GO command the bootloader removes the Erase and Write routines from the RAM
memory before sending to the Host address. The time necessary to remove these routines
is about 150 s.
DocID027487 Rev 2
23/32
32
Error management
7
AN4656
Error management
Error management
Table 4. Errors
ERROR
CMD_ERROR
Description
Actions
If a denied command is received.
If an parity error occurs during its
transmission.
Sends NACK and goes
back to command
checking.
If an error occurs during its execution.
ADD_ERROR
If a received command contains a denied
destination address (see Table 5).
Sends NACK and goes
back to command
checking.
Table 5. Valid addresses
Device
32k
Note:
24/32
Memory
Address <15:0>
RAM
0000h → 07FFh (0FFFh or 017FFh)
DATA EEPROM
4000h → 43FFh
OPTION BYTES
4800h → 487Fh
PERIPHERAL REGISTERs
5000h → 57FFh
PROGRAM EEPROM
8000h → FFFFh
Table 5 depends on the specific device of the STLUX family. Please refer to the specific
device datasheet.
DocID027487 Rev 2
AN4656
8
Erase/Write EEPROM routines in RAM
Erase/Write EEPROM routines in RAM
There are some routines or a part of them that shall be downloaded into the RAM. They are:

Erase routine

Write EEPROM routine
The Erase routine shall be loaded into the RAM starting from 0xA0 whereas the Write
EEPROM routine is starting from 0x150. They are contiguous to the RAM.
The user can download them by Write commands in the RAM.
The routines are contained in an *.s19 file (E_W_ROUTINEs_STLux_ver_1.2.s19).
DocID027487 Rev 2
25/32
32
How to bootload your code to a STLUX device
9
How to bootload your code to a STLUX device
9.1
Introduction
AN4656
As previously said, the bootloader is stored into the internal 2 Kbytes boot ROM memory
and its main task is to download the application program into the internal program memory
through the UART peripheral. Data are provided by any device (Host) that can send
information through the serial interface. To avoid system locks due to application execution
errors (e.g.: the application jumps erroneously into the BL code), all the unused ROM
memory is padded with the hexadecimal value 0x71 that corresponds to an illegal opcode.
STLUX devices have a single UART peripheral which configuration may be switched to
different IO lines depending on the application requirements. The bootloader (BL) may be
configured either to use a specific UART configuration or to autodetect it.
The bootloading procedure is enabled by setting the option bytes OPTBL / nOPTBL
corresponding to the address 0x487E / 0x487F as specified in Table 6.
9.2
Bootloading in AutoDetect mode
The default configuration for the BL is the AutoDetect mode. In this mode, after the reset the
BL performs a polling in order to detect which channel is connected to a boot source via the
UART.
9.3
Bootloading with ST Flash loader demonstrator
Since the Flash loader demonstrator doesn't handle this AutoDetect mode, the bootloader
should be configured to check only the desired channel.
9.3.1
Configuring the desired UART channel
Setting the option bytes
To properly configure the UART boot source, the MSC_OPT0 and nMSC_OPT0 option
bytes must be modified so to indicate the proper UART source to be scanned during the
bootloading procedure. For the option bytes configuration, please refer to STLUX product
datasheets.
Writing the option bytes can be performed via the SWIM building a simple Raisonance
project with the declaration.

At 0x4815 CONST const. u16 MSC_OPT0 = 0x11EE;
this indicates the UART channel is OP0(0, 1) and the bootloader must check for this
channel only as a boot source.
The same thing can be performed via the SWIM with the IAR toolset - new release which
allows directly to handle the option bytes content.
26/32
DocID027487 Rev 2
AN4656
9.3.2
How to bootload your code to a STLUX device
Checking the memory content
In order to enable the bootloader, the Read-out protection for the EEPROM must be
disabled. So the address 0x4800h must be set to its default value 0x00h (brand new
devices are configured like that). If so, the loader can check the EEPROM content of the
0x8000h address as specified below and starts checking for boot sources according to the
UART channel configuration.
Table 6. Initial checking
Checks
EEPROM location
0x8000
EE check
Opt_byte
0x487E
EE check
Opt_byteN
0x487F
Actual EEPROM status
→ action
1st
Not 0x82 and not 0xAC
Don't care
Don't care
EE virgin → jump to BL
2nd
0x82 or 0xAC
0x55
0xAA
EE programmed booting
allowed → jump to BL
3rd
0x82 or 0xAC
Not 0x55
Not 0xAA
EE programmed booting
not allowed → jump to
EEPROM reset
If the EEPROM is virgin, then the bootloader waits for an indefinite time for a connection on
the set UART channel. If the EEPROM is programmed and the booling is allowed, the
bootloader waits for one second checking for a connection on the set UART channel, then
jumps to the code stored in the EEPROM.
So basically using a brand new STLUX device with the MSC_OPT0 option byte properly
configured to a single UART channel and a virgin EEPROM allows to easily download your
code through the UART connection with the Flash loader demonstrator.
9.3.3
Running the Flash loader demonstrator
Now you are ready to connect your PC with your STLUX device and run the Flash loader
demonstrator. The program Shell will appear.
DocID027487 Rev 2
27/32
32
How to bootload your code to a STLUX device
AN4656
Figure 13. Running the Flash loader demonstrator - step 1
Select the right COM port for the connection and push the NEXT button. Then a new menu
will appear.
Figure 14. Running the Flash loader demonstrator - step 2
28/32
DocID027487 Rev 2
AN4656
How to bootload your code to a STLUX device
Figure 15. Running the Flash loader demonstrator - step 3
Select as a target device for the connection the STLUX or STNRG, then press NEXT to
enter the next step.
Figure 16. Running the Flash loader demonstrator - step 4
DocID027487 Rev 2
29/32
32
How to bootload your code to a STLUX device
AN4656
Now to download your code, you need to choose “Download to device” and to give the
complete path and name of the file you want to download to the STLUX. The acceptable file
formats are *.bin and *.hex. When you set the proper file indications, press NEXT to start
downloading the code. You can follow the downloading process reading the bar in the next
shell. When the download will be complete, the Flash loader demonstrator will highlight it.
Figure 17. Running the Flash loader demonstrator - step 5
30/32
DocID027487 Rev 2
AN4656
10
Revision history
Revision history
Table 7. Document revision history
Date
Revision
15-Jun-2015
1
Initial release.
2
Updated the main title, added STNRG device to the
main title, Section : Introduction on page 1 and
Section 9.3.3: Running the Flash loader demonstrator
on page 27.
Updated Section 4: Memory model on page 21 (added
STNRG description).
Updated Figure 15: Running the Flash loader
demonstrator - step 3 on page 29 and Figure 17:
Running the Flash loader demonstrator - step 5 on
page 30 (replaced by new figures).
Minor modifications throughout document.
04-Dec-2015
Changes
DocID027487 Rev 2
31/32
32
AN4656
IMPORTANT NOTICE – PLEASE READ CAREFULLY
STMicroelectronics NV and its subsidiaries (“ST”) reserve the right to make changes, corrections, enhancements, modifications, and
improvements to ST products and/or to this document at any time without notice. Purchasers should obtain the latest relevant information on
ST products before placing orders. ST products are sold pursuant to ST’s terms and conditions of sale in place at the time of order
acknowledgement.
Purchasers are solely responsible for the choice, selection, and use of ST products and ST assumes no liability for application assistance or
the design of Purchasers’ products.
No license, express or implied, to any intellectual property right is granted by ST herein.
Resale of ST products with provisions different from the information set forth herein shall void any warranty granted by ST for such product.
ST and the ST logo are trademarks of ST. All other product or service names are the property of their respective owners.
Information in this document supersedes and replaces information previously supplied in any prior versions of this document.
© 2015 STMicroelectronics – All rights reserved
32/32
DocID027487 Rev 2
Similar pages