All of the following apply to the normal NNDK devices and not the MOD5213 or the SBL2E families.
compcode takes the xx.s19(1) converts* it binary image(2)... compresses that into a binary(3) then writes that back out in srecord format xx_app.s19(4).
Autoupdate reads the compressed srecord xx_app.s19(4) and converts it into the compressed binary (3) it then sends this (3) to the device.
The autoupdate code in the device receives the compressed binary (3) and then writes it unmodified into flash....
The boot monitor takes the compressed image (3) stored in flash and decompresses this into RAM yielding the original binary image (2)
The boot monitor then jumps to the start location in (2) and application execution begins there....
The ONLY place that compresses is in compcode.... all of the conversions are to/from srecord and binary.
The ONLY place that de-compresses is in the boot monitor.
The reason we use s19 format is that it can get emailed, transfered, FTP'ed, HTTP put, etc without it being modified.
Moving true binary files around is problematic.
While we could have use a more efficient record format like UU encode the S19 lets you compare file contents with what you can read out of memory using monitor tools.
*To be 100% correct compcode also pre-pends a BigEndian structure to the front of the compressed image that includes both compressed and uncompressed sizes, start address and final decompressed checksum for integrity checking purposes. The monitor uses this to make sure the decompressed image is valid.
To be 100% complete there are actually several additional ways to get code into flash.... examples of all of the following are in the NNDK examples.
Autoupdate (the standard library way described above)
TcpUpdate Identical to autoupdate, but uses a TCP connection for more firewall robustness.
Ftp update(s), the device either initiates or receives an FTP transfer for the _APP.s19 file and conversion from format (4) to (3) before writing to flash
occurs on the device.
HTTP Post here the device receives an HTTP file post in format (4) and converts it to (3) on the device before writing to flash.
Device reads format (4) from an SD card converts to format (3) and writes to flash.
Serial downloads to the monitor over the serial port (sends format (4) over the serial port and converts to (3) internally before writing to flash.
Specialized custom schemes also exist, such as checking a web site looking for updated images. (No standard example, but its been done in several custom configurations)
How To Count Memory
Re: How To Count Memory
Thank you for your terrific efforts to help straighten this boy out.
So, "naturally", textual (4) is much larger than binary (3), even though they are the same image, just in two different formats; and THAT'S why my 527 kB file (4) fits inside the processor as 175 kB (3)?
[Edit: For future reference, (3) & (4) are both compressed versions of the executable image, which is stored on the hard drive as (1).]
So, "naturally", textual (4) is much larger than binary (3), even though they are the same image, just in two different formats; and THAT'S why my 527 kB file (4) fits inside the processor as 175 kB (3)?
[Edit: For future reference, (3) & (4) are both compressed versions of the executable image, which is stored on the hard drive as (1).]
Last edited by kackle123 on Thu Feb 12, 2015 7:07 am, edited 1 time in total.
Re: How To Count Memory
Yes exactly correct, S19/text is bigger than binary, even though they represent the same exact thing.