4.0 Restore Program Question

bigboosted

Well-known member
Recently with help here, I was able to build a program that update's the 4.0 from can instead of USB. So far it is working extremely well with only 2 downsides that I'm aware of.

1. I can only use half the program space. (not a big deal to me)

2. If power was lost or a bad file was loaded there is no recovery as the teensy would be potted in my project, no USB or button available. (This is a big deal for me)
I could implement a magnetic switch of some kind to act as the button but I prefer not to.


My first thought was to build a small file and stick it in the Restore Program location. But I quickly found out this area is locked as read-only, and even a blank sketch for a 4.0 compiles at over 10k bytes.

My assumption is that the bootloader chip copies this restore program to the lower area so somehow making this area bigger is a no go.
Also, my understanding is this area has an irreversible fuse set to make it read-only.



Does anyone know where the first instruction is located at power up? Is there a pointer to tell it where to start?

I have a few ideas in my head but not sure how to make them work. Thanks for any help!
 
My guess, is this is something you will need to experiment with and see what works and what does not...

My assumption, is that the main entry point is the ResetHandler, as set in the bootdata.c and code in startup.c

If it were me, I might try something like, is it possible, to have your two sub-images and a main root image, and see if you can make that root image to be such that it can not be overwritten by itself?

Again I don't know if this can work or not... But for example in the imxrt1062.ld
Is it possible to change the section:
FLASH (rwx): ORIGIN = 0x60000000, LENGTH = 1984K

To be two sections, like:
FLASH (rwx): ORIGIN = 0x60000000, LENGTH = 1536K
FLASHXO (x): ORIGIN = 0x60180000, LENGTH = 448K

And could your main line code, which I assume does the validation of the two images to see if one is valid or not and chooses the appropriate one, and also handles the downloads, be setup to be in the execute (which may also have the R bit as well)?

I would assume you would need to update linker script and the like to allow new section tag...

But again I have no idea if this could work or not. Obviously if I could get the system to properly load this over USB, one of the first tests would be to see what happens if your code tries to overwrite this section.

I would also probably also setup my code to hopefully be able to intercept some of the unhandled exceptions, and maybe do something like mark that upload as bad?

But again only throwing out suggestions, that may or may not help.
 
Thanks for the reply Kurt I'll look into that. I think that's beyond my skill level but I kind of understand what your saying.

I keep thinking about this Restore program. I was thinking sooner or later Paul will make the bootloader chip available for the 4.0 and when that happened I could populate a W25Q16JVUXIM that is not partially locked. I could then build my own 4K restore program. But the fact that a blank sketch compiled to use the smallest code is still over 10k bytes confused me. How did PJRC build a 4k program?

I decided to poke around and see. I directly copied this 0x1000 program to 0x60000000 and guess what no blinky.
That leads me to believe the bootloader does something or adds something to this as it copies it.

So I started looking at the Hex files and noticed the area from 0x60000200 to 0x60001000 is all 0xFF (Blank)
I tried copying the first 0x200 bytes of the restore program to 0x60000000 then the remaining 0xE00 bytes to 0x60001000 and we have Blinky!!
The restore program is 0x1000 bytes but once moved to 0x60000000 it actually takes up (0x1000 + 0xE00) or 0x1E00 or 7,680 Bytes

Unfortunately, this is still less than the +10K byte blank Sketch. But perhaps if I dig into the Startup.c and other files I can cut out the USB stuff and anything else not needed and build myself a restore program that I need.
 
How did PJRC build a 4k program?
....
But perhaps if I dig into the Startup.c and other files I can cut out the USB stuff...

Yup, pretty much like that.

Several functions in usb.c are not needed if you only do USB control transfers (never bulk, interrupt, isochronous). If you don't use USB at all, you can delete all of it, but the restore program listens for a HID set feature control transfer. If you leave the CPU at its default 396 MHz speed, you can get rid of the huge function which changes the clock speed.
 
Thanks, Frank, I do check my upload. But things happen and I would like a way to recover if something happens.
Trying to avoid bricking my several hundred dollar gizmo.

That's the trick. With a valid, verified CRC you can be sure the upload was OK. If you do it right, there is no way that something happens.
And even then, in the absolutly worst case, you have the 15 second restore - and I wouldn't overwrite that default. Because the default is tested and you can be sure it works. With own program, you risk exactly that - to "brick" it.
 
That's the trick. With a valid, verified CRC you can be sure the upload was OK. If you do it right, there is no way that something happens.
And even then, in the absolutly worst case, you have the 15 second restore - and I wouldn't overwrite that default. Because the default is tested and you can be sure it works. With own program, you risk exactly that - to "brick" it.

The erase and copy is several seconds long. A power issue during this time period could cause issues right?
 
Yup, pretty much like that.

Several functions in usb.c are not needed if you only do USB control transfers (never bulk, interrupt, isochronous). If you don't use USB at all, you can delete all of it, but the restore program listens for a HID set feature control transfer. If you leave the CPU at its default 396 MHz speed, you can get rid of the huge function which changes the clock speed.

Great information Paul. Thanks!
 
The erase and copy is several seconds long. A power issue during this time period could cause issues right?

AFAIK, the erase is controlled by the Bootloader chip. If erase phase is interrupted, I guess, it can be repeated as often as one wishes (TBC by Paul)
 
I have interrupted upload/restore - the flash is left blanked or un bootable to sketch and fixed with normal button press upload or repeat of 15s Restore.

As configured those mechanisms are still functional.
 
If you lose power during the restore process, you can always just start it again and let it finish.

But usually the first fraction of a second of the restore process is enough to get your Teensy able to respond to a normal button press. Odds of actually needing to redo the full restore process are slim.

However, if things have gone very wrong on the PC side, completing the restore process and seeing the orange LED start blinking is a really valuable experience. Then you know Teensy is back to being a USB HID device which your PC should recognize. Much of the design behind the restore process was not only to solve problems on Teensy. It's meant to be a complete solution to getting back to a known good state even when everything possible has gone wrong on the PC side.
 
AFAIK, the erase is controlled by the Bootloader chip. If erase phase is interrupted, I guess, it can be repeated as often as one wishes (TBC by Paul)

In my case I'm using can bus to reflash not the usb. Im also not leaving the usb exposed. So my sketch erases the portion of flash then copys my new file in. During this erase reflash time is when I could have problems. And the very nice restore program pjrc has would not work for me.

If the usb is left exposed then this would not be a issue.
It's only a problem because of how I want to use it.
 
@bigboosted - the 15s Restore would still work - given access to the PGM pin for 15 seconds right? But that would just get the Teensy running Blink - then needing USB connect to upload to start over?
 
@bigboosted - the 15s Restore would still work - given access to the PGM pin for 15 seconds right? But that would just get the Teensy running Blink - then needing USB connect to upload to start over?

Yes that would work if I was willing to leave the USB exposed.
I fully understand I'm creating my own problem here. But what I'm after is a fully programmable and recoverable 4.0 with no USB input only can bus.
 
Yes that would work if I was willing to leave the USB exposed.
I fully understand I'm creating my own problem here. But what I'm after is a fully programmable and recoverable 4.0 with no USB input only can bus.

Okay - just had to confirm there wasn't a way to brick it - without sealing it in a brick :)

Indeed if the worst happens during update without/until USB access the Teensy design will leave it stuck. That is a problem with OTA updates - the ESP family has its onboard scheme - like many PC's to boot to a known startup and then load the new or the old firmware in the event of a failed upload.

Have not followed the T4 Swap - wondering if a Boot stub could be factory programmed and then it could selectively run the Sketch::AFTER_Resethandler at a new address for "main()" - and not seeing that do a CAN connect and upload to that sketch area while never deleting that portion of the flash with the stub code?
 
But what I'm after is a fully programmable and recoverable 4.0 with no USB input only can bus.

If this is a must why not seal in a second T4, also connected to CAN, able to program the first one using USB host mode ...

Kind regards, Sebastian
 
Back
Top