bootloader callable from sketch?

I don't suppose the standard bootloader can be directly entered from code in a sketch without resetting can it? Some magic address I could jump to perhaps? I'd like to (eventually) be able to update the sketch via bluetooth simply by sending a special command to the sketch, then invoking avrdude to do the actual upload. The timing is such on my Uno R3 with a bluetooth shield that by the time the bluetooth is talking again after a reset, the bootloader has already jumped back to my sketch, so there is never a timing window where it is possible to do an upload.

Sort of.

You can do this

void software_Reset() // Restarts program from beginning but does not reset the peripherals and registers
{
asm volatile ("  jmp 0");  
}

but you'll have to manually take care of resetting your hardware.

Google "arduino software reset" for more details than you probably want to know.....

Good luck!

Except the bootloader is NOT at location 0. It's off at 0x7e00 (chip dependent), and it has built-in assumptions that will not be true if it is called from a sketch (all interrupts off, all IO devices in their reset configuration, etc...)

The preferred way to cause a reset from software is to turn on the watchdog timer and let THAT reset the chip, except that this will normally skip the bootloader when optiboot is used, because it is part of the sequence used to start the sketch...

My mistake -- I misread the post. Apologies.

Chris

It would probably be easier to create a custom bootloader with a longer timeout. Up to 8s is an easy change.

Nah, that's what I'm doing now. Apparently doing the jmp 0 enters code that screws around with enough of the registers somehow that the bluetooth gets disconnected temporarily and that temporary is long enough to prevent the upload from working. In fact, I played around with binary searching the time delay and right at 73346 microseconds the error I get switches from ioctl errors on /dev/rfcomm0 to arduino not responding to avrdude :-). I need some way to jump to the bootloader code and have it use the existing rfcomm connection to do the upload. Either that, or a custom bootloader with a longer delay.

westfw:
Except the bootloader is NOT at location 0. It's off at 0x7e00 (chip dependent), and it has built-in assumptions that will not be true if it is called from a sketch (all interrupts off, all IO devices in their reset configuration, etc...)

Interrupts are easily disabled with asm("cli");
The pins can easily all be reset to inputs as well.
Still, the effect is probably not what you desire.

Any reason to use the asm call rather than plain cli() or noInterrupts()?

Which bluetooth shield & module are you using? I'm wondering why the bluetooth connection is being interrupted after a reset. I'm not so familiar with Arduino + BT, but I'm doing remote sketch uploads via an Xbee link without any trouble. The XBee radio modules transmit the reset signal to the Arduino, but are not reset themselves so there is no disruption to the communication link.

SirNickity:
Any reason to use the asm call rather than plain cli() or noInterrupts()?

No. But I am more familiar with using it in asm tags.

tim7:
Which bluetooth shield & module are you using?

It is an ITead studio bluetooth shield v2.2. I also wonder a bit why the jmp 0 seems to reset it, but it sure seems to, the /dev/rfcomm0 device gets nothing but ioctl errors right after the reset. Anyway, I'm resigned to just using USB during development. Its not that big a deal, just a bit irritating. If I get irritated enough maybe I'll build a parallel programmer and see if I can up the delay time in the bootloader.

Claghorn:
I also wonder a bit why the jmp 0 seems to reset it, but it sure seems to, the /dev/rfcomm0 device gets nothing but ioctl errors right after the reset.

That's odd. The schematics seem to show the BT-module's reset clearly separated from the Arduino's reset circuitry. Could it be trying to auto-baud? Do you change bit-rates at any time?

As for running the bootloader... since you're using an Uno the bootloader will only try to upload a new sketch after an external reset (any other type of reset will cause it to restart the sketch immediately). That means pulling the ATmega328's reset pin down to ground -- you can't do it in software. I'd suggest using one of the Arduino's digital output to do this, though I haven't tried it myself.

The BT module is probbly reset as part of the startup() function in your code.

I'd suggest using one of the Arduino's digital output to do this, though I haven't tried it myself.

I have heard mixed opinions on this because the pin will go high impedance during reset which may lead to an incomplete reset. It will probably work though.

smeezekitty:

I'd suggest using one of the Arduino's digital output to do this, though I haven't tried it myself.

I have heard mixed opinions on this because the pin will go high impedance during reset which may lead to an incomplete reset. It will probably work though.

That is correct. The AVR datasheet cautions against trying to use that method.

Lefty

retrolefty:
That is correct. The AVR datasheet cautions against trying to use that method.

I must admit I thought the reset circuitry prevented the possibility of an imperfect reset.
Could you point me to the relevant part of the datasheet?

All this would not be necessary if you ran your code under bitlash
http://bitlash.net/wiki/start
With this system you can run code directly off an SD card.

I must admit I thought the reset circuitry prevented the possibility of an imperfect reset.

This is because before the reset has time to complete it is removed because the output pin driving it is tristated. This is common for all micro controller chips I have ever seen.

Grumpy_Mike:
This is because before the reset has time to complete it is removed because the output pin driving it is tristated. This is common for all micro controller chips I have ever seen.

That much is inevitable. But internally the reset is surely held for some minimum time. Otherwise an indecisively pushed reset-button would cause chaos.

P.47 of the data sheet seems to show that the reset sources set a latch. Any signal long enough to get through the spike-filter will cause a complete reset; whilst shorter signals will do nothing at all. I can't see any circumstance in which an incomplete reset is possible.

But internally the reset is surely held for some minimum time.

No

Otherwise an indecisively pushed reset-button would cause chaos.

It would if you get a reset that is not held down long enough yes. I have worked on a few systems where this is true.

I can't see any circumstance in which an incomplete reset is possible.

Trying to reset a processor with the output of it's own pin is one. No engineer would ever do it.
I have been in this business over 40 years you know.

Grumpy_Mike:

But internally the reset is surely held for some minimum time.

No
I have been in this business over 40 years you know.

I bow to your superior age, but do you think you could expand a bit on "no"? I've copied the relevant diagrams below.