Possible bug with Companion 2.0.18 and 2.0.19 [was: Eeprom 217 on OpenTX 2.0.19: how's that possible?]

[Nadim]

Hello everybody.

All started when I was trying to update from OpenTX 2.0.17 to 2.0.19, including of course Companion itself.

First I upgraded to Companion 2.0.19, successfully.

Then I was about to backup my models and settings, but when I tried to read them out from my radio, I had a pop up saying that "eeprom is from a newer version of opentx, eeprom is not from gruvin 9x, eeprom size is invalid."

I checked the eeprom version from inside the radio, and I found out it was 217 (which is supposed to be the format from OpenTX 2.1.x, which I never installed...)

I switched back to Companion 2.0.17, and now I was able to do both:

1. reading my settings and models
2. flash into my radio OpenTX 2.0.19.

...and so I did.

Now the problem is that if I use Companion 2.0.19 I cannot read my models and settings from the radio (same problem as above), I only can with Companion 2.0.17. How's this possible? Also, how's that possible that I flashed the 2.0.19 firmware from inside Companion 2.0.17?

All I want to do is:

1. to have companion 2.0.19
2. to have opentx 2.0.19 inside my radio
3. to be able to read & write settings and models from my radio (I wonder if this means not having the 217 format eeprom).

Could anyone help me out on how to do that?
Thank you indeed

[Kilrah]

You did not state what firmware version you actually have on the radio, everything points towards it being 2.1.

You actually don't even say what radio you have either...

[Nadim]

I have a 9X with the M128.

As for the firmware, well as (I thought) I explained in the first post, I had OpenTX 2.0.17 and was upgrading to 2.0.19. Right now, I have the 2.0.19.

But here's the issues (and the weird things):

1. The only version of Companion that lets me do anything (both firmware burning and eeprom reading/writing) is the 2.0.17 release. This is the version I was able to burn OpenTX 2.0.19 (I trying also downgrading again to the 2.0.17, and it works). Other versions would give the following error, with any OpenTX version:

avrdude: verification error, first mismatch at byte 0x0100
0xff != 0x49 avrdude: verification error; content mismatch

And after this error, the TX is just totally blank (sorry for probably inaccurate English; I mean that there's no firmware at all and it's not usable).

2. Inside my TX, if I check the eeprom version, it says 217. This is weird. I never had flashed OpenTX 2.1.x, and actually had never ever downloaded Companion 2.1.x. When I tried downgrading back to the 2.0.17, it still said 217. Right now, with the 2.0.19 installed, it says, again, 217.

3. I tried, as an experiment, to download Companion 2.1.x and try to burn OpenTX 2.1.x, and... same error as point 1). I tried both through Linux and through a virtualized Windows 7, and the result is the same.

So, just to have my TX usable again, the final move I did was reinstalling OpenTX 2.0.19 using Companion 2.0.17, the only one that works, like I said before.

Now I don't really get how's that possible that if I burn the 2.0.19 release of OpenTX with Companion 2.0.17, I get eeprom version "217" inside the TX.

It even seems that 'something' remains stored inside the TX between one flash attempt and the other. Isn't the firmware flashing supposed to erase it completely? If not, how do I get a total wipe out and fresh install?

I can't believe that even Companion 2.1.x (which I had never tried) won't flash OpenTX 2.1.x...


EDIT: I have two 9Xs, and I just checked the second one I have, on which I had flashed OpenTX 2.0.17 with Companion 2.0.17 months and months ago (and never touched it after that), and... well it says eeprom version 217. Now I am pretty sure that eeprom format 217 has NOT showed up with the 2.1.x branch, and was actually present before. I am really confused now...

[Kilrah]

I have a 9X with the M128.

Helps when we have details - indeed 2.0 and 2.1 use the same eeprom version on the 9x, and the numbers are independent from other platforms. There basically hasn't been any change for the 9x between the 2. Normal you see 217 then.

As for the firmware, well as (I thought) I explained in the first post, I had OpenTX 2.0.17 and was upgrading to 2.0.19.

You had never specifically confirmed that also applied to the firmware, the way you said it you could have been talking only of companion versions and actually have 2.1 for the firmware.

1. The only version of Companion that lets me do anything (both firmware burning and eeprom reading/writing) is the 2.0.17 release. This is the version I was able to burn OpenTX 2.0.19 (I trying also downgrading again to the 2.0.17, and it works). Other versions would give the following error, with any OpenTX version:

avrdude: verification error, first mismatch at byte 0x0100
0xff != 0x49 avrdude: verification error; content mismatch

Can't see how that can have anything to do with companion or OpenTX given that all companion does is calling the avrdude utility to do the flashing, that error comes from it, and the same avrdude version is distributed in 2.0.17 and 2.0.19. So basically we're calling the same utility the same way, can't see how that could cause it to sometimes work and sometimes fail that consistently.
Might want you're using the same version of avrdude in "Configure communications" when on both versions.

It even seems that 'something' remains stored inside the TX between one flash attempt and the other. Isn't the firmware flashing supposed to erase it completely? If not, how do I get a total wipe out and fresh install?

By default a flashing operation erases both firmware ane eeprom indeed, companion would however by default read the eeprom, flash firmware, then restore eeprom. That can be disabled.
There is a way to disable the automatic erase by changing the fuse configuration, maybe that was done on your radio.

[Nadim]

Can't see how that can have anything to do with companion or OpenTX given that all companion does is calling the avrdude utility to do the flashing, that error comes from it, and the same avrdude version is distributed in 2.0.17 and 2.0.19. So basically we're calling the same utility the same way, can't see how that could cause it to sometimes work and sometimes fail that consistently.
Might want you're using the same version of avrdude in "Configure communications" when on both versions.

You say it has nothing to do with Companion, and I believe that, but then there must be something that changes with the installation of Companion that does have to do with the issue. For instance, let's focus now not on firmware burning but on eeprom read/write.

With Companion 2.0.17, I can read/write the eeprom, with Companion 2.0.19, I can't, and this happens 100% of the time I try. If I try with Companion 2.0.19, I get the following error:

Invalid EEPROM File /tmp/1274-temp.hex
Possible causes for this:
- Eeprom is from a newer version of OpenTX
- Eeprom is not from Gruvin9X
- Eeprom size is invalid

I tried numberless times, and get always the same result.

I checked the settings in "communications", and they are the same for both versions of Companion.

How's this possible?

By default a flashing operation erases both firmware ane eeprom indeed, companion would however by default read the eeprom, flash firmware, then restore eeprom. That can be disabled.

Do you mean just unthicking the box under "Backup and restore models and settings" right before burning? I already tried that, but no difference.

There is a way to disable the automatic erase by changing the fuse configuration, maybe that was done on your radio.

I never tried that, but if the default setting is to erase everything upon flashing, then this is the setting I need, so no need to change.

Any idea on why I keep getting this problem?
Thank you

[Nadim]

EDIT

I think I'm starting to understand what's happening.

I tried with a different physical computer, from the very beginning: I downloaded and installed Companion 2.0.19, installed the drivers for smartieparts board, and tried reading the eeprom: it says the exact same warning as before.

Now, if you check this (http://rc-soar.blogspot.kr/2015/07/open ... l-and.html) page out, under the paragraph "Your EEPROM data looks corrupted. Why?", you'll see that NORMALLY Companion used to allow the user to open eeproms that were from a newer version of OpenTX, without warning to the user. BUT! "this is fixed in Companion 2.0.18 which will not open files in a newer format".

Ta-dah! I just tried using Companion 2.0.18 and I got the exact same error as the 2.0.19. Namely, from version 2.0.18, Companion thinks that eeprom 217 belongs to branch 2.1.x, which, like Kilrah was pointing out, is true for the Taranis but NOT FOR THE 9X. But apparently Companion doesn't know that.

So it seems a bug in Companion introduced with release 2.0.18. We should tell Companion that 217 is 'too new' to be 2.0.x ONLY FOR THE TARANIS, and it's perfectly fine for the 9x.

Again, countless attempts have shown that the error shows up so consistently that it can't be pretty much anything else... I updated this thread's title.

The reason why this might have passed unnoticed by many users is that they are probably focusing on branch 2.1.x.

[Kilrah]

With Companion 2.0.17, I can read/write the eeprom, with Companion 2.0.19, I can't, and this happens 100% of the time I try. If I try with Companion 2.0.19, I get the following error:

Invalid EEPROM File /tmp/1274-temp.hex
Possible causes for this:
- Eeprom is from a newer version of OpenTX
- Eeprom is not from Gruvin9X
- Eeprom size is invalid

Known issue:
https://github.com/opentx/opentx/issues/3333

It will likely not be fixed in 2.0 as for a 9x 2.1 is identical to 2.0, so there is no reason to stay on 2.0. That should actually be written somewhere, will see about adding it.

[Nadim]

To be honest it doesn't seem the same issue to me: the error code is different and what the guy was trying to do was a different thing either.

Also, you say that we should upgrade to 2.1 anyway since for the 9x is the same. Is the same as what? As 2.0.17 or 2.0.18 and 19? 'Cause if it's the same as the 2.0.18 and 19 it means that it doesn't work either.

...and in fact, when I tried with Companion 2.1.x (specifically the 2.1.7) it didn't work.

Again, to me it seems that there isn't a way to make any Companion above the 2.0.17 work on a 9x.

[Kilrah]

Also, you say that we should upgrade to 2.1 anyway since for the 9x is the same. Is the same as what?

Meaning there is no new functionality and nothing's been removed either.

...and in fact, when I tried with Companion 2.1.x (specifically the 2.1.7) it didn't work.

OK. Then use 2.1.7, then open an issue with a detailed report of the problem on the Github issue tracker, and hopefully that'll get fixed.

[anm]

I have a similar problem with Tyrnigy 9RX and Companion 2.0.19. But the flashing and a EEPROM backup pass successfully. All settings remain.
If to keep EEPROM to file, then it is impossible to open. But at the same time everything managed to be made in Companion 2.1.8. But after loading of settings in the transmitter I have found a problem with timers. The first timer didn't work, but for the second, working in the opposite direction, considered in time more slowly at turning on of the first timer. If to switch-off the first timer, then the speed of counting became normal. Probably in the version of a program 2.0.19 structure of EEPROM from the version 2.1.x, and Companion don't understand 2.0.19 it. I have solved a problem flashing a rev. 2.1.8 in my Tyrnigy 9XR, it is similar and the Taranis X9D pass too on 2.1.8 though I didn't want it to do yet.

[jaeno]

Hi guys,
I think I'm having similar problem like you have/had.
I have 9XR M128, using companion 2.02 + freshly downloaded FW 217-
my problem description is here
viewtopic.php?f=70&t=9257&p=119541#p119541