Arduino hangs before any instruction executed.

Hi,

I'm encountering a weird problem, and I can't tell for sure what's the cause. I desperately need help here.

I have a sketch which contains data tables; for some values in those tables, the sketch (consistently) hangs before a single instruction is executed.

I could not understand what combination exactly causes the hang up, but I compared .hex files for different values and didn't find much differences, nor distinguishing similarities.

:10266C000[b]1[/b]0003000000030001000500000004004[b]D[/b] -- hangs :10266C000[b]0[/b]0003000000030001000500000004004[b]E[/b] -- does not hang

:1026CC0003000[b]3[/b]00030000000300030005000000E[b]A[/b] -- hangs :1026CC0003000[b]2[/b]00030000000300030005000000E[b]B[/b] -- does not hang

:10278A000100000000000000000[b][b]0[/b][/b]0003001100032[b]7[/b] -- hangs :10278A000100000000000000000[b]1[/b]0003001100032[b]6[/b] -- does not hang

:102776000100000000000000000[b]1[/b]000300FEFF034[b]E[/b] -- hangs :102776000100000000000000000[b]0[/b]000300FEFF034[b]F[/b] -- does not hang

This is generated from records like:

static const Records[] = {
...
{  Initialize, GoOff, ThisMachine, Off}
...

The following would compile and work:

static const Records[] = {
...
{  Initialize+1, GoOff, ThisMachine, Off}
...

I don't see any common grouping things for hanging and non-hanging codes.

  • This does not appear as an offending opcode (though it's stored in variable memory)
  • Upgrading avrdude to the latest 6th version did not help
  • Programming via ISP the same code results in the same behavior
  • Changing orders of the array records usually helps but it's not a solution to me, since records are sorted
  • This is not an SRAM memory issue, since when this does work I still have about 3K free (it's Mega).

Please, help! It most looks like the resulting sequence somehow interferes with the programming process.

Thanks a lot!

Hi, welcome to the forum.

The Arduino Mega 2560 did have some issues in the past when uploading code.

You are able to use a programmer and ICSP header ? That's cool. Get the newest Arduino IDE 1.0.6 or 1.5.8 BETA, and burn the bootloader from within the Arduino IDE with a programmer. After that, try again to upload the sketch (in the normal way, via the usb-serial).

In the past these two things would help, but it should make no difference with a new bootloader and new Arduino IDE. I still mention them though: 1 ) When you have used the 'F()' for text, try to remove a few or add a few. That changes the data size for ram and flash, and sometimes it helps. You already noted that moving data around helps, so perhaps you have an old Arduino IDE version or an old bootloader. 2 ) It might also help to create a large amount dummy PROGMEM data in flash. Try to get the code size beyond the next boundery of 16kbyte or 32kbyte.

If that doesn't help, you have encountered a very rare and strange bug. Can you make a test sketch for it ? Give all the information with that test sketch: operating system, Arduino version, Mega 2560 board version, bootloader version and so on.

Could your data have any instance where there are (the equivalent of) three ascii ! characters in a row? If so the older mega bootloader hangs on that when uploading to the target. This bug usually shows up when a user inserts !!! in a comment, but any data being uploaded that contains the same data stream value will trigger this bootloader monitor feature/bug. The IDE distribution includes a newer 2560 mega bootloader file that fixes this 'feature' so updating/burning the bootloader could be the fix?

Hi!

It's first time I'm asking help here but I'm very pleased with the community around Arduino. Thank you so much!

Peter_n I was using Arduino 1.0.4 with toolchain update to GCC 4.7.2 and latest avrdude (actually, I tried both 5x and 6x branches).

I used several bootloaders with the same symptoms. I cannot use standard bootloader because it is not compatible with the hardware watchdog. Will try different options here again and let you know.

I tried to pad with PROGMEM variables (and generally liked this direction as it seemed a way to go) without any success by now. Seems like dark magic.

Currently, I cannot post the code, it's a part of a large project and I didn't manage to make a self-contained small reproducible sketch. Furthermore, the table itself is generated, hence if I fail to understand how to solve the problem, I cannot use whole toolchain.

retrolefty I'm aware of this bug though didn't check it before you mentioned. No, this is also not the case...

I tried 2 different bootloaders (adapted to work with watch-dog), on 2 different boards (to eliminate an improbable possibility of dead board), meanwhile, without any success.

Solved!

Fortunately, it is not related to code or so. The problem was that a constructor of a global variable was reading the table and did some action that indirectly accessed Serial via a logger. As I once had such a problem, and thanks to seeing the link here on forum that made me recall it and understand the potential problem. Then some virtual debugging in my head finally revealed the issue!

Thank you so much, I was nearly desperate.