Does it possible to call/ jump into boot loader from main loop ( for remote access)?

[GoogleCodeExporter]

What steps will reproduce the problem?
1.-
2.
3.

What is the expected output? What do you see instead?
-

What version of the product are you using? On what operating system?
AVRdude / Custom Made board / Win7

Please provide any additional information below.
  For develop remote flash by serial link application.I try to jump from main loop to boot loader.Please comment.

Original issue reported on code.google.com by tsupa...@gmail.com on 20 Jan 2012 at 2:33

[GoogleCodeExporter]

Hmm.  Difficult.  The bootloader checks the reset-reason flags, and only 
continues if it was "hardware reset."  (the preferred method for an application 
to cause a reset is to turn on the watchdog and loop till that resets the chip, 
but this would invoke the "fast boot" feature of optiboot and immediately start 
the sketch instead.)

Original comment by wes...@gmail.com on 24 Jan 2012 at 6:25

• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

Possible feature for 1K bootloader?

Original comment by wes...@gmail.com on 4 Apr 2012 at 2:16

• Added labels: Type-Enhancement
• Removed labels: Type-Other

[GoogleCodeExporter]

I also am looking for a way for the sketch to invoke the bootloader when it 
gets a command that says: "Hey! I want to update the firmware." I was looking 
at modifying the code to check (and reset) a flag in eeprom that says if it 
should fast boot or not when it gets a watchdog reset. That way my sketch could 
set the eeprom flag then force a watchdog reset and optiboot could then fall 
through to the bootloader on that reset, but since it uses reset itself, would 
act "normally" on subsequent resets.

I was able (after prodding the Makefile some) to get references to 
eeprom_read_byte() and eeprom_write_byte() to resolve and link OK, but I'm 
wondering if they will really work correctly right after a reset? (I guess I'll 
find out if I try and use the loader I built :-).

Original comment by horsley1...@gmail.com on 12 Apr 2012 at 4:39

[GoogleCodeExporter]

I think all you have to do is reset the stack pointer, clear r1, and jump to 
just after the fast boot check.  You may need to clear some other registers, or 
return some hardware to it's reset state.  I haven't tried this as I have been 
trying to log data to flash, not replace my whole program.  To that end I have 
factored out a page erase function and a page write function.  These can be 
called using a function pointer.  Attached is the page erase/write function 
patch, and a arduino test sketch for the atmega328p.  Depending on the exact 
compile the function off sets will need changing.

Original comment by eric.pet...@gmail.com on 18 Aug 2012 at 4:55

Attachments:

• UserFlashWrite.diff
• self_programing.ino