BOOTRST fuse was disabled, but bootloader code is EXECUTED

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am experimenting with ATMEGA328P bootloader and I created HEX file with program with infinite loop on the begining and with optiboot code at end of hex file. (code loaded into chip is here: http://relliks.php5.cz/stackexchange/DUMP.bin) Then I disabled BOOTRST fuse and press restart button on arduino uno r3 but the bootloader still blinks with LED on digital port 13.

How is it possible, that bootloader is executed after chip reset and BOOTRST is disabled? My fuse settings is: only SPIEN and BODLEVEL0 is set.

I found that when I disable BODLEVEL0 fuse, the bootloader turns off. BODLEVEL0 is used to set brown-out voltage and shouldn't affect bootloader start, where is the issue?

THX

SulisH@cker

Attachment(s): 

This topic has a solution.
Last Edited: Sun. Jan 8, 2017 - 03:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your App starts at 0.   The Bootloader starts at 32256.

 

If BOOTRST fuse is present,  the AVR goes to 32256 at Reset.   The Bootloader looks to see if anything is happening.

And restarts at 0.

 

If BOOTRST is not present,  the AVR just starts at 0.   i.e. your App still runs.   Only a bit sooner than if it started via the Bootloader.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree with your description of the standard behavior, but when I disable BOOTRST fuse, the bootloader still works and I am still able upload sketch from arduino IDE. Any reason how it is possible? Bootloader starting regardless BOOTRST fuse setting.

I tested the behavior on two arduinos but still the same results. Any idea where can be problem?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If your App is "erased".   The AVR starts at 0 and steps through all the 0xFFFF "opcodes" until it gets to the Bootloader.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, i supposed it. Attached file (dump.bin) have basically this code:

.nolist
.include "./m328Pdef.inc"
.list
   rjmp    Start        ; first line executed
Start:    
  nop 
  nop 
  nop 
  rjmp Start //infinite loop
  rjmp Start //and this instruction should be never executed (and every next 0xFF opcodes leading to bootloader start section)

If the first code execution starts on 0x0000, then the bootloader could not be never executed.
But if I upload above attached code, and simultaneously disable BOOTRST, the bootloader still starts for an unknown reason.

Can be there another way (unknown for me) which causes bootloader code execution? 

Last Edited: Sun. Jan 8, 2017 - 02:56 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jirisalek wrote:
... Then I disabled BOOTRST fuse

 

After disabling BOOTRST fuse, read back the fuses and copy the flash to a file.

 

See if BOOTRST is really UNPROGRAMMED and if the application program is still in flash.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you all very much!

 

I found that when I set fuses using program PONYPROG2000 and native RS232 programmer (http://3.bp.blogspot.com/-2D_0B7...) then I read fuses again using another program (eXtreme Burner) and another programmer(USBASP 2.0), there was difference. The PONYPROG2000 probably sets the fuses incorrectly.
Now the arduino works how david.prentice described and although i dont have clear flash chip, the code is executed only from 0x0000 and the bootloader is now dead code only.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jirisalek wrote:

Thank you all very much!

 

I found that when I set fuses using program PONYPROG2000 and native RS232 programmer (http://3.bp.blogspot.com/-2D_0B7...) then I read fuses again using another program (eXtreme Burner) and another programmer(USBASP 2.0), there was difference. The PONYPROG2000 probably sets the fuses incorrectly.

It really was a problem with PonyProg2000. I've encountered similar problem yesterday but what I noticed was BOOTxxx and BODLEVEL bits were swapped for ATmega328 in the Configuration and Security bits panel. I posted a note at PonyProg's forum and a few hours later Sonix fixed the problem and already released 2.08d update.

Chupo_cro