Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

GoogleCodeExporter opened this issue Mar 14, 2015 · 5 comments


Copy link

@GoogleCodeExporter GoogleCodeExporter commented Mar 14, 2015

What steps will reproduce the problem?

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 by on 20 Jan 2012 at 2:33

Copy link

@GoogleCodeExporter GoogleCodeExporter commented Mar 14, 2015

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 on 24 Jan 2012 at 6:25

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

@GoogleCodeExporter GoogleCodeExporter commented Mar 14, 2015

Possible feature for 1K bootloader?

Original comment by on 4 Apr 2012 at 2:16

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

@GoogleCodeExporter GoogleCodeExporter commented Mar 14, 2015

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 on 12 Apr 2012 at 4:39

Copy link

@GoogleCodeExporter GoogleCodeExporter commented Mar 14, 2015

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 on 18 Aug 2012 at 4:55


Copy link

@WestfW WestfW commented Jul 27, 2018

Should be possible in v7.
See examples/test_reset.ino

@WestfW WestfW closed this Jul 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants
You can’t perform that action at this time.