Share
Tapatalk

Error uploading code

Error uploading code

4

PostMar 02, 2017#1

Hi,

i transfered successfuly the code i wrote based on the examples and all worked fine. I started then tinkering with the code and changed the serial speed to 9600

Code: Select all

Serial.begin(9600);
  Serial.println(F("Example: Power Down - Periodic"));

  Serial.println(F("Putting Radio and SPI Flash to Sleep"));
and on my loop function i had

Code: Select all

 digitalWrite(T2_WPN_LED_1, HIGH);
  delay(25);
  digitalWrite(T2_WPN_LED_1, LOW);

  // We old the MCU for 8 seconds so you can measure the current
  delay(25);

  Serial.println(F("loop"));
The changes uploaded correctly but after that i was unable to upload new code changes.

Code: Select all

avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xbd
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xbd
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xc1
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x35
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x29
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xfe
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x0c
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0xbd
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xbd
An error occurred while uploading the sketch
Is there any way to reset to default program or to change the speed on the Arduino IDE so i can reset the speed to 115200 and work normally?

I'm uploading with FTDI to USB 3.3v

PostMar 02, 2017#2

Ok, Factory Reset worked (Duh...) :)
21

PostMar 19, 2017#3

I am having a simular problem. It seems I can upload only once and to upload a new sketch it requires a factory reset to upload again. I am not using or changing the serial port. This is which multiple FTDI adapters, one with RTS and another with DTR

Could this be caused by low-power mode?

Thoughts?

-tim
5

PostMar 21, 2017#4

I also have exactly the same problem
Have done with all 6 of these I've bought

At first I thought it might be my cheap eBay bought FTDI board so I bought a legit
and lot more expensive one, from a reputable supplier, still got the issue though.
I just assumed it was a 'feature' of such a new board, However it would be nice to know if there's a fix

For info, I'm using the IDE etc on Mac OS
1885
1885

PostMar 22, 2017#5

It seems to be a issue related to the low-power, I'll hook the oscilloscope and investigating in which situations that might happen and post the findings.

Here the current situation:
The Serial Interface is the same used by the Arduino Pro Mini, which is very simple: basically the FTDI pins are directly connected to the TX and RX on MCU Pins, the Power goes though the LDO and the DTR/RTS goes to the MCU's Reset Pin via a 0.1uF capacitor.

When the board is powered, the MCU Reset pin will become HIGH, because there's a 10K resistor to the 3.3V Rail 1. This will put the MCU in running mode.

What actually happens during the programming, the FTDI adapter pulls the Serial DTR/RTS line LOW, which will force the the capacitor connected between the MCU Reset Pin and the FTDI adapter to charge. During the charging time the MCU Reset will become low for a very short period, but enough to make the MCU Reset and run the bootloader, which will start communicate with AVR Dude and accept new firmware.

What seems to be happening is that the MCU is not being restarted by the DTR/RTS signal when the MCU is in sleeping mode. It shouldn't have nothing to do with the upload or sketch speed as the bootloader is not running yet. Actually it appears that the capacitor between the Reset and the DTR/RTS line never discharges (or takes very long time to discharge...).

PostMar 22, 2017#6

Hi again,

I've performed a few tests and I could replicated the problem. I've decided to leave my steps debugging the issue as it might be interesting for some of you - solution at the end!

For testing today I loaded a "lowPower" code, which puts the SPI Flash and RFM69 to sleep, followed by the MCU. Very similar to the "PowerDown.wakePeriodic" example but without the 8 seconds awake.

After uploaded the firmware I tested multiple times uploading the same code and using the "Reset Terminal" command from Putty or similar Serial Terminal software. I did it at least 30 times without error initially...

Below some scope captures. Note that the "Blue" signal is from the DTR/RTS pin on the FTDI adapter and the "Yellow" is from the RESET line on the Whisper Node:


As you can see above, the DTR normal state is LOW and the RESET line is kept high. When the IDE needs to upload a new firmware, before the upload begins, AVRDude sends a "Terminal Reset" to the FTDI, which will cause the DTR to go HIGH for a few milliseconds (500ms), after the whole process the DTR goes LOW again.

Here what happens: Once the DTR goes HIGH it will basically reverse the charge on the capacitor sitting between the FTDI DRT pin and the RESET line (C11). Next, as soon the DTR changes back to LOW, the capacitor starts to recharge via a 10K Resistor (R4). The recharge step takes some time and this is when the MCU "notice" that the RESET line is LOW, causing the micro-controller to reset.

Below the zoom from the time the capacitor starts to recharge:


As you can see the RESET line is kept below 1V for a few micro-seconds (100-150µS), and according to the ATMega328p's datasheet, 2.5 micro-seconds are enough to cause the MCU to reset:


I tried everything again without the scope probes connected, and still I could't see the issue. I was doing all tests using Eclipse Arduino, which has a very nice interface and a handy "Serial Monitor" which connects and disconnects to the Board just before and after the firmware upload. At the end, when re-doing some tests on the Arduino IDE things start to behave similarly as reported and I could identify the issue.

The real problem and solution.

The problem is a non expected value in the MCUSR register, which is used by the Bootloader to define if it should listen for new Firmware or jump to the Main Program. The MCUSR contains the cause of the MCU reset and is the cause is "External Reset", the bootloader will "listen" for a new firmware. But apart from that, the bootloader also look for other causes to handle things like self-programming and factory reset...

Basically when the MCU is in running mode and the External Reset is performed (by the FTDI via RTS), the MCUSR will have only the "External Reset" bit set. But when the MCU is at sleep and the same kind of reset occurs, more bits might be defined, confusing the bootloader.

To fix the issue a new version of the bootloader has been published. The change is very small: in case the MCUSR has the "External Reset" bit set, the bootloader will not look any further for any other MCUSR bit and prioritize the programming via Serial.

The new bootloader is available to install/update via the Board Manager. If you don't have an ISP programmer, any other Arduino, or even another Whisper Node can be used. If necessary I'll publish mode details about it and will continue to research to understand why other bits are being set to the MCUSR when the MCU is reset in sleep mode.
Share