openrcforums

OK, the fuses are a problem. The low fuse is set to use the internal RC oscillator at 8 MHz. The firmware expects an external crystal at 16 MHz, so the serial baudrate to the Multi module will be wrong.
Looking at the pictures of the board on RCG, it looks like there is a crystal on it. Check carefully if there is a crystal (Y1?) connected to pins 23 and 24 of the processor. If there is, then you should be able to change the fuses to the correct values@
High: 0xC1
Low: 0x0E
Ext: 0xFF
eepe includes an option to set the fuses "Set fuses to protect EEPROM".
NOTE: If there is NO crystal on pins 23 and 24, then this operation will brick the processor.

Before you set the fuses, you could try configuring a timer and see if it only counts 1 second every 2 seconds.

Mike

Interesting, just tried flashing with that last .hex from MikeB again, and this time it didn't need -F. Completed without error.

But the screen is now dead...

Operating with the internal oscillator as the clock can cause flashing problems as the programming speed may be too fast for the slower clock.

Mike

Please check if there is a crystal on the board as Mike suggested, and if so, what numbers it has on it?

João

Mike, it looks like it has an XTAL
Actually, it looks more like a Resonator..

https://static.rcgroups.net/forums/atta ... 034763.jpg

João

Y1 is in a metal can and only has two connections, to those pins. Set Fuses to protect eeprom ha brought the screen back, great! Can't download eeprom - it gives a chip ID error, or if I override, it says the data is corrupt.

Are you using eepe to download the radio's eeprom?

Again, NEVER use the -F option again.. That was what messed the fuses. You are lucky you didn't brick the chip..

João

Yes - although I think eePe is just launching avrdude, which says the chip ID is incorrect and exits (or with the -F flag downloads something eepe can't open - and irritatingly doesn't seem to save?). There's probably command-line string that will get avrdude to download & save it. But it's odd that it says the chip ID is incorrect.

what are your settings in eepe's "Burn menu? What programmer is yours? UsbAsp?
Again, do not use -F, you will end up bricking your radio if you do..
eeepe uses AVRdude, yes, but it is still the best application to flash your radio..

You should have something like on the picture attached to this post.

João

Right, everyone hold their breath... it has all started working! I just re-flashed with MikeB's last offering for the umpteenth time, the module goes into 'fast flash' when I press 'bind' in MULTI, and I've even bound a FRSkyD and DSM2 receiver!

Many, many thanks for your enthusiastic and thoughtful input.

I am now confident that everything will work perfectly forever from now on ...

Darn, thought it was all a bit too good to be true. Now it will download the eeprom without errors, but eepe then just sits there with the endless whirling blue doughnut of Windows 10, not displaying anything. I shall leave it to whirl overnight... perhaps it's thinking...

Let's see what Mike say about that.. I use windows 7 not 10.. and i don't want to

João

Re-flash one more time, and now it all works AND I can download the eeprom - hoorah!
Many thanks again.

Congratulations

Remember, no more -F

João

Thanks. Yes, it was only the last .hex MikeB supplied that (initially) wouldn't update due to the chip ID being wrong (and recommending using -F to overcome this!). Odd how, after resetting the fuses, it didn't throw this error. Of course, I don't know what the fuses were initially.

Yep, they probably got messed up because of the -F option. or they did it wrong at the factory

João

MikeB wrote: ↑Mon Jun 25, 2018 9:48 pm Try this one, it should sort the display.

For the multi module, the "normal" CPPM signal sends serial data to the multi module if the protocol is set to "Multi".

For telemetry, pins 2 (Thr switch) and 3 (Ail switch) are the Rx and Tx serial signals. These 2 switches are normally wired to PC6 and PC7 (41 and 42) in order to free up pins 2 and 3.

MIke
er9x_128_ssd1306.zip

Hello. I need a voltage for atmega128a 3.3 volts, could you recompile the firmware for a frequency of a quartz resonator of 8 megahertz?

Not quickly as all the timers and baudrate generators will need to be changed and checked.
Also, I'm not sure whether everything will work at 8MHz, I suspect the processor may not handle all the processing in time.

Are you sure you can't use 5V?

Mike

unfortunately, the sticks on the hall sensors with a power supply of 3.3 volts

Use a different supply for the sticks then.

The 9X board already has a 3.3V regulator on it to supply 3.3V to the display. It should be fairly easy to use this to power the sticks.

Mike

I made my own PCB. If you feed the microcontroller 5v, and the sticks 3.3v, then the resolution drops. Please try to simply change the frequency to 8 mhz with the version of the firmware that was in the quote.

Wouldn't the resolution be affected then?
I remember that this issue was already addressed in some other topic..
And I believe a solution might have been found??

João

As I indicated, it is neither a simple change, nor could I test such a change.
The processor has an analog reference voltage. All you need to do to restore the resolution is to supply both the sticks and the analog reference from a 3.3V supply.

Mike

That is a solution.. a good stable regulator on the analog ref pin should sort that out.. I have seen it done on other projects. But i wouldn't use the onboard 3.3V regulator that is already used for the LCD. I would use a dedicated regulator only for that purpose..

João

MikeB wrote: ↑Wed Dec 12, 2018 1:03 pm , nor could I test such a change.

Mike

I will check it for you. Please just compile, please. You are my last hope

I think you should try the solution Mike just explained above. It would avoid a huge amount of work changing the code. Connect a 3.3V regulator on the analog reference pin and power the sticks from the same regulator. Like this the resolution stays the same..

João

Yes, do try providing a 3.3V supply to the sticks (and pots), and using that voltage for the processor AREF pin (pin 62). Keep AVCC at 5V.
You may need to adjust the resistors that provide the battery voltage to the processor, which would be needed even if you were running at 3.3V.
I really don't want to work out all the changes required to operate at 3.3V/8MHz as, without me testing it, I can't be certain the firmware is performing correctly, and the processor is keeping up with the processing requirement. It would then also mean I would have to continue to maintain and release an extra binary file.

Mike

I have a homemade remote, the space is very limited, to add another stabilizer, to feed the hall sensors separately is problematic. I am not asking you to change the code, just try recompiling for a different frequency. If it doesn’t work, I’m not stalking.

Я не прошу изменять код и тратить ваше время, только скомпилировать КАК ЕСТЬ с заменой частоты. если не будет работать, то буду мудрить с питанием процессора.

As you were told It 100% cannot work by "just recompiling". New timings have to be worked out in several places and that's not automatic. It's not arduino code.