Interrupted sketch upload results in bricking?

Using Arduino Installation & Troubleshooting
#1

Hi,

I have a Japanino board (basically a clone of the standard board with ATMega168V), which was working fine so far. Today I was uploading a sketch, and by accident during the upload I clicked the upload button again. The upload failed, and since then the board is unusable. If I try to upload another thing, it just times out with

avrdude: stk500_recv(): programmer is not responding

and upon turning the board on, no reaction to the reset button, nor does the L LED light up (which would mean there's a functional bootloader, as much as I know).

Could that interrupted upload result in bricking or killing the board? Or the bootloader got damaged somehow? How could I test these things, or is there a way to fix it?

#2

Sounds like the bootloader got corrupted. Does the serial port show up in the Tools menu? What type of board is it?

#3

imrehg:
Could that interrupted upload result in bricking or killing the board? Or the bootloader got damaged somehow? How could I test these things, or is there a way to fix it?

It should not do that (get killed). Do you have another board? (you could test the first with the second)

#4

Yes, I have another board, how could I test the functionality of this one?

#5

Follow the instructions here:

#6

Thanks, I'll check it out and get back with the results.

#7

Hi, finally got the Chip Detector sketch working. The chip on Japanimo is ATmega168V-10AU, added the signature to the sketch such as:

 { { 0x1E, 0x94, 0x06 }, "ATmega168V", 16 * kb,       256 },

The 16kb I know, the 256 bootloader size I just guessed based on the rest of the chips. The output of the detection is the following:

Atmega chip detector.
Entered programming mode OK.
Signature = 1E 94 06 
Processor = ATmega168V
Flash memory size = 16384
LFuse = D2 
HFuse = DE 
EFuse = F8 
Lock byte = FF 
Clock calibration = B3 
Bootloader in use: Yes
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 256 bytes starting at 3F00

Bootloader:

3F00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
3F10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
3F20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
3F30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
3F40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
3F50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
3F60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
3F70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
3F80: 57 00 E8 95 00 91 57 00 01 70 01 30 D9 F3 01 E1 
3F90: 00 93 57 00 E8 95 32 96 02 97 09 F0 C7 CF 10 30 
3FA0: 11 F0 02 96 E5 CF 11 24 5C CF F8 94 FF CF 80 00 
3FB0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
3FC0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
3FD0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
3FE0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
3FF0: FF FF FF FF FF FF FF FF FF FF FF FF 07 04 06 B3 

MD5 sum of bootloader = C5 0A 34 A2 77 92 2E D2 70 BF 65 70 2B 7C 3F 4F 

First 256 bytes of program memory:

0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
10: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
30: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
40: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
50: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
60: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
70: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
80: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
90: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
A0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
B0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
C0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
D0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Some observations:

  • there was uploaded sketch on this board before, does it mean that it got erased?
  • the bootloader area starts with a bunch of 00s, is that normal? Or does that show that there's a problem?
  • the fuse values are quite different from what I used before, the settings I got from this blog post.

Any recommendation to get this board working again? :slight_smile:

#8

The chip detector does not erase or change anything.

I would not expect the bootloader to start with zeroes. And if the sketch is all 0xFF that looks like an erased program.

#9

Yeah, of course, the chip detector just reads. I meant that the original problem of interrupted upload or something that I did before hand, messed up the bootloader.

So should I try to reflash the bootloader (probably with your Atmega Board Programmer sketch) and see what happens?

#10

You should be able to use my sketch which writes bootloaders:

Alter (or duplicate) the table of stuff for the ATmega168PA to match the signature on your device, and it should go ahead and replace the bootloader. Same wiring, as I recall.

#11

imrehg:
Yeah, of course, the chip detector just reads. I meant that the original problem of interrupted upload or something that I did before hand, messed up the bootloader.

Sounds like it.

imrehg:
So should I try to reflash the bootloader (probably with your Atmega Board Programmer sketch) and see what happens?

Yep.

#12

imrehg:

  • the fuse values are quite different from what I used before, the settings I got from this blog post.

Conceivably what happened was you interrupted the fuse writing at a bad moment. Also what that blog says (the parts I can understand) relate to what the fuse settings are changed to when you upload a bootloader, not when you upload a sketch.

#13

I found some supplementary material from the magazine where I got this Japanimo board. They have an instructional pdf, where they basically say it is an Arduino Pro Mini (3.3V,8MHz)w/ATmega168.

Thus, looking at your code, I tried to flash with these settings:

  { { 0x1E, 0x94, 0x06 }, "ATmega168V",  16 * kb,       256,
        ATmegaBOOT_168_atmega328_pro_8MHz_hex,   // loader image
        0x3E00,               // start address
        sizeof ATmegaBOOT_168_atmega328_pro_8MHz_hex, 
        128,          // page size (for committing)
        0xC6,         // fuse low byte: external full-swing crystal
        0xDD,         // fuse high byte: SPI enable, brown-out detection at 2.7V
        0x04,         // fuse extended byte: boot into bootloader, 512 byte bootloader
        0x2F },       // lock bits: SPM is not allowed to write to the Boot Loader section.

The low byte and high byte are copied from the boards.txt appropriate for that Arduino Pro Mini. The extended byte and lock bits are from the ATmega168PA settings of your code. The start address is also copied, I have no idea where I could get the correct value.

The flashing works, verifies. Noticed that after flashing, the reported Extended Byte and Lock Bits are not the same in the detection code as set here. Is that normal behaviour?

After flashing, still nothing happens. Meaning, connecting the board to the PC the USB shows up, but no communication, not able to flash a new sketch. The loopback test works just fine.

Any other pointers what else to try?

#14

imrehg:
The flashing works, verifies. Noticed that after flashing, the reported Extended Byte and Lock Bits are not the same in the detection code as set here. Is that normal behaviour?

What are they, then?

#15

Flashing this:

{ { 0x1E, 0x94, 0x06 }, "ATmega168V",  16 * kb,       256,
        ATmegaBOOT_168_atmega328_pro_8MHz_hex,   // loader image
        0x3E00,               // start address
        sizeof ATmegaBOOT_168_atmega328_pro_8MHz_hex, 
        128,          // page size (for committing)
        0xC6,         // fuse low byte: external full-swing crystal
        0xDD,         // fuse high byte: SPI enable, brown-out detection at 2.7V
        0x04,         // fuse extended byte: boot into bootloader, 512 byte bootloader
        0x2F },       // lock bits: SPM is not allowed to write to the Boot Loader section.

i get

LFuse = 0xC6
HFuse = 0xDD
EFuse = 0xFC
Lock byte = 0xEF

As another try, if I flash 0x0F for lock byte (as in the boards.txt), i get 0xCF as lock byte in the verification part.

From the fuse checker site it seems to me that 0x00 or 0x04 (the code and in boards.txt) are not really valid values for the Extended Fuse? E.g. 0xFF is a valid value, and that indeed flashes as such.

Hm.... Any clue in this?

#16

I wouldn't be too worried about non-implemented bits reading back with 1 set. That does happen. According to the fuse calculator:

http://www.engbedded.com/fusecalc

both settings of the extended byte mean the same thing (the boot size).

Any other pointers what else to try?

I am wondering about the clock rate. Is this board running at 16 MHz? Also have you got the correct board selected in the Board menu? (Yes, I know it is a beginner question, but that is what I would be checking).

Also can you turn on verbose uploading information, and copy and paste the output you get when trying to upload a new sketch? Thanks.

#17

It's 8Mhz. Yeah, I keep checking the settings in the boards menu as well to be sure. Since I burned the the Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega168 firmware, I keep choosing that one.

The output is this:

hardware/tools/avrdude -C/home/lab/Greg/arduino/hardware/tools/avrdude.conf -v -v -v -v -patmega168 -carduino -P/dev/ttyUSB0 -b19200 -D -Uflash:w:/tmp/build7496679973925227559.tmp/Blink.cpp:i

avrdude: Version 5.11, compiled on Sep  9 2011 at 16:00:41
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/home/lab/Greg/arduino/hardware/tools/avrdude.conf"
         User configuration file is "/home/lab/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyUSB0
         Using Programmer              : arduino
         Overriding Baud Rate          : 19200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

avrdude done.  Thank you.
#18

Try halving the baud rate in boards.txt and restarting the IDE.

#19

It has the same result.

#20

thank you for the forum, I thought there was some thing wrong with my board having had the same problems, but having checking the serial port I identified the problem