Nano analog issue post bootloader update

Development Tools Uploading
1

I have a Nano 3.0 clone (old bootloader). Every few days or so the device freezes and as yet I've not been able to pinpoint the problem in the code. So I decided to add a watchdog, which upon testing I found the watchdog issue with the old bootloader. I burned the new bootloader (via USBasp) without issue. However now the analog input values are wrong. These analogs are simple thermistor potential dividers. The temperatures are now all reading high. It very much looks like the either the analog reference has changed or the digital output level has changed (the potential divider is supplied by a digital output).

If I restore the old bootloader the analogs go back to normal. Any ideas what might cause this behavior?

I have a spare Nano and tomorrow I shall set up a test rig to measure some values as it is difficult to get any measurements where actual device is installed.

2

I cannot imagine any connection between the bootloader and analog measurements from the sketch. The bootloader has only one functionality, to upload the sketch and since the next reset it is all directed by sketch.
You forgot mention, what does it mean the old bootloader and the new bootloader. Be specific. Also, post your schematics and code.

It very much looks like the either the analog reference has changed or the digital output level has changed (the potential divider is supplied by a digital output).

Why do not to check it? Write a code to test your suspicions.

3

I set up a test rig and was able to replicate the issue which I have now resolved. I will explain so it may hopefully help somebody in the future should they encounter the same issue.
The issue was caused by an error in my code and how specifically the D13 (led pin) acts under the different bootloader revisions.
This circuit is using D13 to drive a thermistor potential divider.
Essentially when running the old bootloader if the pinMode() is not set for D13 it will still output high (5v) when a digitalWrite high command is sent. Whereas when running the new bootloader the output floats around 1.7v when a digitalWrite high is sent if the pinMode is not set, as you would expect.
This code works with the old bootloader but not with the new:

void setup() {
  Serial.begin(9600); 
}

void loop() {
  digitalWrite(ledPin, HIGH);
  testSample = analogRead(a0Pin);
  Serial.println(testSample);
  delay(500);
}

Of course the code should be:

void setup() {
  Serial.begin(9600); 
  pinMode(ledPin, OUTPUT);
}

void loop() {
  digitalWrite(ledPin, HIGH);
  testSample = analogRead(a0Pin);
  Serial.println(testSample);
  delay(500);
}

In the original code I set all the pin modes except D13 so it work by luck and I would have of course found the issue sooner. However the bootloader revision clearly affects the way pin D13 functions.

4

...the output floats around 1.7v...

Normally all pins should be in high impedance state after the bootloader ends and MCU starts execution of the sketch. It is incorrect to suppose D13 is in output HIGH even though the old bootloater does it this way.
You have to take a care of it.
Of course, some features are builted in the Arduino startup code but they have nothing with the bootloader.

Karma for the solution and have fun with Arduino! :wink:

5

Essentially when running the old bootloader if the pinMode() is not set for D13 it will still output high (5v) when a digitalWrite high command is sent. Whereas when running the new bootloader the output floats around 1.7v when a digitalWrite high is sent if the pinMode is not set, as you would expect.

The output does not actually float with the new bootloader. On a Nano, D13 is connected through a resistor to the 'L' LED (which is then connected to ground). Writing a HIGH to D13 activates the internal pullup resistor, which supplies a small current to the LED and is probably visible if you are in a dimly lit room. Because of the connection to the LED you also have to be careful using D13 as an input on a Nano because it will act as a pull-down instead of a high-impedance. The UNO drives the LED through a buffer so does not have these problems.

Incidentally, if you burn the UNO bootloader to the Nano instead of the new Nano bootloader, you will gain 1.5K of flash memory for your code, but you will need to remember to use UNO as the board type in the IDE when programming the board. The UNO and new Nano bootloaders are actually identical, only the fuse settings that specify the flash memory allocation for the bootloader differ. When the change was made from the old Nano bootloader to the new Nano bootloader, the flash memory allocation was not changed (probably for compatibility reasons), resulting in an allocation of 2K of memory for a bootloader that only needs 512 bytes.

6

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.