VBAT Problem with R1512 on 2560 based FC

[Nicksdesign]

I've encountered a confusing problem with the VBAT function when running R1512 on a 2560 type FC. Logically, it acts like a hardware problem, but since software is the only option for dealing with it, and since it would be a very strange hardware issue, I'm putting this in this forum.

Some more details: The FC is a HK MWC Pro board which is based on the Mega2560. The software is R1512 (now not the latest) and I'm running with SBUS.

The problem: The battery voltage being displayed on the GUI makes no sense. This is NOT a VBATSCALE issue. To diagnose the problem I am using a voltage divider using a 15 turn pot. I have a volt meter reading the actual voltage on the assigned VBAT pin A15. I also have the raw result of the ADC read being displayed on the GUI as debug[1]. (Thanks to the person who left that line in the source code. I would have never thought of it. I had no idea what those fields on the GUI meant.)

With 4.9v applied to the VBAT pin, the 2560 data sheet says that the result of the ADC should be ~1000. The actual number returned by the analogRead is about 200. What the ??? I compared this to the same voltage on A14 as VBAT and the result is about 260. So it's not just A15.

Taking a bit of risk, I slowly and carefully raised the voltage on A15. While the data sheet says there are clamping diodes to VCC and GND for all I/O pins, I did not observe any effect as I slowly raised the voltage above 5v. If that clamping diode is there, it didn't do anything. It should have clamped the voltage to one diode drop above 5v. To get a return value of 1000, I had to raise the voltage to around 12v. That should have made bad things happen. But, as far as I can tell, without actually flying my quad, all other functions are operating normally.

The ADC on A15 continues to function as if the reference voltage is around 13v.

Anyone have any ideas? I fly on 4S and I could set my divider to work. BUT it SHOULDN'T work!

Nick

[clough42]

What voltage do you have on AREF (pin 98)? I had very confusing things happening when my AREF was bridged to ground.

Are you providing 5V to the board, or using an onboard voltage regulator?

[Nicksdesign]

I have been using the ESC's to supply power to the FC. The Vref measured at 3.9v. That was a surprise to me.

After some investigation, I determined that the ESC's were supplying 5v to the V+ pins for all ESC and servo (A8 - A15) connections. The uC is powered via a 5v LDO regulator which gets its power from the 5v rail FROM the ESC/servo pins. That explains the 3.9v at the uC.

The Vcc for the uC is also connected to all the 5v pins for the serial ports and the 5v I2C port.

I have a 5v switching BEC that I now have connected to the FC via the ISP pins so all serial ports are still available. My BEC provides 5.5v out and this is on all board I/O header pins and the Vcc for the uC. I'm tempted to remove the shrink-wrap to see if it can be adjusted, but it is what it is.

In any case, the result of the Vbat analogRead still doesn't make sense. With Vref at 3.9v, the result should be even greater than if it was at 5v.

With Vcc/Vref at 5.5v and the Vbat pin (A15) at 4.7v, the analogRead returns ~260. That still makes no sense. It should return ~874.

Of course, it's possible that my Mega2560 is defective. But, that would be a rather strange defect. All other functionality is ok. And if I assign Vbat to A14, the analogRead returns a similar low value. It's just weird. When I raise the A15 input above the Vcc, I should see the input being clamped to a diode drop above Vcc, but I observe no clamping at all. Even after raising the A15 pin to >13v there seems to be no negative effect on the uC. That's at least something good because I'd rather not buy another FC at this time.

Because the Config GUI takes nearly 5 minutes to start up and connect AND it never seems to be able to re-connect after re-flashing, I'm reluctant to try all 8 analog inputs. I suspect that something is going wrong with my compile of MultiWiiConf.pde too, but that's a matter for another thread.

Unless a solution can be found, I guess I'll just have to wait until I can buy another FC board to be able to implement VBAT. Or, since I'm using a pot for a voltage divider, I might just crank it up until I get a usable value and see what happens.

Nick

[Nicksdesign]

After some more testing, I've decided that there is clearly nothing wrong with the MultWii code and my Mega2560 is useless for measuring any voltage on any of the analog inputs. I guess I'll just have to buy something else to be able to use VBAT.

Nick

[Nicksdesign]

PROBLEM SOLVED!!!

I tend to be a bit stubborn so I kept reading the 2560 data sheet. The ADC can measure single ended inputs as well as DIFERENTIAL inputs! So I decided to see if the ADC was configured for differential inputs. I grounded A9 (the negative pin for differential inputs in PORTK. Now the results of the ADC read correctly. The darn thing works after all!

NEW QUESTION: Does anyone know how to set the PORTK ADC to differential/single ended?

Nick

[Nicksdesign]

Post edited on 7-12 to correct error!

I think I have found a solution for reading the analog inputs on a Mega2560 based FC. At least, it works for mine. I'm running development version R1512.

The Problem: For my HK Pro Mega2560 FC, the ADC is configured as differential at 1X amplification. I suspect that any Mega2560 based board will have the same problem. After hours of searching through the MultiWii source and the Arduino programming reference, I have been unable to find ANTHING that sets the configuration of the ADC. The Mega328's ADC only works in single ended mode and thus there is no need to set anything for FC's using it. Perhaps this is an oversight?

It took a bit of study and a leap of faith: if it compiles, it can't be too dangerous, right?

Code: Select all

#if defined(VBAT)
 case 1:
 {
 static uint8_t ind = 0;
 static uint16_t vvec[VBAT_SMOOTH], vsum;
 ADMUX = ADMUX && B1100111; // Set ADC mode to single ended. Has no effect for 328p
 uint16_t v = analogRead(V_BATPIN);
 debug[1] = v;
 #if VBAT_SMOOTH == 1

With this line added, it should be possible to use #define OVERRIDE_V_BATPIN Ax to assign VBAT to any unused analog input pin.

Use at your own risk because I'm not an expert at programming this stuff. And since I broke a motor shaft while trying to straighten it, it will be a couple of weeks before I can flight test it. On the bench, the GUI says it works.

It would be nice if others would test this on other FC's. I only have the one board. I suspect this will be needed to use ANY analog read on a Mega2560 FC, but I have only tested it for VBAT.

Nick

[Hamburger]

It would be nice if others would test this on other FC's. I only have the one board. I suspect this will be needed to use ANY analog read on a Mega2560 FC, but I have only tested it for VBAT.

Nick,
I assume when you say Mega2560 FC, you really mean the one brand you have?
Just to clarify, on my two different brand FCs with mega 2560 mcu, analogread does not suffer from the symptoms you describe but works.

[Nicksdesign]

Hamburger, thanks for commenting. I was hoping that someone with a more experience with 2560 based FC's would weigh in.

The question then is why is mine different? As far as I can tell, the ADC mode is only software controlled within the 2560. While my board is a Hobby King one, that shouldn't affect the ADC mode. I see no way to set the ADC mode via a hardware connection to one of the 2560's pins so it can't be the board's design or quality. I suppose my individual 2560 could be weird, but that seems a weak explanation.

When running the same software as everyone else, it is pretty clear that my 2560's ADC is in differential mode: with A9 open, or used as a receiver input, the measured voltage makes no sense; with A9 grounded it works as expected. Add the line ' ADMUX &= B1100111;' to the code and all is well with A9 open. I observed the same behavior using A14 as the VBAT pin. This behavior has been consistent through many compiles and re-flashes.

In all current versions of MultiWii, the ADC mode is assumed to be single-ended, but there is nothing in the code actually setting it in to that mode other than that the uP should be in that mode after it initializes. The assumption seems weak to me and my experience shows that it can not be relied upon. Explicitly setting the ADC mode with ADMUX should remove the chance of the ADC mode being wrong and causing confusion. I plan to add the code to all my sketches for any 2560 based FC. (I think it would be better located in setup().)

Would it be wise to add to the released versions so others don't have the same problem? If it could be a problem for me, than it could just as easily be a problem for others. It would cost nothing, other than a couple of bytes of memory space that the 2560 can well afford, and if placed in setup(), it would add nothing to the loop time. I ask only that the development team consider it.

Thanks for listening.

Nick

[Hamburger]

Nick,
I understand the issue. I have spent some time on tweaking accuracy vs. performance for analogRead() in MWii (used for vbat, powermeter and (new) rssi). At one point I was down to experimenting with external reference voltage to bypass potential side effects. Fortunately this seemd to have been not neccessary. That was on 328p boards.

Is the ADMUX value dependant on the acutal pin(s) used? Can you point me to some documentation, please?

[doppler]

http://www.atmel.ca/Images/doc2549.pdf

ADMUX references start on page 271.... don't drown in that sucker...

Andrew

[Sebbi]

Please note that ADMUX (bit 0-4) together with bit 5 of the ADCSRB register controls the ADC channels being used on an ATmega2560.

The code mention above therefor sets the ADC tzo pin 7 (btw: only pin 0-7 can be used for differential measurements) and the voltage reference to the internal 2.56V one instead of the default ACC. Maybe the later is causing your board to work "as expected"? The MUX-bits certainly have no effect since "analogRead" is resetting them (and for choosing A15 you should have been writing ADMUX |= 0x07; ADCSRB |= (1 << 5); anyway ...)

Code: Select all

ADMUX = ADMUX && B1100111;

This line has sideeffects (especially since it uses the logical && and not bitwise &) for other users and shouldn't be implemented. If you want to change the analog reference, use the Arduino function "analogReference" (http://arduino.cc/de/Reference/AnalogReference).

Documentation about this and other analog registers can be found in this PDF: http://www.atmel.com/Images/doc2549.pdf (p. 289 and following)

[Nicksdesign]

Documentation is always nice. All my information ADMUX comes from the Mega2560 data sheet. You can get a copy here: http://www.atmel.com/Images/doc2549.pdf

The ADC is described in section 26, starting on page 275. The part relative to ADMUX starts on page 289. In particular, refer to Table 26-4 starting on page 290. ADMUX, with bit 3 of ADCSRB, controls the Vref selection, the ADC mode, and which Ax is being read.

The Arduino reference makes no mention of the mega2560's ADC's modes and provides no information on how to control them. It seems to assume that it works only in the single ended mode and never otherwise. I couldn't even find any mention of the Mega2560's ADC modes in the Arduino user forum. The constants DDRK (used in rx.ino to set the port K pins to inputs) and ADMUX are completely absent for any Arduino documentation that I have been able to find. When I tried ADMUX it was simply a guess based on MultiWii's use of DDRK. If DDRK exists and works to set the port K pins to input mode, then why not ADMUX?

After studying table 26-4, it became clear that ADMUX bits 3 & 4 control the ADC mode: if both are set low, the ADC is always in single ended mode.

The reliance in MultiWii on the ADC just 'being' in the appropriate mode is risky. The fact that my Mega2560 comes up in differential mode proves that it can't be relied upon. MultiWii doesn't even explicitly set the Vref to the uC's Vcc (assumed to be 5v). Vref may not even BE 5v because the Mega2560 may not be running on 5v! If other Mega2560 based boards are like the HK one, the Mega2560 is powered off a 5v regulator that, in turn, gets its supply from one of the 5v pins on the board's Ax/Dx headers. The result is the Vref could be 3.9v as that's about what a LDO 5v regulator will produce if it's being supplied by 5v. This, of course, effects the values returned by the ADC.

MultiWii also doesn't enable the internal pullup resisters on port K pins which leaves them floating if they are not being driven by external means and it is very poor design to leave digital inputs floating. This tends to produce oscillation in the input logic which generates substantial noise and increased power consumption. The increased power consumption may not matter relative to the power consumed by the motors, but it's still bad practice.

This may be a bit presumptuous being so late to the MultiWii game, but in my opinion, as a matter of good design, MultiWii should, in setup(), explicitly set the ADC mode. It also should use pinMode() to set the port K pins to inputs and enable the pullup resisters on any input that may not be actively used since pinMode() is documented and DDRK isn't. This would make it much easier for non-experts to understand the code. Unfortunately, ADMUX, while undocumented, seems to be the only way to set the ADC mode. It would also make it easier for users to customize the use of all the analog inputs when they are not needed as inputs from the receiver.

I propose something like this in setup() would be better:

Code: Select all

#if defined(MEGA) {
  ADMUX &= B11100111;  // Set ADC mode to single ended
  analogReference(DEFAULT);  //Set ADC reference to Mega's VCC
  pinMode(A0, INPUT_PULLUP);  // Set A0 to input with internal pullup resister enabled for use as digital input
  //pinMode(A0, INPUT);  // Set A0 to input with internal pullup resister disabled for use as analog input
  .
  .
  .
 pinMode(A15, INPUT_PULLUP);  // Set A15 to input with internal pullup resister enabled for use as digital input
  //pinMode(A15, INPUT);  // Set A15 to input with internal pullup resister disabled for use as analog input
 }

This would use more program memory space, but the Mega's are not lacking for memory space.

Nick

[Nicksdesign]

Sebbi, your post arrived while I was composing mine.

The && resulted on only the bits 3 & 4 being affected.

All analog inputs can be used in differential mode. Take a better look at Table 26-4! analogRead() does not affect the input status of the pin. I believe one can analogRead() the pin even if it is an output. I saw nothing to the contrary in the datasheet or the Arduino reference. I've spent hours studying the dang things.

It's only my opinion, but I think it is much better, and safer, to explicitly set Vref and the ADC mode than to rely on default that may be changed by unseen code inserted by the compiler somewhere. The fact that DDRK and ADMUX work means that the compiler has inserted code that uses them. The use of pinMode(), rather than DDRK, to set the analog I/O pins to inputs is much easier to understand.

If anyone knows where the use/action of DDRK and ADMUX is documented, I would very much like to know! I don't like using them without explanation.

[Nicksdesign]

DAMMIT! Now I really screwed up. I did have it right! I DID want &&!! Now to change it back to the way I had it.

Nick

[Sebbi]

From wiring_analog.c:

Code: Select all

int analogRead(uint8_t pin)
{
   uint8_t low, high;

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
   if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
   if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(__AVR_ATmega1284__)
   if (pin >= 24) pin -= 24; // allow for channel or pin numbers
#else
   if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif
   
#if defined(__AVR_ATmega32U4__)
   pin = analogPinToChannel(pin);
   ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
#elif defined(ADCSRB) && defined(MUX5)
   // the MUX5 bit of ADCSRB selects whether we're reading from channels
   // 0 to 7 (MUX5 low) or 8 to 15 (MUX5 high).
   ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
#endif
  
   // set the analog reference (high two bits of ADMUX) and select the
   // channel (low 4 bits).  this also sets ADLAR (left-adjust result)
   // to 0 (the default).
#if defined(ADMUX)
   ADMUX = (analog_reference << 6) | (pin & 0x07);
#endif

   // without a delay, we seem to read from the wrong channel
   //delay(1);

#if defined(ADCSRA) && defined(ADCL)
   // start the conversion
   sbi(ADCSRA, ADSC);

   // ADSC is cleared when the conversion finishes
   while (bit_is_set(ADCSRA, ADSC));

   // we have to read ADCL first; doing so locks both ADCL
   // and ADCH until ADCH is read.  reading ADCL second would
   // cause the results of each conversion to be discarded,
   // as ADCL and ADCH would be locked when it completed.
   low  = ADCL;
   high = ADCH;
#else
   // we dont have an ADC, return 0
   low  = 0;
   high = 0;
#endif

   // combine the two bytes
   return (high << 8) | low;
}

Everything is taken care of by this function. The voltage reference is being set to whatever the user has chosen with analogReference() (default being DEFAULT = ACC, all set in code). It's always single ended ...

Modifying ADMUX before this function doesn't affect it.

But I agree with you, it is not clear where MultiWii sets the analog pin that is configured in config.h to input ... (pullup shouldn't be needed when the pin is connected to something that you want to measure and you can't blindly configure all analog inputs, because those pins could be used for other purposes (I don't really know).

P.S.: && is logic AND ... the result can only be 0x00000001 or 0x00000000

[Nicksdesign]

Sebbi,

It'll take me some time to fully analyze the code you posted. First you will have to tell me where that code is because IT IS NOT part of the MultiWii sourc. Actually, don't bother. That is clearly a place regular Arduino users are not supposed to go. And I DEFINITELY don't want to go there. If the Arduino developers made a blunder, I'd rather not look for it. Frankly, I never wanted to get any deeper into the code, or the operation of the Mega2560, beyond using OVERRIDE_V_BATPIN to assign VBAT to A15.

I do understand the function of ADMUX. To be clear, my inserted line of code DOES NOT change the Vref. 'ADMUX && B11100111' only sets the two bits low, leaving the others unchanged. (I did make the small mistake of miscounting bits and only 'anded' seven bits. But since the last bit needed to be low too, it didn't cause a problem.) And if those two bits were already low, my added code would do nothing, I would never have had a problem, and I would never have looked for a solution. Clearly something is changing the ADC mode.

I did not rely on ADMUX to select A15 and my inserted code had no effect on those bits. Why would I when analogRead(A15) does it all for me?

It is possible that my Mega2560 is uniquely faulty. But the probability of that, given that it works correctly otherwise, is rather low.

However, that doesn't change the fundamental problem. If that is really all that is needed, why is my Mega2560 ALWAYS in differential mode when analogReading the VBAT pin? If the ADC mode is single ended because the Arduino IDE set it that way, my inserted code would accomplish nothing. But, after that line is inserted, my Mega2560 CORRECTLY reads the pin. Without the added line, it always returns nonsense UNLESS I tie A9 to gnd. (A9 is the reference pin for the port K pins with the ADC is in deferential mode. I also observe the same behavior on A14) If my Mega2560 was in single ended mode, grounding A9 would have no effect. The fact that I get a correct read when A9 is grounded and junk when it's not, indicates to me that my Mega2560 is in deferential mode unless I explicitly set it otherwise.

I have no problem with accepting that the Arduino IDE inserts code that sets the ADC, and other things, to default values. (It would, however, be oh so nice if they would tell us what they have done.) If so, then there is no need to set them explicitly in MultiWii. But, something caused my Mega2560 change the ADC mode to differential. It is as if they never expected anyone to read the Mega2560 datasheet.

Do you have any idea why? I really can't afford to toss this board and replace it. But, if it is truly just my board, then this is much ado about nothing. I'd much rather buy more plastic to feed my 3D printer.

My opinion about using pinMode() instead of DDRK to set the analog pins to input is a separate matter. It's just about making it easier to understand and easier for one to use unneeded Ax pins for other things than digital inputs. Especially since the use/meaning of DDRK is hidden to all other than the few who know where to look. I spent many hours looking for where it was defined and where, in time, it would be used without success. It would be better if it wasn't necessary to use ADMUX in the MultiWii source too. I don't like using ADMUX because I can't know where/when it has an effect. Sadly, the Arduino developers decided to hide a significant amount of functionality.

When it comes to enabling the pullup resisters, even Atmel recommends not leaving digital inputs floating.

To be clear, I would really like to not change anything in the MultiWii code. Even though I was once a skilled digital hardware designer and a computer system architect, that is not what I prefer to do as a hobby. But, since multirotors are a significant risk to life, limb, and property, I'd really like to know what is happening and how to assure that there should be no problem.

Gad! All I wanted was to read VBAT! I could have been learning how to fly FPV!

Nick

[Sebbi]

1) Arduino abstracts whatever special treatment different hardware wants. The reason is simplification, so a user of the Arduino language doesn't have to worry too much. Of course this hides a lot of functionality of different hardware and that's the reason MultiWii replaced Arduino functions with their own AVR/Atmel code.

2) wiring_analog.c can be found in the Arduino code. This and other files in the same directory give you functions like analogRead() which sets everything you need to read an analog value for you. As you can easily see, it completely resets the ADMUX register, so anything you set it to before calling analogRead() has ABSOLUTELY NO EFFECT.

But since you are clearly observing some change whether or not you put that line before analogRead() I suspect ghosts ... sorry to put it that way, but this is the only explanation left to me

'ADMUX && B11100111' will be either 1 or 0, it doesn't set bits to 0 (http://en.wikipedia.org/wiki/Bitwise_operations_in_C) ... if you want to clear bit 3 and 4, you need to write 'ADMUX &= ~(3 << 3)' ... but again, analogRead() resets ADMUX, so it wont have any effect ...

P.S.: If it works for you with this modification or pulling A9 to ground, then by all means, modify the code/hardware and learn to fly FPV

[Nicksdesign]

Sebbi, thanks for being kind to me. Every time you told me that 'ADMUX && B11100111' was wrong, I went back to the language reference and checked to verify the meaning. Each time I reached the same wrong conclusion. You are correct that I used the wrong operator. I should have used 'ADMUX &= B11100111' or 'ADMUX = ADMUX & B11100111'. [B11100111 is so much easier to understand than ~(3<<3)]

I really do understand the concept of abstraction. I even used to be able to read the definitions of things like '&', '&&', and '&=' and correctly use them! I'm getting old and these kinds of errors are not fun! It's been almost 40 years since the first time I programed a uC in assembly! That uC was my first 'personal' computer. That was a very good lesson on the benefits of abstraction! High level languages are so much easier!

Based on the contents of wiring_analog.c, I agree with you that no matter what I did with ADMUX it was all for naught.

Even though I observed an apparent correction with that line of code and with grounding A9 multiple times with both A14 and A15, ghosts is probably the best explanation.

To verify, I removed that line of code, re-flashed my board, and ran it again this morning on the bench. The ghost is gone! My Mega2560 now reads the analog voltage fine. Why it didn't every time I tried it last week, and it that was a lot of times, I have no real idea. I spent a long time working that problem before I even thought about posting anything here.

The only difference between this morning and when I started is that my Mega2560 was running on 3.9v then and it's now running on 5.5v. But, I took that into account as soon as I measured the Vcc. That shouldn't have affected anything other than the values in the voltage divider and I built a new variable divider just so I could be sure to keep the voltage below Vref and vary it to test different voltage levels on the analog input. (Batteries don't change much or fast enough).

Oh well!

Thanks again for not ridiculing me.

Nick