Skip to content

Unable to upload firmware to OpenLog modules #143

Closed
TimSRT opened this Issue Mar 12, 2013 · 7 comments

2 participants

@TimSRT
TimSRT commented Mar 12, 2013

I successfully loaded v3.14 onto a board that had previously had v2.5 on it but when I tried to do the same thing with three other boards that look the same/genuine (but came with v3.11 installed) the bootloader doesn't seem to be working - the command window extract below shows the successful operation (on the older board) and then two unsuccessful attempts with the other boards. I am using the "apply power then hit return key" method. If I leave it too long the response is "avrdude.exe: stk500_getsync(): not in sync: resp=0x00"


C:\Users\Timl\Documents\AVR\OpenLog>avrdude.exe -p atmega328p -P COM5 -c stk500v
1 -b 57600 -Cavrdude.conf -U flash:w:main.hex

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude.exe: Device signature = 0x1e950f
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be perfo
rmed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "main.hex"
avrdude.exe: input file main.hex auto detected as Intel Hex
avrdude.exe: writing flash (29354 bytes):

Writing | ################################################## | 100% 14.66s

avrdude.exe: 29354 bytes of flash written
avrdude.exe: verifying flash memory against main.hex:
avrdude.exe: load data flash data from input file main.hex:
avrdude.exe: input file main.hex auto detected as Intel Hex
avrdude.exe: input file main.hex contains 29354 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 12.36s

avrdude.exe: verifying ...
avrdude.exe: 29354 bytes of flash verified

avrdude.exe: safemode: Fuses OK

avrdude.exe done. Thank you.

C:\Users\Timl\Documents\AVR\OpenLog>avrdude.exe -p atmega328p -P COM5 -c stk500v
1 -b 57600 -Cavrdude.conf -U flash:w:main.hex
avrdude.exe: stk500_getsync(): not in sync: resp=0x31
avrdude.exe: stk500_disable(): protocol error, expect=0x14, resp=0x51

avrdude.exe done. Thank you.

C:\Users\Timl\Documents\AVR\OpenLog>avrdude.exe -p atmega328p -P COM5 -c stk500v
1 -b 57600 -Cavrdude.conf -U flash:w:main.hex
avrdude.exe: stk500_getsync(): not in sync: resp=0x65
avrdude.exe: stk500_disable(): protocol error, expect=0x14, resp=0x51

avrdude.exe done. Thank you.

C:\Users\Timl\Documents\AVR\OpenLog>

@nseidle
SparkFun Electronics member
nseidle commented Mar 12, 2013

I'm trying to map everything out in my head:

You loaded successfully v3.14 onto a board that had v2.5.
You are unable to load v3.14 onto two boards that have v3.11 on them

I would not be surprised if the v2.5 board required a slower baud rate (19200bps) because the bootloader may be pre-Optiboot. but it looks like you were successful at 57600. I'm not entirely sure why v3.11 boards are having an issue.

"avrdude.exe: stk500_getsync(): not in sync: resp=0x00" is usually an indicator that either the baud is off or the target is not getting reset correctly. I recommend using the Arduino IDE as it will toggle the DTR pin to reset the target and make life a lot easier.

@TimSRT
TimSRT commented Mar 12, 2013

I successfully flashed the v2.5 module back to v1.61, then up to v3.11, then v3.14 – all using avrdude command line @ 57600bps and the "toggle power" method to activate the bootloader, I'm quite familiar with that kind of thing. I cannot flash any of the later boards that I received from www.hobbytronics.co.uk that happened to have v3.11 already loaded. I bought about 10 of the OpenLogs last year. I think it might be a hardware issue with those boards, perhaps? I have emailed Hobbytronics about the problem as well.

"avrdude.exe: stk500_getsync(): not in sync: resp=0x00"

I have also seen: resp=0x31 & resp=0x65 , which I think may be garbage / coincidental data generated by the OpenLog when applying power: resp=0x00 tends to occur when I leave the power applied for longer before pressing for the avrdude command line or if is pressed before applying power.

Either way the Bootloader isn't Bootloading on those later boards for some reason. I will next try using the DTR line and the IDE to re-flash those boards as per your suggestion.

@nseidle
SparkFun Electronics member
nseidle commented Mar 12, 2013

Hrmm. The test procedure for OpenLog is pretty rock solid but there's always a chance that something went wrong. I am happy to do a board swap to do some hardware debugging if you've exhausted ideas on your end. Let me know.

@TimSRT
TimSRT commented Mar 13, 2013

Unfortunately my USB - TTL-232R cable doesn't have the DTR signal - only RTS and CTS. I would have to get another type of adaptor in order to make use of DTR :-( I will try and find one. It would be good to know why the boards don't load firmware though...

@nseidle
SparkFun Electronics member
nseidle commented Mar 15, 2013

I'm at a loss at to what could be going wrong with your earlier OpenLogs. Shoot me an email nathan@sparkfun.com and we'll chat about swapping boards.

@TimSRT
TimSRT commented Mar 27, 2013

I've now had a chance to experiment with the FTDI + Crossover method: I'm able to flash v3.14 onto the boards using the Arduino IDE – Great! I am still unable to flash using the "apply power" method to start the bootloader (same result on newer loggers supplied with v3.13 on them – I either get "not in sync: resp=0x00" or 0x12, timing dependent).

So, at some point between the v2.5 loggers and those that shipped with v3.11 something appears to have changed in the firmware or hardware that prevents the user from following the power-on boot-load + command line method outlined in the wiki (e.g. using COM7):

"avrdude.exe -p atmega328p -P COM7 -c stk500v1 -b 57600 -Cavrdude.conf -U flash:w:main.hex"

It seems only the method that toggles the DTR line for reset works for later boards – maybe that 500ms window has disappeared?

@nseidle
SparkFun Electronics member
nseidle commented Apr 8, 2013

I'm chalking this up to the switch from the Duemilove style bootloader to the more recent Optiboot bootloader. Trying to time the reset sequence is hard. We recommend using an FTDI connection so that the software can reset the target and get the timing correct. Closing issue. Let us know if you have any more problems.

@nseidle nseidle closed this Apr 8, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.