> This time around I compiled all the programs myself. I then modified the
> robositx i2c-io program so that it flashed the blue LED as a heartbeat
> instead of the red one.
> This made it quite evident what the problem was:
> When I just finished uploading the i2c-io onto the robostix for the first
> time, the blue led flashed a heartbeat which meant i2c-io was running on the
> robostix. Now in my earlier attempts as well, the first time when I had just
> finished the upload,the red lights would flash a heartbeat. But whenever I
> tried any command, the bizarre flashing would ensue.
> But now since the i2c-io used a different LED, it became clear what the
> problem was - any time I type either the i2c-load Run command or the
> robostix reset pulse command, the robostix was just being rebooted
> continuously, i.e, i can clearly see that the red LED flashes as it would
> while rebooting for exactly 5 secs, there is a pass, and then it is repeated
> again and again. But if I use the i2c-load info command (both with or
> without the --reset option), it gives me the proper info and I can see from
> the flashing of the red LED that the continuous rebooting has stopped and
> instead the bootloader is running.
> Finally, when I give the poweroff command and turn of the gumstix, one
> rebooting cycle later, the i2c-io blue heartbeat shows up and remains
> beating steadily. Please advice.
So it sounds like there might be an issue with the run command then. I
don't normally use the run command, so it's possible that there is a
weird problem that's crept in.
Actually, because you're seeing the same behaviour with the robostix
reset command, it sounds more like it's an uninitialized variable.
Which version of the avr compiler were you using?
And were you using WinAvr or a linux version?
Can you email me your i2c-Bootloader (.hex file) and your i2c-io (.hex file)?
> > fuse_h = 0xc9 disables the bootloader reset vector
> > fuse_h = 0xc2 enables the bootloader and sets the bootloader size to 4k
> > bytes.
> This is what is confusing me- if you look inside 'pgm-fuse-standalone' the
> value for the high fuse is:
> whereas; as you mentioned; in the wiki page it is specified as 0x09 for
Oh, ok the difference between 0xc1 and 0xc9 is 0x08. This bit
corresponds to the EESAVE bit. If the EESAVE bit is zero, then the
contents of EEPROM is preserved when performing a chip erase (i.e.
programming with uisp) . If EESAVE is 1, then the EEPROM will be
erased when you erase the chip.
Either setting works, although is EESAVE is 1, then everything goes
back to defaults when you download the i2c-Bootloader. So it really
just depends on what behaviour you want.
Vancouver, BC, Canada