next topic »

[on:]

Over in another area, this thread rapidly degenerated:

http://arduino.cc/forum/index.php/topic,97457.0.html

But I do think it would be useful to have a library routine that a sketch could invoke which would turn off interrupts, clear registers, etc. then jump to the bootloader where it will then wait for avrdude to get in touch and upload new microcode.

In my case, I want to be able to upload new microcode via bluetooth, and it appears as though by the time the bluetooth module is talking after a reset, the bootloader has already entered my sketch (at least that is my theory). A way to leave the serial connection operating, and upload new microcode over the existing connection would be handy.

[Reply #1 on:]

Over in another area, this thread rapidly degenerated:

http://arduino.cc/forum/index.php/topic,97457.0.html

But I do think it would be useful to have a library routine that a sketch could invoke which would turn off interrupts, clear registers, etc. then jump to the bootloader where it will then wait for avrdude to get in touch and upload new microcode.

That would require a rewrite of the bootloader. Present behavior is to wait for AVRDUDE but only for a short period and then if there is a sketch already in flash memory it will jump to that code. Only if the flash memory is erased (except for the bootloader of course) will the bootloader wait indefinitely for AVRDUDE.

In my case, I want to be able to upload new microcode via bluetooth, and it appears as though by the time the bluetooth module is talking after a reset, the bootloader has already entered my sketch (at least that is my theory). A way to leave the serial connection operating, and upload new microcode over the existing connection would be handy.

Again what you are asking for is not presently possible without modification of the bootloader code, regardless if you can properly 'jump' to the bootloader code from within a sketch. The 'sanctioned method' to do that is to enable the watchdog timer and let it time out which will create a reset and start the bootloader.

Lefty

[Reply #2 on:]

Again what you are asking for is not presently possible without modification of the bootloader code

Right. That's why I posed it in the suggestions for arduino forum :-).

[Reply #3 on:]

Again what you are asking for is not presently possible without modification of the bootloader code

Right. That's why I posed it in the suggestions for arduino forum :-).

But you suggested it as a library addition, not a modification of the standard bootloader. The bootloader is 'standalone' piece of software that is not modifiable directly from within the arduino IDE.

Lefty

[Reply #4 on:]

it appears as though by the time the bluetooth module is talking after a reset, the bootloader has already entered my sketch (at least that is my theory)

Wouldn't a longer bootloader timeout be a better solution?

[Reply #5 on:]

Oh, wait...

Either that, or a custom bootloader with a longer delay.

You already proposed that as a solution.  So what was the result?

[Reply #6 on:]

Wouldn't a longer bootloader timeout be a better solution?

I don't know about better. It might be a solution, but to do that I'd need a way to replace the bootloader (which I don't have at the moment). I'm more likely to try something really evil like replicating the code that waits for avrdude, then jumping into just the right spot in the existing bootloader (reverse engineering is more fun than building a parallel programmer :-).