where to start with bootloader/firmware update

[Xarion]

Hi Guys

I am using an S08QE32 connected to a GSM engine and and external EEPROM. I can manage to get my S19 file downloaded through GSM and put onto the EEPROM (which I access through SPI)

Basically I need to now transfer that S19 file so that I can update the firmware on my device.

Now I see there is quite a bit on the serial bootloader which is kind of down my line so I just need a few pointers in the right direction so I just have a few questions

1) In order for me to flash I need to make use of the doonstack files provided - This is stored in RAM which will allow me to write to where my user code. Which part in the doonstack ASM file says that it is stored in RAM?

2) In order for me to read from the EEPROM (via SPI) would I need to store my SPI routines in RAM too?

3) Is there some code that can interpret the S19 file in a way that allows me to reflash my device, or perhaps it would be easier to restructure the S19 file before sending over the air?

Thanks

Xarion

[bigmac]

Hello Xarion,

Xarion Comoretto wrote:

3) Is there some code that can interpret the S19 file in a way that allows me to reflash my device, or perhaps it would be easier to restructure the S19 file before sending over the air?

It is better to send the S19 file over the air because this has an ASCII text only format, and each line contains a checksum value for some measure of error detection.  The incoming data should be checked line-by-line for any checksum error, before each record is stored in EEPROM.  Storing the data as incoming S19 records will require an EEPROM size about 2.5 times the maximum program size.  However you can repack each character pair to a single byte within the EEPROM, to halve the size.  The overhead for each program data record consists of record type, record size, start address and the final checksum byte.  For the QE32 device, only the S2 records, with 16-bit addresses, would be of interest.

It would alternatively be possible to treat the EEPROM as a direct image of the program space within flash (with a fixed offset value).  The data within each program data record would be placed at the correct location within the image, as it is received.  This would imply that the whole image would need to be programmed into flash irrespective of the actual program size.

Xarion Comoretto wrote:

2) In order for me to read from the EEPROM (via SPI) would I need to store my SPI routines in RAM too?

If using byte-by-byte programming, you would simply read each data byte from EEPROM, and then immediately program the value at the required address.  However, if using burst mode programming of each flash row (slightly shorter programming time), the approach would be to store all the data from the particular record within a RAM buffer, prior to programming flash.  Burst programming will require greater RAM resident code size than byte-by-byte programming.

Xarion Comoretto wrote:

1) In order for me to flash I need to make use of the doonstack files provided - This is stored in RAM which will allow me to write to where my user code. Which part in the doonstack ASM file says that it is stored in RAM?

Using the "doonstack" method means that the RAM resident code is temporarily loaded to the stack (in RAM), and executed from there.

Regards,

Mac

[Xarion]

Hey bigmac, thanx for the quick reply.

With regards to my second point... If my function to read from SPI and flash my device is resident in the ROM, I could run the risk over overwriting it, which is why I thought that I would need to store the function in RAM. or perhaps allocated it at a specific place in ROM that cannot be over written? This lead me to my second question to ask how function are declared to run out of RAM, "doonstack" was just the file name so I was looking inside teh code to see how it was defined.

I think I will pack the ascii received over the air into the EEPROM, this will be more efficient, besides, i'm going to have to eventually convert it in the end before flashing, right?

Would reprogramming directly from this S19 file also take care of the interrupt vectors? (I would obviously have to disable all interrupts while flashing so that I do not get interrupted while doing so)

Thanks again! :smileyhappy:

[bigmac]

Hello Xarion,

Xarion Comoretto wrote:

  With regards to my second point... If my function to read from SPI and flash my device is resident in the ROM, I could run the risk over overwriting it, which is why I thought that I would need to store the function in RAM. or perhaps allocated it at a specific place in ROM that cannot be over written? This lead me to my second question to ask how function are declared to run out of RAM, "doonstack" was just the file name so I was looking inside teh code to see how it was defined. 

The bootloader program should be entirely separate from from the application program, and would be placed at the top of flash memory.  The bootloader memory block should be write protected, and the SPI functions would obvioulsy reside within the bootloader.  The bootloader code would alway be programmed using Multilink BDM interface.

The "doonstack" assembly code routine pushes each byte of the RAM resident flash programming routine to the stack.  It then executes this routine from the stack, and when completed, the stack pointer is adjusted to recover the memory occupied by the routine.  The doonstack routine itself does not reside in RAM.

Would reprogramming directly from this S19 file also take care of the interrupt vectors? (I would obviously have to disable all interrupts while flashing so that I do not get interrupted while doing so)

The application program vector table will need to be relocated to a non-protected position immediately below the bootloader.  Access to this vector table will need to be redirected, either automatically, or under the control of the bootloader.  Automatic redirection, when available for the particular MCU type, can be used when the bootloader itself does not use any interrupts.

In the event that the incoming S19 file does not relocate the vector table to the redirected position, the bootloader should be able to detect this situation, and automatically program the vector data to the shifted location.

Regards,

Mac

[Xarion]

Hey bigmac

Thanks for the advise, my head is still spinning, there are a lot of things that I cant translate from my 8051 knowledge to the S08... like how on earth can you move an interrupt vector table, I would think the uP would always jump to a certain point in memory for the interrupt?

How can this be moved?

In my bootloader I would write bit-banged SPI code so that I do not need to rely on the interrupts right?

I'm also battling to find the correct syntax to declare my function @ a certain memory location..

My prm file has the following declaration

    ROM                      =  READ_ONLY    0x8000 TO 0xFFAD;

This would mean it would be good to place this spi code at 0x8000?

Thanks again for the help, sorry for the delay, newborns tend to take over one's life :smileyhappy:

Xarion

[bigmac]

Hello Xarion,

Congratulations!

The bootloader code, including the SPI functions, woud occupy a separate block of memory at the top of flash memory.  Above this block would be the normal location for the vector table (0xFFC0-0xFFFF).  The usual requirement is that the bootloader code be write-protected.  This will mean that the vector table will also be write protected.  Refer to section 4.5.6 of the Reference manual for the device.

To overcome an obvious problem for the application code vector table, many of the devices provide for automatic vector redirection, as described in section 4.5.7 of the Reference manual.  If enabled, the occurrence of an interrupt will fetch the ISR vector from the redirected location within the unprotected flash block used by the application code, instead of the normal location.

For example, if a block of flash memory starting at 0xFC00 were allowed for the bootloader code, the memory from 0xFC00-0xFFFF would be write protected.  The redirected vector table would then be located from 0xFBC0-0xFBFD (the reset vector is not automatically redirected).  The bootloader would be responsible tor translating the application vector table data within the S19 file, to the new location.

Since the device has a SPI module, use this instead of bit-banging.  For a SPI master, it is rarely necessary to use interrupts - the flags would normally be polled.

The bootloader would be handled as a separate project, and would have its own PRM file that would define the flash block used.

   ROM                      =  READ_ONLY    0xFC00 TO 0xFFAD;  // For the above example

The linker would then allocate the address of each bootloader function within this block.  There is normally no need to allocate a function at a specific address.

Regards,

Mac