Micromod + Teensyduino firmware upload question

[UHF]

Sorry if this is a silly question. Why do I always need to push a button or bridge the boot pad to ground when uploading a firmware hex file to a Teensy Micromod using the Teensyduino loader app, but it's automatic when using PlatformIO/Arduino IDE?

Thanks.

 

[defragster]

The "automatic when using PlatformIO/Arduino IDE" is by design where those apps trigger the upload.

The Teensy Loader App is 'passive' when active and 'pointed to a HEX' file it is ready.

The button or the IDE's trigger the Teensy which activates the Loader app.

In the IDE doing a Verify build creates a HEX and (starts if not open and) passes the path to the Loader - but the Loader passively waits in that case - as is normal. Just because the loader has a HEX it won't repeatedly upload it until triggered.


Question: If not 'using PlatformIO/Arduino IDE' - what leads up to 'need to push a button or bridge the boot pad' when an upload is desired?

 

[UHF]

Question: If not 'using PlatformIO/Arduino IDE' - what leads up to 'need to push a button or bridge the boot pad' when an upload is desired?

Thanks for the reply. An end user of a product wanting to flash updated firmware using the Teensyduino loader, needs to access the Teensy to initiate the upload, unless using an IDE.

 

[CollinK]

Yes, that's a limitation with how the default Teensyduino loader works. However, there is a command line firmware uploader: https://github.com/PaulStoffregen/teensy_loader_cli That source code will compile and result in a command line tool you can use for flashing. Unfortunately, it doesn't entirely do the automatic updates either. I merged together some changes other people did plus some code I wrote to fix "soft reset" on Windows and Linux: https://github.com/collin80/teensy_loader_cli

With my version you can ask the board to reset itself and flash automatically from either Windows or Linux. I never got MacOS to work that way.

I was also interested in the same thing as you: being able to send something to an end user and have them flash firmware without needing to compile it themselves or do anything complicated.

You'll note that I don't have binaries on the github page. I wasn't entirely sure what the view is on custom teensy loader binaries. Usually people want to use official PJRC binaries but they don't currently have a command line binary that works properly to do soft resets so that you don't have to push any buttons. But, the code as posted should compile fine on both Windows and Linux if you follow the directions. Then you have your own freshly built binaries you can provide to customers along with a simple script to run the binary with the proper files to flash.

 

[UHF]

Thanks very much. I would like this to be a feature on the Teensy Loader. I wish the Teensy platform was more geared towards finished products, rather than hobbyists and one-offs. I can put a button on my product and a 'firmware flash' hole, but if a change to the software can be made, that would benefit all of us.

 

[joepasquariello]

Thanks very much. I would like this to be a feature on the Teensy Loader. I wish the Teensy platform was more geared towards finished products, rather than hobbyists and one-offs. I can put a button on my product and a 'firmware flash' hole, but if a change to the software can be made, that would benefit all of us.

You might be interested in the link below. FlasherX is code that you can include in your application to allow firmware updates over any connection (USB, UART, Ethernet, etc.). The concept is to buffer the new firmware in unused flash (or RAM for small programs in T4.x). When the entire new firmware is in the buffer, the "flash_move" function (executing in RAM) erases the existing firmware, copies the new firmware from the buffer to the flash base, erases the flash buffer, then reboots Teensy. The example program lets you transfer a hex file containing the new firmware via USB or UART, or read a hex file from SD. For my own projects and products, I provide users with a custom UI that communicates with the Teensy to do the update via UART, and I built a protocol to command the Teensy to "enter flash mode", "receive firmware", "confirm", "update", etc.

https://github.com/joepasquariello/FlasherX

 

[UHF]

Thanks, that's interesting. Yes, I've got an SD card slot which can be checked at boot-up for a hex file and it can update itself. Better than getting users to install apps.

 

[UHF]

Hello, is there somewhere I can ask questions? I'm getting the following:

created buffer = 0K FLASH (60FFC000 - 60FFC000)
++++  Firmware update   ++++
reading hex lines...
abort - max address 60000010 too large

I'm trying to flash a 1.2MB firmware file, I'm sure the 0K FLASH part is the problem!

 

[houtson]

@UHF - I use the micromods.
I use TyUploader for user firmware updates - I only have to very occasionally do the boot button otherwise it happens as expected. If you can I'd recommend breaking out the boot button as useful if thing get really screwed up and it needs a complete reset.

 

[joepasquariello]

Hello, is there somewhere I can ask questions? I'm getting the following:

I'm trying to flash a 1.2MB firmware file, I'm sure the 0K FLASH part is the problem!

You can ask questions here. Are you running the example program or have you added FlasherX to your own application? If it's your own application, are you using EEPROM or LittleFS? Those two features use upper Flash, so in the FlasherX file FlashTxx.h, you should increase FLASH_RESERVE from (4*FLASH_SECTOR_SIZE) to (64*FLASH_SECTOR_SIZE). If that doesn't fix it, please tell us more about what you're doing.

 

[UHF]

@houtson - Thanks very much, I'll take a look.


@joepasquariello - Yes I'm using EEPROM emulation. I made the change and it's got this far:

SDClass::setMediaDetectPin(27)SD card is connected
target = fw_teensyMM (16384K flash in 4K sectors)
created buffer = 15640K FLASH (6007A000 - 60FC0000)
++++  Firmware update   ++++
reading hex lines...

hex file: 27916 lines 446464 bytes (60000000 - 6006D000)
abort - new code missing string fw_teensyMM
erase FLASH buffer / free RAM buffer...

Where is this string expected to be in the new firmware?

Also, can user input be bypassed? I want it to just happen at boot-up:

// get user input to write to flash or abort
  int user_lines = -1;
  while (user_lines != hex.lines && user_lines != 0) {
    out->printf( "enter %d to flash or 0 to abort\n", hex.lines );
    read_ascii_line( out, line, sizeof(line) );
    sscanf( line, "%d", &user_lines );
  }

 

[joepasquariello]

Where is this string expected to be in the new firmware? Also, can user input be bypassed? I want it to just happen at boot-up:

The string can be anywhere. The easiest way to make sure it's in your code is to #include "FlashTxx.h" and add the statement Serial.println(FLASH_ID). Without the println(), the compiler will optimize out the string. Yes, user input can be bypassed. I'm guessing that you have the FlasherX example running on your Teensy and you have your own hex file on the SD card. That will work if you add the FLASH_ID string to your own application, or you can try putting the FlasherX example hex file on the SD card. For your "production" solution, you need to add FlasherX to your application, and you can decide how you want to handle the update process via SD.

 

[CollinK]

If you want to take a look at an existing program that uses FlasherX to do firmware updates from SDCard you can look at my code here: https://github.com/collin80/GEVCU7

Unfortunately, it may not be the simplest implementation. It is meant to be a primary vehicle control unit after all. But, it does firmware updates of a Teensy MM from sdcard without the user having to do anything. You just put the card into the slot and boot up.

 

[UHF]

@CollinK - Thanks that's very useful.

 

[UHF]

@CollinK - I'm using your code without any changes except to

#define FLASH_SIZE (0x1000000)                 // 16MB
and
#define FLASH_RESERVE (64 * FLASH_SECTOR_SIZE) // reserve top of flash

in FlashTxx.h, which was (wrongly?) 8MB

I have the following output. The firmware is seen and read from the SD card, it has the correct targetID, the firmware is deleted from SD card, flashing takes place and finally the TeensyMM attempts to reboot (could be a crash?). The new firmware doesn't appear to have correctly flashed and I have to recover by reflashing by activating boot and using Teensy Loader.

++++  Firmware update   ++++
target = fw_teensyMM (16384K flash in 4K sectors)
buffer = 15640K FLASH (6007A000 - 60FC0000)
waiting for hex lines...
Write Block flash_write_block 1611112448
Write Block flash_write_block 1611112452
Write Block flash_write_block 1611112456
Write Block flash_write_block 1611112460
... lines removed
Write Block flash_write_block 1611604976
Write Block flash_write_block 1611604980
Write Block flash_write_block 1611604984
Write Block flash_write_block 1611604988

hex file: 30800 lines 492544 bytes (60000000 - 60078400)
New firmware contains correct target ID fw_teensyMM
Delete firmware from SD card: firmware.hex
Erase Sector flash_move 1610612736
Write flash_move 1610612736
Write flash_move 1610612740
Write flash_move 1610612744
... lines removed
Write flash_move 1610659012
Write flash_move 1610659016
Write flash_move 1610659020

Any thoughts would be gratefully received. Is any routine being missed during the flashing process?

 

[defragster]

...
Any thoughts would be gratefully received. Is any routine being missed during the flashing process?

Have not worked with current Flasher code at all - but that 8MB limit on 16MB Flash may be to assure that at least HALF of the flash is reserved for the process? And to locate the start point for the load area?

Years back on T_3.2 - did test with Frank B on his software flashing that worked and halves were smaller back then.

 

[joepasquariello]

Have not worked with current Flasher code at all - but that 8MB limit on 16MB Flash may be to assure that at least HALF of the flash is reserved for the process? And to locate the start point for the load area?

Years back on T_3.2 - did test with Frank B on his software flashing that worked and halves were smaller back then.

The latest FlasherX version has the correct 16MB value as shown below. This value is meant to represent entire flash, not a maximum buffer size.

#elif defined(__IMXRT1062__) && defined(ARDUINO_TEENSY_MICROMOD)
  #define FLASH_ID		"fw_teensyMM"		// target ID (in code)
  #define FLASH_SIZE		(0x1000000)		// 16MB
  #define FLASH_SECTOR_SIZE	(0x1000)		// 4KB sector size
  #define FLASH_WRITE_SIZE	(4)			// 4-byte/32-bit writes    
  #define FLASH_RESERVE		(4*FLASH_SECTOR_SIZE)	// reserve top of flash 
  #define FLASH_BASE_ADDR	(0x60000000)		// code starts here

 

[defragster]

The latest FlasherX version has the correct 16MB value as shown below. This value is meant to represent entire flash, not a maximum buffer size.
...

Thanks - good to know.