'Over the Air' firmware updates, changes for flashing Teensy 3.5 & 3.6

[jonr]

It would be really nice if the flasher code could directly accept any .hex lines it is likely to receive.

[joepasquariello]

Agree, Jon. That's at the top of my list for the next update to Flasher. Better to integrate what I did with IntelHex directly into Flasher.

[Frankthetech]

I working on this some more and looking into the code compiled I see this about middle of the code (about 129k total code size)

:10FFE000704700BF18EA0100054A02608A7D02716D..
:10FFF000CA7D42710A7E82714A7EC271704700BF1B..
:020000021000EC.. :1000000018EA0100064A02608A7
F0271CA7F4271C3..
does the compiler do this and is there any way to tell the compiler not to do this?
This happens twice in the 129k code block.
I can't manually fix this as it would mess all the following address's, off by 2 in this case.
Unless all the following address jumps are by reference and not absolute.

[jonr]

Don't worry about the ":02 0000 02" lines, they aren't code values. But for now, do manually combine any ":04 XXXX 00" lines.

[Frankthetech]

I was able to get it working. Flasher3b has no problem with 130k code size. uploaded and works.
Thanks for all the help!
Still some more to do, make code with the flasher and test.

[joepasquariello]

Thanks for letting us know, Frank. I will update IntelHex to handle larger files so that you don't have to hand edit.

[joepasquariello]

Flasher3c.zip is attached. This update accepts the as-built Teensy hex files and so avoids the need to pre-process to get 64-bit aligned hex records for T35/T36. The differences from Flasher3b are (a) flash and LMEM functions are broken out into a separate file (FlashT3x.cpp/h), and (b) the flash_block() function in FlashT3x.cpp has new static variables and logic to buffer bytes in T35/T36 hex records so that all flash writes are 64-bit aligned. The logic is based on the following observations of Teensy hex files:

- all hex records are 32-bit aligned
- all hex records are sequential, i.e. there are no address "gaps"
- if the last 32-bit word is on a 64-bit boundary, its value is always 0xFFFFFFFF

flash_block() confirms the first two conditions. Assuming all are true, flash_block() needs to buffer either 0 or 4 bytes. If 4 bytes from the previous record have been buffered, the new bytes are appended, the write address is decremented by 4, and as many 64-bit phrases as possible are written. If 4 bytes are left over, they are retained for the next pass.

Frank, give this a try with your large hex file and let us know how it goes. As long as the upper/lower FSEC fields match, it should be safe to do the flash update.

[Frankthetech]

Great stuff! It works with my file 8120 lines x 16 bytes = 129920 bytes code size flashed with no problem.
Code seems to work as expected, will test and report.
Joe thanks for making this work. now we have a way to do updates remotely.

[joepasquariello]

Thanks for letting us know, Frank. That's good news. I'd like to understand why the hex files always have the same pattern of record lengths ...16,16,16,8,4,16,16,16... There must be reason those records of length 8 and 4 always occur. It's the 4-byte record that moves all subsequent records off of the 64-bit boundary. If that can be "fixed" via the the linker file or something in the code, it would be well worth the cost of 4 bytes of padding.

One correction I wanted to mention from my previous message. I don't think they occur, but address "gaps" are okay as long as they occur between hex records and on a 64-bit boundary. For example, if the first hex record defined addresses 0-15, and the second skipped ahead to 32-47, that would not be flagged as an error. An error occurs if there are 4 bytes in the static buffer, waiting to be written, and the record that follows does not define the bytes immediately following those in the buffer.

[joepasquariello]

The hex lines below from a T3.6 hex file show the 4-byte record at AD78 that breaks the 64-bit alignment. Further below are lines from the symbol file. AD78 is .fini (language cleanup code), which is followed by arm.exidx, which has something to do with the exception table. I experimented with specifying 8-byte alignment, but it causes linker errors. I'm going to leave this alone.

:10AD60005FF800F0D109FF1F5FF800F05109FF1FE5
:08AD7000815B000035040000C6
:04AD7800F8B500BF6B
:08AD7C0068F3FF7F01000000F5
:10AD840072B60D4B41221A7003F8010C073B802266

SYMBOL TABLE:
00000000 l d .text 00000000 .text
0000ad78 l d .fini 00000000 .fini
0000ad7c l d .ARM.exidx 00000000 .ARM.exidx

[Frankthetech]

Ya I get that kind of break up too.
The first two 0x08 and 0x04 are easy to combine. but at only 12 bytes would need to grab 4 bytes from the next line too. just need to compute the right checksum.
:04 AD78 00 F8 B5 00 BF 6B line is going to write 0xBF to AD7C and the next line
:08 AD7C 00 68 F3 FF 7F 01 00 00 00 F5 looks like it will over write AD7C with 0x00, strange I thinks.
Need to figure out how the compiler does this. It's just me 'need to know syndrome'
No biggie as your flasher3c works like a charm. We're go to good.