Question on .bin file format for smartphone OTA updates via

sentinel · Joined: 02 Feb 2009 Posts: 141 Location: Tasmania

Can anyone be so kind as to clarify how a binary file needs to be processed when it is received by the main firmware program prior to saving in external I2C EEPROM?

From an examination of the Bootloader.bas code, the loader routine looks for an initial received byte value of 123, whereupon it jumps to the flash loader routine.
It then waits until it receives a zero, then erases the first page of flash memory.

When a 1 is received, this indicates the heading.
The next 2 bytes are the block number and the checksum 1st byte.

The following 128 bytes are saved to an array, then, if the block number and checksum match the calculated ones, the array is written to flash memory, before looping to load the next block. This would be looped 125 times for a 16kB file.

So, what I need to know, before modifying this loader into one that diverts the .bin file to external I2C EEPROM is this - what modifications does the PC make to the compiled .bin file before sending it to the MCU loader?

Am I correct in thinking that the 123 byte, the Kind byte (0), the following zero byte, the heading byte (1), the block number byte, the checksum first byte, then after the following 128 bytes of binary code, the second checksum byte, are all calculated and added by the PC?

If this is the case, then I will need to write Android and iOS apps to split the .bin file into 128 byte chunks and add these extra bytes before sending eack block one by one by Bluetooth.

(BASCOM-AVR version : 2.0.8.5 )

i.dobson · Posted: Mon May 02, 2022 4:22 pm Post subject:

Hi,

The standard MCS bootloader/PC application uses the XMODEM protocol to transfer the program code, if I remember correctly.

Regards
Ian Dobson

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

xmodem-crc and as the original version with BYTE checksum.

see also : http://web.mit.edu/6.115/www/amulet/xmodem.htm
but do not use crc but byte checksum. checksum is just adding all bytes.

the 123 is just used by MCS. the C could have been used, or you can use anything to trigger the actual tranmision.
and you can also throw your own procedure and checksums.

sentinel · Joined: 02 Feb 2009 Posts: 141 Location: Tasmania

Thanks Ian and Mark.

That link explained things very clearly. Now I know how to proceed.

I would like to also use the external EEPROM as if it is internal EEPROM through the use of

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

when using the lib to override the internal ERAM/EEPROM, you can not change the address. the first starting address is 0.

how i usually do this :
- use some eeprom that has sufficient size
- in the normal app code, get the data and put it into this eeprom
- when the data is complete and ok, set a flag.
- on start/boot check this flag
- when the flag is set, just perform the copy from the eeprom to the flash.

the advantage is that this way you can use any of the resources (ethernet, BT, serial, usb , etc) to get the data. but the actual boot loader is still small and simple.

also, create a copy of the initial firmware and when a user pres a button at boot, you can copy this original copy into flash

sentinel · Joined: 02 Feb 2009 Posts: 141 Location: Tasmania

I was not suggesting changing the address of the lib, but rather the address in the external EEPROM of the downloaded data which will be loaded into flash at boot time.

So, the lib would use memory starting at &H0000 as normal and the data downloaded over BT would be saved in memory starting at &H8000.

The bootloader would copy this data from the eeprom at &H8000 to the flash when rebooted.