Just killed my Taranis using the bootloader

[dvogonen]

Yesterday I was working on some suggestions for for improving the looks of the bootloader. I switched between flashing the Taranis with updated bin files and using the boot loader itself for flashing the Taranis.

After a successful bootloader flash (they are always successful), I turned the radio off and on again to reboot it, as I have done countless times. Only this time the radio would not start. It is completely dead. Dfu-util does no longer recognize it and it shows no signs of life. It will not boot into bootloader mode or into the normal mode.

Hardware failures can naturally happen at any time, but I have flashed the radio with dfu-util literally hundreds of times without any problems.

I will open the radio and see what I can find out this afternoon. Any and all hardware debugging help would be useful, since I am not a hardware developer.

[Kilrah]

Did you try unplugging the battery for a while? The radio might still be ON but with nothing on the display. Dfu-util wouldn't recognise it in this case.

If it's not that, next step is to check for a voltage on the CPU supply.

[MikeB]

Unless the bootloader has been changed, you shouldn't need to switch off and on after flashing the main program, just use EXIT LONG to reboot.
Also, on ersky9x, the main program now includes a "maintenance mode", accessed by booting with both horizontal trims held apart. This has a function to update the bootloader from a file on the SD card. I recommend this facility is added to openTx.

Plugging the USB cable in before switching on forces the processor to use the ROM based DFU loader, and should "always" work, regardless of what firmware might be loaded. I'd suspect a power problem.

Mike.

[dvogonen]

Yes, I tried disconnecting the battery for a couple of minutes. Makes no difference.
I also suspect some kind of hardware issue. I am hoping for something simple like a bad solder joint or loose cable.

[dinamich]

dvogonen, since you seem to be using linux, you can sniff USB traffic between Taranis and computer. http://wiki.wireshark.org/CaptureSetup/USB

Basically you load usbmon moudule and run wireshark. It is prudent to set a display filter to filter out a usb keyboard and mouse. Then you are left with what is left.

I will make a capture of what Taranis says when powered off (dfu loader) and attach it here to get you going.

[dinamich]

To start USB sniffing:

Code: Select all

$ sudo modprobe usbmon
$ sudo wireshark

Disconnect all usb devices that you can miss, leave only essential things like keyboard and mouse.

In wireshark:
* Capture -> Options...
* select all USB usbmon interfaces (I have four on my computer)
* start capture with update list of packets in real time

You will get a bunch of packets comming from mouse and keyboard, with specific address in Source and Destination colums. Mine was 3.3. Make a filter like this:

Code: Select all

!(usb.device_address == 3)

And hit Apply. Remember this is for my case (mouse and keybord have same address 3). If you have separate devices add anoteher adress:

Code: Select all

!(usb.device_address == 3) and !(usb.device_address == 6) 

Now most of packet should be hidden, now connect Taranis and watch. You should get 20 packets. See attached capture file from my taranis.

[dvogonen]

I managed to get out of the deadlock by removing the Taranis battery and flashing an older firmware version. With the battery in place it would not flash. In the meantime Kilrah found and fixed a bug in the boot loader with misaligned start vectors that was the root of the problem. So there is nothing wrong with the Radio!

But thanks for the information. It may well come in handy at a later tume.

[rdeanchurch]

Does this mean that a new version of boot loader needs to be written to tx?

[MikeB]

One advantage of using the "maintenance mode" to update the bootloader is it has some validation in that checks the first few vectors before flashing the bootloader.
I'm curious as to why the look of the bootloader needs "improving"? It was intended to just provide a simple method of selecting a file on the SD card and flashing it. It has been being used very successfully on the 9XR-PRO Beta units as originally written.

Mike.

[dvogonen]

Does this mean that a new version of boot loader needs to be written to tx?

Only if you have used the bootloader from the two latest nightly builds.
On closer examination it turned out that the problem was caused by myself, not the bug André fixed. I just fixed it and the fix will be in the next nightly build.

[dvogonen]

I'm curious as to why the look of the bootloader needs "improving"? It was intended to just provide a simple method of selecting a file on the SD card and flashing it. It has been being used very successfully on the 9XR-PRO Beta units as originally written.
Mike.

The "improvements" are very minor. I have not seen your original bootloader, since I do not have access to a 9XR-PRO Beta, but I imagine that most of the users would not notice any difference.

One thing I added was that there was no origin or version information displayed. That usually comes in handy when problems pops up and people need to identify which boot loader they are using. Not so easy to know as the bootloader will stay in place long after the firmware it came with is gone. The title bar now says something like OpenTX BootLoader v1.0

Another thing I changed was the indentation. Bertrand used the OpenTX variable length fonts, which made everything shift to the left compared to if a fixed pitch had been used. All centering was also off because of this.

The third thing I changed was the calculation of progress in the progress bar. The previous calculations made the progress bar stop at about 50% when the firmware had loaded. I do not know why.

[MikeB]

The bootloader code, as I wrote it, is common to the 9XR-PRO, the original SKY board and the Taranis for both openTx and "ersky9x for Taranis". I'm just about to get the sources for the bootloader in a new repository, specific for the bootloader. I agreed with Bertrand this was useful as the bootloader isn't specific to any one application firmware. It also means any fixes, like the one I recently have done for the MAC unmounting problem, are then available for all platforms.
The bootloader as I have it does include a version number, and a signature of the text "BOOT" that is checked, along with vectors, in maintenance mode updating to ensure only something that looks like a bootloader is used when updating.
Again, the version I'm using shows the progress bar correctly.
All my existing bootloader code is at http://code.google.com/p/ersky9x/source ... bootloader.
This is the code I'm about to put into a new repository.

Mike.

[MikeB]

I've just managed to get the bootloader code onto GitHub: https://github.com/MikeBland/OpenRcBootloader.
These are just the source files, although I just checked they compile OK.

Mike.

[Daedalus66]

I find the setup of the boot loader on the 9XR Pro very satisfactory, especially now that it shows v.1.0. The progress bar works properly and flashing takes only a couple of seconds.

[Daedalus66]

Does this mean that a new version of boot loader needs to be written to tx?

Only if you have used the bootloader from the two latest nightly builds.
On closer examination it turned out that the problem was caused by myself, not the bug André fixed. I just fixed it and the fix will be in the next nightly build.

Maybe you could change the rather provocative title of the thread now that it's clear the problem had a different cause.

[dvogonen]

Different than what? I did kill the Taranis with the latest OpenTX version of the bootloader. Luckily it wasn't permanently dead and future versions will not have the problem.

[jhsa]

Then you didn't kill it

Maybe you should change the title to something like:
"I really did think I just killed my Taranis using the boot loader, but it turned out tt didn't die....yet"