openrcforums

MikeB wrote:I would think you can replace the stock firmware and EEPROM OK, so probably worth flashing something.
Perhaps try standard er9x first as this is less than 64K, you can find it here: http://www.er9x.com/.

Mike.

Yeah, just wanted to know if anyone wanted me to do something to figure out the issue with the clone chips. Either an update to the opentx firmware or maybe even discover that there really isn't an issue. One of the pieces of the notice is that there is no firmware to restore the clone chip if there is an issue so in your mind, do you think we have a good copy of the clone firmware? It just so happens that it is the same as the non-clone firmware?

Yes, since the firmware matches the original, it should be OK to replace it.
I'm suggesting whatever you flash with first should be less than 64K, hence my suggestion of standard er9x.

Mike.

Ok I'll try that. Any particular functions to try? I'm not sure what issues people were having

The <64K er9x firmware flashed fine. When I made a model in OpenCompanion and saved to EEPROM, I got that warning about the EEPROM being 4096 but it is only going to use the first 2048. When it rebooted after that, it beeped really weird and the LCD was blank. Nothing I did could bring it back so I went ahead and flashed the latest version of opentx. That flashed fine and then the models saved fine without that warning. The reboot worked and the model now shows. Everything seems to be working but I don't know what exactly to test so if any of you have any ideas, let me know.

dreed75 wrote:The <64K er9x firmware flashed fine. When I made a model in OpenCompanion and saved to EEPROM, I got that warning about the EEPROM being 4096 but it is only going to use the first 2048. When it rebooted after that, it beeped really weird and the LCD was blank. Nothing I did could bring it back so I went ahead and flashed the latest version of opentx. That flashed fine and then the models saved fine without that warning. The reboot worked and the model now shows. Everything seems to be working but I don't know what exactly to test so if any of you have any ideas, let me know.

What settings and firmware did you use to flash OpenTX (64 or 128)? I flashed mine last night and had the same issue with the LCD being blank. I've tried flashing it again but have no change.

When I flashed my TGY9x with your provided firmware, the Tx permanently beeped, but showed "Eeprom error" that I could not clear to continue. I had to restore the originally delivered Eeprom to get the radio working (with your code).

Reinhard

dreed75 wrote:The <64K er9x firmware flashed fine. When I made a model in OpenCompanion and saved to EEPROM, I got that warning about the EEPROM being 4096 but it is only going to use the first 2048. When it rebooted after that, it beeped really weird and the LCD was blank. Nothing I did could bring it back so I went ahead and flashed the latest version of opentx. That flashed fine and then the models saved fine without that warning. The reboot worked and the model now shows. Everything seems to be working but I don't know what exactly to test so if any of you have any ideas, let me know.

If you flash er9x, then you need to use eepe on the computer, not Companion, to read and write the EEPROM.
When you first ran er9x, did you get "EEPROM Error", and then have the EEPROM format?
The LCD may be blank because the contrast setting is incorrect, which could easily be caused by writing the EEPROM from Companion.
I would be interested if you could install eepe on your computer (download from the same place as er9x), then put the <64K er9x back on and use eepe to create a default EEPROM and write that as well.

Mike.

MikeB wrote:
If you flash er9x, then you need to use eepe on the computer, not Companion, to read and write the EEPROM.
When you first ran er9x, did you get "EEPROM Error", and then have the EEPROM format?
The LCD may be blank because the contrast setting is incorrect, which could easily be caused by writing the EEPROM from Companion.
I would be interested if you could install eepe on your computer (download from the same place as er9x), then put the <64K er9x back on and use eepe to create a default EEPROM and write that as well.

Mike.

I'll try that. Yes, it did format the eeprom for me.

One other thing about flashing opentx... The sticks get calibrated right away and everything is good until I save a model from the computer. It seems to save the model correctly but the sticks are not calibrated anymore and only function in one quadrant. If I manually calibrate, it appears to work but then it only functions in one quadrant again. The sticks have no values in the "dead" quadrants. I'm not sure if the eeprom gets corrupted somehow through a model download.

On the 9x you will have to calibrate the sticks every time you flash the firmware, or change the fuses to protect the eeprom.
Another option is to download the eeprom onto eepe/companion, depending on which fw you're using, Flash the firmware, and then burn the eeprom to the radio again. That will restore all your settings and models.

João

jhsa wrote:On the 9x you will have to calibrate the sticks every time you flash the firmware, or change the fuses to protect the eeprom.
Another option is to download the eeprom onto eepe/companion, depending on which fw you're using, Flash the firmware, and then burn the eeprom to the radio again. That will restore all your settings and models.

João

Yeah, I understand the calibrating part. Any time I burn the eeprom, it wipes out the calibration. Actually, it may not be the "calibration" that is wiped out. The limits of the sticks are altered and they arent fixable. Flashing the firmware obviously fixes it but anytime I burn eeprom, the stick limits are messed up.

As João says, once you have done the stick calibration, always read the EEPROM into eepe/companion, do any changes you need to do, then write the EEPROM back. This preserves all settings you have already done.

Mike.

MikeB wrote:As João says, once you have done the stick calibration, always read the EEPROM into eepe/companion, do any changes you need to do, then write the EEPROM back. This preserves all settings you have already done.

Mike.

I tried it that way to and same result.

Was that with er9x/eepe or openTx/companion?

Mike.

MikeB wrote:Was that with er9x/eepe or openTx/companion?

Mike.

OpenTx Companion. I haven't had a chance to try it with eepe. I'll try it after work.

I believe companion may keep the configuration values in a 'profile', and may be using default values from that when you read the EEPROM from the radio.
It may also be there is a problem writing to the EEPROM from the computer.

Mike.

MikeB wrote:I believe companion may keep the configuration values in a 'profile', and may be using default values from that when you read the EEPROM from the radio.
It may also be there is a problem writing to the EEPROM from the computer.

Mike.

Using eepe worked even though it kept giving all kinds of random errors during the flashing process. So far the model I have is working fine. Any particular functions/switches I should try that people have had problems with?

What sort of random errors during flashing?

I don't know what specifics may need testing.

If the standard er9x (<64K) has flashed OK, it is worth trying er9x-128 to see if >64K flashes. This will also use all 4K of EEPROM.

Mike.

I did flash the 128 version. The errors I was getting were:
avrdude saying that it failed even though it was still running (successfully) in the background.
Another error after 100% saying that the write failed even though it was successful.
Some other error during a read that I can't remember but it seems to have been a fluke.

I ordered a real atmega128 so I can send you my clone chip if you want to run some more thorough tests.

I posted on the rcgroup forums about this.

I got one of these chips in a FlySky transmitter, so it's not just Turnigy that are getting them.

Mine is slightly different though. There's no Atmel markings at all, and it's a Green ED040502-H16D rather than Green ED040501-H16D.

I haven't tried flashing anything yet but I have it set up to now. I wasn't going to after discovering this problem with counterfeit chips but I'm tempted as I have a AR9X mainboard on the way some time soon.

Would it help anyone for me to try it?

Interesting it is a '02 not a '01. I wonder if they have found a problem in it and fixed it?
dreed75 managed to read the stock firmware and EEPROM, so it would be worth you doing the same, then it should be possible to put them back if necessary.

I think it would be worth another test. Perhaps you could follow the same sequence:
1. Backup the existing firmware and EEPROM.
2. Flash standard er9x (this is less than 64K) and check if it works.
3. Flash er9x-128 (this uses more than 64K) and check if it works.
4. Read both the firmware and EEPROM, zip them up and post here for checking.

Mike.

It'll maybe take me a day or two but sure I can do that. I have a couple of other jobs to do before I can commit to it.

Derpdiherp wrote:...There's no Atmel markings at all, and it's a Green ED040502-H16D

Quite a few different processors out there...
Last summer I got a spare motherboard from HK for the 9X that is marked with

ATMEGA128A-AU
Green
ED040502-H16D
1104
110404

but with ATMEL-Logo on it.

Klaus

KAL wrote:

Derpdiherp wrote:...There's no Atmel markings at all, and it's a Green ED040502-H16D

Quite a few different processors out there...
Last summer I got a spare motherboard from HK for the 9X that is marked with

ATMEGA128A-AU
Green
ED040502-H16D
1104
110404

but with ATMEL-Logo on it.

Klaus

Agreed. Here is mine.

Also another (better) option when replacing the main board chip is to use the M2561 instead of the M128 chip.

From my experience with Chinese marketing... there's not necessarily a reason to believe they are different chips or that they found a problem and switched. The different markings are most likely indicative of there being multiple manufacturers/factories working from the same reference design.

For mass market items, particularly items bound for export, China seems to follow this model: Copy a working design; Make a lot of them; Use it in as many things as possible.

"Green" is probably the company that worked out the reverse engineering and provided a reference design and several chip factories probably started pumping them out. Some chose to rip off the Atmel logo, others didn't. Some used a "2" instead of a "1" because it is a higher number and, therefore, a better product. Did they find a problem? They don't find problems. They wait for Atmel to find a problem and release a new chip to copy.

I'm not intending this in a derogatory way. Chinese law simply views intellectual property differently than much of the "Western" world.

As for FlySky... their motivation for choosing one chip over the other is almost certainly about cost and availability (most likely the latter). It is no surprise to me at all that the firmware on all these chips is going to be identical.

bob195558 wrote:Also another (better) option when replacing the main board chip is to use the M2561 instead of the M128 chip.

+1 here, it doubles the RAM as well. and this is really recommended because the RAM on the m64 and m128 is getting a bit too full. So if you are going to replace the chip, better use an Atmega2561..

João

Attached is a macro image of the microchip. Completely different from any others I've seen so far.

Are the same firmwares compatible?

I'd personally bet money on it.

Then again, I had Clinton so whatever.