Need hel pwith a bootloader

Status
Not open for further replies.
F

Frank B

Senior Member
Edit: code-fragment & link deleted


Hi,

i tried to make a simple bootloader for Teensy 3.x. Just for fun (for me), and because there are so many requests.

It should
(Step 1) copy a file "flash.bin" from SD to the upper half of the flash (this works)
(Step 2) copy the upper half of the flash to the lower half (this works NOT)
Maybe if have forgotten something important or something is wrong.. but i can't find it.

The problematic "Step 2" (name of the function is "flashcpy()")
- runs in RAM(with "FASTRUN")
- disables interrupts
- erases the lower flash-sectors
- copies the data to FlexRAM in 1024-Byte steps
- flashes the data from FlexRAM
- resets the teensy

Edit: flashEraseSector() and flashProgramSector() seem to work, they are used in "Step 1" too.

Creating the flash.bin file with a batch (works), target dir is c:\temp, takes the last built-project:
Code: 
deleted

How to use:
Code: 
deleted.

Edit: The problematic function is commented-out at the moment - see last line of bootloader.cpp
 
Last edited:
On a non-Teensy project, I did that sort of strategy for remote reprogramming.
I wrote a parser for Intel .HEX file formats to avoid .bin and .out file format irregularities.

Interested to see if you get this to work.
And you know of Mark at uTasker's work in this topic, right?
 
Frank B said:
The problematic "Step 2" (name of the function is "flashcpy()")
- runs in RAM(with "FASTRUN")
- disables interrupts
- erases the lower flash-sectors
- copies the data to FlexRAM in 1024-Byte steps
- flashes the data from FlexRAM
- resets the teensy
Click to expand...

only a question: what happens after the CPU_restart with the registers and interrupts?
 
From the manual:
6.2.2.8 Software reset (SW)
The SYSRESETREQ bit in the NVIC application interrupt and reset control register can
be set to force a software reset on the device. (See ARM's NVIC documentation for the
full description of the register fields, especially the VECTKEY field requirements.)
Setting SYSRESETREQ generates a software reset request. This reset forces a system
reset of all major components except for the debug module. A software reset causes the
RCM's SRS1[SW] bit to set.
Click to expand...
 
If you know off-hand without study, is there a register to read that shows cause-of-restart (power on, watchdog, software-reset, etc.) ?

And... did I read post #1 correctly: code is not yet working ?
 
No.. and i don't know why it is not working. I have no debugger. And i can't use print()...
I supect that i have to write the flash word-wise... but that's only a guess. But i will give it a try..

Edit:Sorry, regarding cause-of-restart: Manual, chapter 13.2
 
Last edited:
32 bit writes required?

And.. how do you write in 1024 byte chunks since flash sectors are larger than that, and in most ARMs, the sector sizes differ within the address space. Often, the sectors at small addresses are smaller. E.g., some ARM M4's have three different sector sizes, where most are the largest size.
 
I reconfigure the FlexRAM to RAM, then copy 1024 Bytes (This is the maximum allowed sized) to it, then flash this block.
There is a special flash-command to do this. And it works for "Step 1"

But.. at 0x400 there is special case,, i assume. There is the flash-configration-area located.
 
If you write the wrong byte to location 0x40C, you can permanently brick your Teensy.

During normal uploading with Teensy Loader, the Mini54's bootloader prevents writing that byte with a wrong value. No matter what you try to upload, the Mini54 replaces that byte with a safe setting.

While I can't stop you from publishing this sort of code, I would really like to discourage it. Writing directly to that section of flash is risky. Publishing this software is almost certain to result in increased technical support burden on me and PJRC.
 
It checks the existance of 0xfe before doing anything to this area...

My teensy is not bricked...despite of the not working code which erases the flash (and this sector too)
But i understand your point, and maybe you're right with the "technical support burden"

You can close this topic, if you want.
 
PaulStoffregen said:
While I can't stop you from publishing this sort of code, I would really like to discourage it. Writing directly to that section of flash is risky. Publishing this software is almost certain to result in increased technical support burden on me and PJRC.
Click to expand...
Not meant to be argumentative, but is FrankB's functionality any different than Mark's (uTasker) secondary bootloader? Both permit loading the T3 via a medium other than USB/Mini54.
Perhaps PJRC can just decline support requests for custom bootloaders.

The underlying issue is that many people need a means to reflash the T3 with code updates via Ethernet, Serial, Wireless of all kinds, etc.
 
Last edited:
I was able to identify the problem.
"FASTRUN" does _not_ the expected, in every case... most of the "FASTRUN" functions were placed in flash instead RAM (looked at the assembler-output).
It works now for me (and is very fast), but i think the idea of simply including a "bootloader.h" is not as good as i thought, in every case, because there are too many unknown compiler-issues when doing this. And indeed, it is a bit risky if you can be not sure what the compiler does.
The only way out is to write the main routine "pass 2" by hand, in assembler (maybe i do this, sometime..). Or, working with a precompiled lib (but i don't like this).

But i reached my goal and wrote my own (working!) bootloader. Yeah!!!
I'll use it in my own projects. For public use, it's too risky at the moment.
 
Last edited:
can you make the bootloader a standalone program? set ld file to put in same address as normal apps are placed?
then make a new ld file for user apps so they origin in the next sector up ?

This would work so long as the mini54-based bootloader is not used, as it (currently) erases all flash sectors, and preserves a few special bytes in flash.

so the idea would be: always use the bootloader in operatonal use but optionally use the mini54 for development. Maybe a jumper to disable the mini54 until its needed?
 
Last edited:
Take a look at the kinetis bootloader.

Yeah, and i found the problem with FASTRUN. I use #define RAMFUNC FASTRUN __attribute__ ((noinline, noclone, optimize("Os"))) now... works perfect.
 
Teesny Bricked by using utasker and mass erase option

PaulStoffregen said:
If you write the wrong byte to location 0x40C, you can permanently brick your Teensy.

During normal uploading with Teensy Loader, the Mini54's bootloader prevents writing that byte with a wrong value. No matter what you try to upload, the Mini54 replaces that byte with a safe setting.

While I can't stop you from publishing this sort of code, I would really like to discourage it. Writing directly to that section of flash is risky. Publishing this software is almost certain to result in increased technical support burden on me and PJRC.
Click to expand...

Hi paul,

I have been using teensy 3.1 for some time now, i was trying to develop an application that required me to load code wireless either by using radio like bluetooth or nrf24 etc. So i tried the Utasker s-rec, msd bootloader for teensy, from www.utasker.com/SW_Demos.html#K20. It worked but just for testing i selected the "mass erase" option in Serial console. I didn't know about this 0x40c address byte before that and now my teensy is dead.

So can you please help me in reviving it, because now i am stuck i don't have any spares and the distributor in my area said he can't get me one
for atleast another 4-5 weeks.

Hoping for your quick response.

regards
neutronstriker
 
Hi neutronstriker

I have just seen that you had a probem after commanding a mass erase.

This command calls the Flash code to delete all sectors of Flash:
fnFlashNow(FCMD_ERASE_ALL_BLOCKS, 0, 0);
FCMD_ERASE_ALL_BLOCKS is the command 0x44 that is executed by the internal Flash engine of the Kinetis.

This command programs (deletes) the entire Flash to 0xff and so sets the chip to secured mode (the default mode when the device leaves the factory). JTAG debuggers will then unlock the device by performing another mass erase command (which allows the unlock sequence to complete) and program new code with 0x40c generall set to 0xfe (unsecured).

This means that the command will not cause a dangerous value to be written to 0x40c and programmers should not have any problems with the default secured state of the device.

I can't however explain why the board has a difficulty and whether it is a concequence of a mass erase but this information may help in case the case in hand is ivestigated more.

Regards

Mark
 
uTasker said:
Hi neutronstriker

I have just seen that you had a probem after commanding a mass erase.

This command calls the Flash code to delete all sectors of Flash:
fnFlashNow(FCMD_ERASE_ALL_BLOCKS, 0, 0);
FCMD_ERASE_ALL_BLOCKS is the command 0x44 that is executed by the internal Flash engine of the Kinetis.

This command programs (deletes) the entire Flash to 0xff and so sets the chip to secured mode (the default mode when the device leaves the factory). JTAG debuggers will then unlock the device by performing another mass erase command (which allows the unlock sequence to complete) and program new code with 0x40c generall set to 0xfe (unsecured).

This means that the command will not cause a dangerous value to be written to 0x40c and programmers should not have any problems with the default secured state of the device.

I can't however explain why the board has a difficulty and whether it is a concequence of a mass erase but this information may help in case the case in hand is ivestigated more.

Regards

Mark
Click to expand...


@Mark, Thank you for this info. I think that is the case like you said, after mass erase the whole flash is filled with 0xff, because of which the mini54-tan couldn't recognize the chip and fails to load the usb bootloader.

But unfortunately i don't have a JTAG right now, so if any body could verify this it would be great, however i am waiting for my J-link to arrive.
Once i get it i will test it.

Thanks

Neutronstriker
 
Hi Neutronstriker

In fact I may have made a mistake writing that a chip has all flash deleted (at 0xff) when it leaves the factory because in fact probaby the byte at 0x40c is set to 0x7e so that it is not secured.

Normally the complete blank state is not a problem for a JTAG debugger but it may be that the mini54-tan indeed can't handle it (??)

Boot loaders don't normally delete the first sector in Flash because they usually 'occupy' it and co-ordinate the loading of the application in higher sectors. This means that the typical boot loader usage never writes, deletes or changes the 0x40c location 'ever' and so is completely safe.

The only reason for the "mass erase" command in the uTasker loader is in case the boot loader were configured to intentionally block all debugger access to protect internal code (this is often done in industrial/commercial products to protect against competitors reading out the code and cloning products). The mass erase also deletes the 0x40c byte and so allows the board to be used again (with the original code destroyed).

The uTasker boot loader is programmed by using the mini54-tan and so I understand that this will also not allow the 0x40c byte to be programmed to anything other than 0xfe (which is also the case for many JTAG debuggers / IDEs).

However if you have lost programming capability by performing a mass erase it does sound as though the mini54-tan "may" be the root-problem. (I have only one Teensy so I won't test it).

Assuming that this is the case it does in fact mean that there is a (small) danger involved every time a program is programmed to the board using the "Teensy Loader".
Since every download programs the first sector (whether writing 0x40c with 0xfe, or any other values) it means that there is a short period of time in which the sector is "deleted" before the write is performed. If there is an error or a power failure at this point in time the value at 0x40c will be 0xff and the device will be secured once it restarts. If indeed the loader can't handle this case then the Teensy will also no longer be operational (although could be recovered with JTAG or EzPort).


Therefore I conclude that the exact behaviour with a secured device should be identified to know whether there is a risk with the "Teensy Loader" operation.
If it is found that this is indeed the case it would mean that the mini54-tan is the main source of the issue and it would make sense to modify it (if possible) to be able to recover. (by performing the standard unsecure sequence).
My further conclusion is however that a boot loader occupying the first sector of Flash (which is usually/always the case) cannot be a source of risk (as long as it doesn delete itself) because, once loaded, it never changes values in the first flash sector and thus actually removes the possibility of the problem from occurring.

I am wondering how often the Teensys stop working normally in normal use? I was involved with a project where 2 Teensy's were bricked but the actual reason why was not identified - is there maybe a higher rate of loss of loading capability that one would expect?

Regrds

Mark
 
'delete' terminology - is clearer if one says 'erased'.

It's probably to be found on this forum, but what's the magic with that one location in flash? Is it a value that the mini54-tan relies on to be able to use Single Wire Debug (SWCLK, SWDIO) to write the K20's flash?
 
I think the mini54-tan checks this 0x40c location to identify if it is teensy 3.0 or teensy 3.1, may be there is different data for mk20dx256 and mk20dx128 in this location, by default.

@Mark, I don't remember where i saw it but paul wrote somewhere that the mk20dx256 doesn't contain the bootloader, the mini54-tan loads it when the teensyloader sends a signal packet. or maybe I am wrong.
 
Status
Not open for further replies.
Back
Top