Thought I'd check in on this subject -- thanks to Tom in Aussie for bringing it to my attention.
Here's my few cents worth on the topic ...
1. I have never personally experienced the trim-crash problem. I have one client (Tom) who has had it on a G9X v4.2 board, which was replaced. My understanding is that the replacement board solved the problem. However, I believe he also has a board with an ATmega128 chip, which has the trim crash problem. (Hope I haven't got that wrong, Tom.) I still have the returned, faulty G9X board here and have confirmed the fault. But I never really got the time or inclination to investigate further. Now that I've seen this forum thread, I may have to do so, just to try and get all the way to the bottom of this mystery.
2. Whilst the resistor insertion trick certainly appears to get around the trim-switch crashing problem, it absolutely should NOT be required. Something else is wrong. I cannot stress this enough. This SHOULD NOT be required, at all. Obviously though, you have to do whatever works, in the meantime.
EDIT: Addressing this issue further; Some time back ...
MikeB wrote:NOT replacing the existing resistors, they are AFTER the de-bounce capacitor.
Adding a resistor in the wire from the trim switches will drastically reduce any spike caused when switching. Not having a resistor is, in my opinion, poor design.
The only current consumption in question here is the shorting of the capacitor to ground, by the trim (and other) switches. There can be no spike on the power rails from this. There could be an electromagnetically induced current in other wires -- inductively coupled. But that would be very short in duration and, very small. That said, if the Vss-to-AVss short is present, then there is a fairly decent sized ground loop in the wiring loom, which I guess could pick up such a spike. Seems very unlikely to me to be anything like what would be required to interfere with the MCU, though. And why not on the '64 chip?
In this case, all capacitor discharge current goes through a big fat, mechanical switch, only. This does introduce some potential for anomalous spikes, should there be ground loops involved -- as indeed there is, with Vcc shorted to AVcc on some
'9X trim switch PCBs. But this should at worst only present noise on the analogue input ports. (More on this below.)
That said, the fact that inserting current limiting resistors does
appear to solve the problem, I have to concede that there is some possibility of this transient spike being an issue. For the life of me however, I cannot see how and I cannot concur that it is, "bad design". All else being as it should be, no current should be sourced from ANY supply rail, through this. Hence, no spike -- except maybe on AVss. But IMHO, that should not cause a crash, either -- unless the chip is faulty in some manner, either by design or during fabrication.
3. I have three Turnigy branded, "V2" 9X radios and one FlySky version. The second
"V2" Turnigy branded radio I bought was the one I installed the G9X v3.2 board into. Only on that radio, there was this issue on the right hand trim switch PCB (looking from the back, with the case off) where it turned out that an error in the PCB design had digital ground and analog ground shorted together, under the white wire loom connector. The other three radios I bought did NOT have this problem.
So then, some trim switch PCBs have the shorting error and some (most?) do not -- with no apparent way of telling the difference, by just looking.
The ONLY reason I had to correct this error was because for the G9X v3.2 board (only), I changed the circuitry for reading the 13 switches (navigation x 6 and trim x 8) from 13 individual I/O pins to a 4x4 scanned matrix, using just 8 I/O pins, in order to free up I/Os for the SD card interface. This required being able to switch four virtual grounds on and off in a scanning, round-robin fashion. Having one of those grounds shorted to AVss foiled that plan.
I never actually checked the first Turnigy radio -- the one I originally hacked to make it do telemetry. That main board has since been destroyed (parts robbed off it etc) and the radio itself dismantled for spare parts. Looking in the junk drawer now, I have no idea which trim boards are which.
4. Having digital ground (Vss) connected to analog ground (AVss), however in error that may be (and it is) absolutely should NOT cause these trim switch system crashes. At worse, it should only introduce a little more noise on the analog input ports -- sticks and pot readings -- especially if using lower frequency radio modules, like 40 or 72MHz, perhaps. I have never witnessed a problem, using 2.4GHz modules -- not that I had very long to test that, since I fixed the problem on the bench, before using that radio in the field.
These switch inputs do not generate any interrupts. They are merely polled, in low priority MCU time. There is therefore no opportunity for noise on these inputs to cause a system crash -- not withstanding a faulty chip, perhaps. That said, all eight PORTJ inputs on the G9X v4.x boards do support pin-change interrupts. But there is no code anywhere in the firmware that enables those, far as I can or have ever seen.
4a. Yes, there are two inductors involved in this -- larger black casings (0805 size, I think) -- each 10uH in value and both near the MCU chip. These inductor RF-isolate the analogue supply rail from the digital rail. That is, they filter out high frequency noise that may be present on the digital supply rails, for the express purpose of making analog reads as less noisy. This is especially important for the ARef input, which is the reference voltage for the analog converters. One inductor is on the +5V rail (Vcc) and the other is on the ground (Vss). They connect Vcc to AVcc and Vss to AVss, respectively.
The error on some
trim PCB's, shorts Vcc and AVcc/ARef together, through the wiring loom, at the right hand (from rear) trim switch PCB. The error is directly beneath one of the white wire loom connectors, which has to be removed to effect correction. Again though -- this error does not
correcting, in practice, in our case, as far as my experience confirms. It certainly would not lead to system crashes, in and of itself.
5. When developing the firmware to make the ATmega2561 and '2560 chips work, I/we came across a number of anomalies, compared to the '64 chip and also at odds with the '256x data sheet. In other words, there are bugs in the design or fabrication of the chips I am using, which sourced from DigiKey -- not off eBay.
There are at least two places in the firmware where this has had to be worked around ...
5a. One relates to the PWM hardware in the chip and its relation to the normal I/O pin operation. We cannot read the current output status of a PWM output pin when in PWM module, hardware driven mode, on the 256x chips. But we can on the '64 chip and
the datasheet for the 256x chips says you can. Further more, when I first reported this, at least one commenter came back to say that they has runs tests and could not
duplicate this fault. (See my comments below about potential, "Chinese knock-off" chips.)
5b. The other bug is also relating to the PWM generator, used in this specific case to drive the PPM_OUT pin. The internal timing of timer output compare match to actual pin toggling is off by +/- a couple cycles (depending on toggle direction) on the 256x chips. It is not off at all on the '64 chip. This first showed up as errant timing in the DSM2 125,000bps signals, was later confirmed in standard PPM mode if the hardware switching mode is used and needed an annoying coding work-around to correct the timing.
5c. Again, in both cases here, how the chip actually operates is at odds with how the datasheet says it should
. Is it possible that some of us have ended up with Chinese knock-off chips? Or are all '256x and possibly '128 chips, given the reports in this thread, having some internal faults?
I should note that the one G(X board that has been reported to have the trim switch error was from the second batch of G9X boards we had made in China, by the second supplier. Both suppliers claimed to be using, "100% manufacturer original parts" -- but in this batch, ALL the 1.22V reference parts were completely stuffed and needed replacing. So I can't believe them. What I am saying here is that we have no way of knowing if the chips on those boards were in fact genuine Atmel parts, having passed all QC checks. The same goes for chips bought off eBay - especially rom Hong Kong or China. (I'm just saying. It's possible
My own field radio uses a board from that same, second Chinese batch though and does not have the trim-crash issue.
5d. Neither of these PWM/Timer related issues should have anything to do with trim switches causing crashes and they certainly do not explain why some folks are seeing problems with the '128 chip -- unless that chip has the same, potentially faulty design. However, once you find one bug in a chip, you can't help wondering if there are others -- or indeed if the chip is a knock-off, with errors.
6. If a digital input, such as those being used for the trim switches, happens to be configured as an OUTPUT in the firmware, then with a 200 ohm or even maybe as high as a 1K ohm resistor in series (or no resistor) the pin WILL still operate as a input, in this circuit. Obviously however, that input signal will clash with the digital high (+5V -- current limited) output is and will cause an internal high current loading, "short circuit". This causes excessive heating in part of the chip and, importantly in this case, loads down the Vcc power supply rail, potentially causing a system crash through the accompanying spike -- especially given that the 5V regulator in this circuit is only rated to 100mA.
I have had this exact error in firmware, several times in other projects. Inserting a higher value resistor will limit the current of the internal, "short circuit", possibly to the point where the spike is no longer sufficient to cause a crash. But everything else appears to work correctly. If a switch is held down (input held low) then the chip will become noticeably warm or even hot to the touch, but otherwise keep on trucking.
If I had to guess -- faulty Chinese clone chips not withstanding -- I would be looking here first. So lets do that ...
6a. opentx r2741/targets/gruvin9x/board_gruvin9x.cpp: Line 60: ...
Code: Select all
DDRJ = 0x00; PORTJ = 0xff; // 7-0:Trim switch inputs
... correct. PORTJ is all inputs, with internal pull-upss on.
Well then, assuming readers with this trim switch problem are using a G9X v4.x board and opentx -- as I am -- then errant firmware is not the problem. Indeed, I do not experience the problem. But there are surely other variables at play and I haven't even looked at code written for the '128 chip.
It would be good if someone else could triple-check the firmware (th/er/openXx) relating to whatever I/O port it is where this trim switch crash problem is
occurring, just to be certain that the I/O pins in question are in fact configured correctly -- IE. not as outputs and with internal pull-ups on, as in the code sample above. However, we know there is at least one G9X v4.2 board where the fault occurs.
If that's all good -- and I suspect it is -- then I'm going to lay a bet on the idea of Chinese knock-off chips having polluted the market place. Proving that could take a lot of energy ... unless perhaps someone who definitely has the trim switch crash problem could go to the expense and trouble purchasing a known genuine chip directly from Atmel's online store and seeing if that fixing the problem -- or informing us that they already have a known genuine chip and it's still got this problem.
In summary then
, it seems to me that only thing left to have checked would be for someone who has the trim-crash problem and
who can confirm also having the Vss-to-AVss short on the right-hand (viewed from back) trim switch PCB, to remove and remedy that fault, then test for the trim-crash fault again -- without the 1K resistors inserted. Personally, I cannot see the crash problem being fixed by simply removing that errant Vcc-to-AVcc short. But I've been wrong (many times) before and it would seem this particular route has not yet been tried.
I'm still backing faulty chip design and/or fabrication -- possibly due to Chinese knock-offs as the most likely, true cause. Then again, we have more than fifty G9X v4.2 boards out there -- with Atmega2560's on them -- that do not have appear this trim crash problem. At least one does. Maybe it just comes down to some people having the shorted Vss-to-Avss problem and most folks not?
Failing all that, let's just all go buy a Fr-Sky Taranis!
(I don't have one yet, fwiw. can't yet afford it.)