joepasquariello
Member

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...

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...

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...

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

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.

All Teensy hex files seem to have those lines. The IntelHex program does the same "fix" that you did manually. It is based on a C file (ihex.c) written by Paul, with just a couple of small changes that I made, plus my...

The address field in the intel hex format is 16 bits, so the max is 65535. For files larger than 64K, additional record types come into play that specify "base address", and the 16-bit address field becomes an offset to...

Yes, you're right, IntelHex is currently limited to 64K. I'll have to modify it to handle larger files. Please provide the info about your target and your build environment. If you're using a build environment other...

I did a little more digging, and to clarify, for all T3.x, the 16 bytes from 0400 to 040F are set aside as "flashconfig" in the linker files (*.ld). File mk20dx128.c in cores\teensy3 defines those 16 bytes as shown...

I just repeated my tests with T3.2, T3.5, and T3.6, and in all 3 cases, I get a match on the FSEC field between upper (new program) and lower (existing program). The program size limit is 1/2 of the flash size, so 128K...

Okay. This is the set of conditional defines you need to add to your program, than add the Serial.println(FLASH_ID); #if defined(__MK20DX128__) #define FLASH_ID "fw_teensy3.0" #elif...

You just need the #define FLASH_ID "fw_teensy3.5", and then you need to make sure that string gets used within your program. What I suggest is adding a line in your setup function that says Serial.println( FLASH_ID ); ...

For T35/T36, you must use the IntelHex.exe to convert from 32-bit aligned records to 64-bit aligned. That will avoid the "align error". Any application you upload must contain the appropriate ID string, e.g....

This is a limitation of using a terminal emulator to send an ASCII hex file. There is no error checking except the record-level checks within the target. I can write a very simple command-line program to send a hex...

Hi Jon. Yes, what the Flasher program is doing now (and has always done), is report the number of valid lines received. If it receives any invalid lines or, in the case of T35/T36, it receives a line that is not...

I use Teraterm, and it works, though I can't say I'm crazy about it.

After you see those messages, you need to type in ":flash XXXX", where XXXX is the number of lines reported by the program, and then hit Enter. When you hit Enter, as long as you have typed in the ":flash" command...

Thanks very much. I like the option of a text display.

iniitu, that looks great. Would you mind providing a short summary of your connections and the working code?

Flasher3b.zip is attached, with improvements from Flasher3a and has been 100% reliable on many updates of T32/T35/T36. I was having trouble with T3.6, and after a lot of trial-and-error, added code to disable LMEM code...

Thanks, Paul. Good to know. I'll experiment by decoupling the file transfer from the flash writes and see if I can figure out why doing Serial.print/flush after each record seems to fix it.

Yes, or at least make it clear that firmware upload requires a "shutdown" of the application. Can you comment on whether disabling HSRUN might affect file transfer via the USB serial?

The attached file Flasher3a.zip contains an update to jonr's "flasher" for T32, with support for T35 and T36. The primary change relative to flasher is addition of a flash_phrase() function to write to flash in 64-bit...

Continuing to work on Flasher for T35/T36. As dahollen mentioned, flash operations are not reliable with high-speed mode enabled. The NXP reference manuals are clear that high-speed mode is not supported for flash...

Something a little different about T35 and T36. The simple test of erase/write/read at the beginning of the program works fine, but the hex file transfer via TeraTerm seems to be failing. There are no error messages...

Okay, thanks. The original flasher keeps interrupts disabled from the the beginning of stage 2 (moving upper to lower) through the reboot. I'll keep it that way.

jonr, I'm working on integrating dahollen's flash routines for T35 and T36 with your flasher program, and I have a few questions. (1) In flasher, you specify RESERVE_FLASH for T31 and T32. Is this meant to be an...

Ah, light dawns on Marblehead. Thank you. I thought the 2MB of flash on T4.0 was on-chip. Now I understand there is only the external serial flash, 2MB for T4.0, 8MB for T4.1. How interesting. I need to read up on the...

Thanks, Paul. I'm still unclear on why the T4.1 page says it has 8 MB of flash and not 2+8 = 10 MB. For code space, it has the same 2MB on-chip flash as T4.0, plus the 8MB U3 for EEPROM + future stuff?