Possible new flashing method

[MikeB]

I've just completed a working version of a new method for flashing the SKY board. It should be possible to port this method to the STM ARM processor of the Taranis, allowing for some differences in the way the flash is written.
The method I have working is:

1) Create a directory on the root of the SD card called "firmware" (no quotes of course).
2) Copy your required firmware file (.bin).
3) power off.
4) Hold both horizontal trim switches towards the center and power on.
5) You should have a list of available firmware files, use UP/DOWN to highlight the required file.
6) press MENU LONG to select.
7) You get a confirmation screen, MENU LONG to flash, EXIT LONG to cancel
8) On MENU LONG the firmware is flashed, a progress bar is displayed, only takes a few seconds
9) You get a "Flashing Complete" display.
10) power off
11) power on to use the new firmware.

If this is of interest we could look into adding it to openTx.

Mike.

[Helle]

Hy,

no zadig driver to use

only a subdir at the SD-Card

make only a copy of the firmeware to SD-card

could be a fine solution

Helle

[Kilrah]

Yes perfect.
I would have wanted us to do exactly this for the Taranis, but the unpredictable release schedule went such that there simply wasn't enough time to tackle that. I had started by making a copy of the openTx firmware and purging it of all unrelated functions (i.e. keeping only LCD, SD and buttons), but it didn't go any further.

How do you plan on storing the upgrade code? Part of the main binary, or independent? I wanted to make it completely independent, and load it at some predefined address on top of the flash that would never be touched afterwards.
So bootloader would have been compiled separately from the firmware, then both the firmware binary and bootloader binary combined into a .dfu file for production. Bootloader would then be in place for good, so that a failed flash through SD would not destroy it and require PC-based flashing. Only a failed bootloader upgrade if implemented could corrupt it.

[MikeB]

At the moment it is embedded in the main code, and copied to RAM when needed.
The minor problem on the STM device is the flash page sizes (and so the lock size) are small at the low end of memory and large at the top. If you want a permanent bootloader then it would be best at the bottom (16K page size), and compile the main application to load and run above that.

Probably, to power up into the bootloader it would need to be there anyway.

Mike.

[Kilrah]

True, shouldn't be an issue anyway.
Put the bootloader at the low end, do the key combination detection in the assembly startup "script", if not done jump to the main program start before even initializing the bootloader, else continue executing bootloader.

The only drawback is that the firmware would need a few defines to set the base address either for standalone or bootloader-based execution.

Some ideas could probably again be taken from openpilot. They run very robust bootloaders on all their devices, although USB ones instead of SD.

[G550Ted]

I've just completed a working version of a new method for flashing the SKY board. It should be possible to port this method to the STM ARM processor of the Taranis, allowing for some differences in the way the flash is written.
The method I have working is:<snip>

Mike, if you and Kilrah can make this happen it will be a tremendous boost in facilitating the ease for all Taranis users in overcoming one of the biggest problems of upgrading the FW! I stated in this forum last July that this would be one of the most problematic issues in getting popular acceptance of Taranis for the general public and this looks to me to be an elegant solution.

TIA,

Ted

[dvogonen]

How would the existing model settings be handled?


Sent from my Nexus 7 using Tapatalk 4

[MikeB]

Brain ticking over.

I'm beginning to think the bootloader should be at the start of flash, locked in place, and it should also have the USB mass storage built into it, rather than have the USB mass storage in the main program. So there would be three modes of use:

1) Plug in USB and power on - DFU loader.
2) Power on with both trims held - Bootloader with mass storage for up/down loading SD and EEPROM and flashing.
3) Power on normlly - normal operation.

Mike.

[MikeB]

The concept works! I'm building a bootloader for SKY board Tx's, but the functionality is as described. In bootloader mode, I have USB mass storage running. While connected to the PC, the rest of the bootloader functions are not accessible. When the USB is disconnected, it reloads and re-displays the list of files to flash. The program is around 26K.

The binary file I'm building includes the bootloader in the first 32K, always. The bootloader expects this, and only flashes the file from 32K onwards, having checked the file seems valid.

The only drawback I can see at the moment is eepskye/companion can't make the flashing take place, but it does remove the need to install any drivers on the PC.

Mike.

[Kilrah]

The only drawback I can see at the moment is eepskye/companion can't make the flashing take place

Have the bootloader map the flash (from 32k onwards) to a virtual drive like the eeprom?

[MikeB]

Just tried making the EEPROM virtual drive larger and having two files on it. Windows throws a complete wobbly, error 0x80070057 incorrect parameter. This is internal to windows so looks like I will have to have a third virtual drive.

Mike.

[LTMNO]

This is truly amazing. I was reading on this thread on another forum something similar.

http://forum.mikrokopter.de/topic-31676.html

I wish I could decipher. But perhaps both threads could benefit from collaboration?



Sent from my iPhone using Tapatalk

[MikeB]

Cancel my previos comment, I found the "disk size" is in several places and I missed one. Now I have two files on the virtual diskm, one is the EEPROM and the other is the firmware. Both read fine, I need to sort writing to them.

Just looked at the other forum. Interesting, but you still need a programmer to get the bootloader in the processor so I'm not sure quite what the advantages are against mounting a USBASP in the radio.

Mike.

[Kilrah]

Now I have two files on the virtual disk, one is the EEPROM and the other is the firmware. Both read fine, I need to sort writing to them.

How can you guarantee the OS will not reallocate the sectors? Or say if you deleted the files and then wrote them, that it might write one file to the memory addresses that are dedicated to the other?

With just one file we know it works, but with 2 I don't think we can be sure...

Otherwise there's the solution like in the little oscilloscope I have, putting the file in doesn't write directly to memory, but is processed and directed to the right place depending on the filename being written.

[MikeB]

As long as the OS open the file for read/write it shouldn't reallocate the sectors.
I'm not sure we know which file is being opened, this operates at the sector read/write level.

Mike.

[Kilrah]

I say this because with the Taranis on Windows for example I can't copy a TARANIS.BIN file onto the drive without deleting the existing one first. We know it doesn't really delete the file, but the OS thinks it has deleted it and then will allow copying a new one. Result works fine.

We're dealing with something "visible" that people will mess up with in all possible ways, so I'd tend to think 2 separate drives would be wiser...

[MikeB]

OK, we know what a firmware file looks like. The first few 32-bit words are the vector table. In the case of having the bootloader resident at the start of flash, there will also be vectors at the 32K offset. I already check for these when flashing from the SD card.
I'll add a couple of "blocking" flags. Writes to either file ar BLOCKED by default. When writing to the FIRMWARE file, if vectors are detected at the correct place, the writes will be UNBLOCKED, otherwise no writes take place.
When writing to EEPROM, if vectors are detected then that remains BLOCKED. I should be able to validate the start if the EEPROM as well as each 4k block, if it contains valid data, has a checkable header on the SKY board.

Mike.

[LTMNO]

Cancel my previos comment, I found the "disk size" is in several places and I missed one. Now I have two files on the virtual diskm, one is the EEPROM and the other is the firmware. Both read fine, I need to sort writing to them.

Just looked at the other forum. Interesting, but you still need a programmer to get the bootloader in the processor so I'm not sure quite what the advantages are against mounting a USBASP in the radio.

Mike.

Apologies, its clear this is all way over my head... but I thought it was interesting... thanks for looking.

[MikeB]

I've completed the bootloader for the SKY board.

Main operation:
1) Plug in USB and power on - SAM-BA boot program
2) Power on with both horizontal trims held towards the centre - Bootloader with mass storage for up/down loading SD and EEPROM and flashing.
3) Power on normally - normal operation.

To use the bootloader:
1) Hold both horizontal trim switches towards the center and power on to enter bootloader.
2) Plug in USB cable, the SD card appears as a disk drive on the PC
3) Create a directory on the root of the SD card called "firmware" (no quotes of course).
4) Copy your required firmware file (.bin).
5) Disconnect the USB cable.
6) You should have a list of available firmware files, use UP/DOWN to highlight the required file.
7) press MENU LONG to select.
8) You get a confirmation screen, MENU LONG to flash, EXIT LONG to cancel
9) On MENU LONG the firmware is flashed, a progress bar is displayed, only takes a few seconds
10) You get a "Flashing Complete" display.
11) power off
12) power on to use the new firmware.

Also, while the bootloader is running you get a second disk drive with two files mapped to the EEPROM and flash. These may be used directly by eepskye/companion to read/write the EEPROM and the flash. It is even possible, as kilrah does, to simply delete one of the files and write a new EEPROM/flash image.

The bootloader protects against overwriting itself, and also validates the content being written to protect against writing a firmware file to the EEPROM, or an EEPROM file to the firmware.

For the SKY board/9XR-PRO, this should pretty much mean the end of special driver installs or the need for SAM-BA.

Mike.

[jhsa]

As always, THANK YOU!!

João

[G550Ted]

Way to go, Mike!!!

Can this also be implemented for Taranis?

Ted

[MikeB]

I've passed info on to Bertrand, and I'm going to be looking into this as well. I'm just a bit busy at the moment.

Mike.

[Daedalus66]

I've completed the bootloader for the SKY board.

For the SKY board/9XR-PRO, this should pretty much mean the end of special driver installs or the need for SAM-BA.

Mike.

Wonderful news! Thank you, Mike.

Nigel

[bob195558]

[LTMNO]

Wow... just amazing.. great work! Hopefully will be able to see it in action one day when and if I own a Sky9x board or the 9xPro... its on the list...

[MikeB]

I'm working with "ersky9x for Taranis", but a bootloader will be exactly the same for both that and openTx. I now have a framework in place for building the program. I have the space reserved for the bootloader in the flash, and code that tests for the two trim switches pressed at power on.
On detecting the trims pressed, the code copies actual bootloader code from flash into RAM, and is ready to run it. It will need to run from RAM as the time taken to erase a flash block is very long (up to 2 seconds) and this would probably cause USB problems if the bootloader was in flash as it would be stopped while the erase took place.
Just need to sort the actual bootloader now. It shouldn't be too difficult as it will use a lot of code from the one I already have working for the SKY board.

Mike.

[Daedalus66]

It works great on a Sky board. I'd love to have it on the Taranis.

[MikeB]

Bootloader code now running from RAM OK. It's finding the SD card and listing files on it for flashing. I need to change which buttons are used to suit the Taranis (+/- for up/down etc.). Then I need to make it actually flash the firmware from the SD card. Finally, I'll need to get the USB as mass storage running and read/write the flash and EEPROM, but it looks promising.

Mike.

[MikeB]

Buttons changed, and I've just flashed the firmware from a file on the SD card. It flashed noticeably quicker then when using dfu.
dfu (160K) 23 seconds
bootloader (128K) 4 seconds

On to USB mass storage!

Technical: I build the (RAM based) bootloader then use a python script to convert the .bin file to a (compilable) byte array. Then I have the main program build have some startup code that detects the trim switches and either executes the normal program (starting 32K into the flash), or copies the RAM image into the RAM an executes it. I did have one (minor) problem in that system_stm32fxx.c hard codes setting the VTOR (vector base address register) to the start of flash. I've changed:
SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */
to:
extern uint32_t g_pfnVectors ;
SCB->VTOR = (uint32_t) &g_pfnVectors ; /* Vector Table Relocation in Internal FLASH */
so it sets it correctly to where the vectors actually are in flash or RAM.

Mike.

[ReSt]

Would that also be possible with the standard 9x board with an M128 processor and a sound module ?

Reinhard