1
\$\begingroup\$

I'm working on an implementation of AVR109, where the bootloader times out after two seconds if a given series of bytes aren't received on the serial port, and then starts the main application using a function pointer to address 0.

The bootloader is working fine, and I'm able to program the AVR via serial port. But when the AVR only contains the bootloader, and the flash memory at location 0 is empty, it takes two seconds in addition to the bootloader timeout every time the AVR restarts. Why isn't this instantaneous? Why isn't the AVR resetting immediately when the bootloader sets the pointer to an empty area in the flash? Is this something I can configure?

EDIT: My bootloader conundrum actually proved to be caused by PEBCAK. An error in the initial timing loop in the bootloader caused the extra two second delay, and was fixed. When jumping to the start of a blank/erased flash memory, it actually only took a few milliseconds before the bootloader started up again, i.e. not a big problem. But the best approach is to check the flash memory location before jumping there. If it's erased, just restart the bootloader instead of jumping to the empty area.

Improve this question
\$\endgroup\$
13
  • \$\begingroup\$ There is no such thing as "empty". There is some data that will be executed. \$\endgroup\$ – PlasmaHH Jan 24 '17 at 15:12
  • \$\begingroup\$ Didn't you just said it is using these 2 seconds to allow you to program it? \$\endgroup\$ – Eugene Sh. Jan 24 '17 at 15:13
  • \$\begingroup\$ @EugeneSh. "it takes two seconds in addition to the bootloader timeout every time the AVR restarts." In other words it takes four seconds when the bootloader timeout is set to two seconds. So when the pointer is set to address 0, which I assume is all 0xFF after the flash is erased prior to programming the bootloader, it resets after exactly two seconds. And then takes an additional two seconds to time out again. And so it goes in a four second cycle. \$\endgroup\$ – Oystein Jan 24 '17 at 15:15
  • \$\begingroup\$ @PlasmaHH Even when the flash is erased prior to the bootloader being programmed? Isn't the flash set to 0xFF then? What happens when the AVR tries to execute 0xFF? \$\endgroup\$ – Oystein Jan 24 '17 at 15:20
  • 1
    \$\begingroup\$ @Oystein: Unless by "erase" you mean "rip off with a pair of pliers", it contains some data. 0xFF is data too. \$\endgroup\$ – PlasmaHH Jan 24 '17 at 15:21
3
\$\begingroup\$

Well, the answer its to the behavior of the system is "who knows" because you basically have an undefined behavior because there is nothing written to flash to the MCU will try to use whatever is at address 0 as the reset vector for the application, if is erased it will try to use 0xffff and I do not think that the AVR issues an exception when you go outside the memory bounds and it will execute some random instruction and probably hang in there until the watchdog or other invalid instruction causes a reset. Most boot loaders tend to do a check for the value at the reset vector (typically address 0) to verify it is not blank and if it is they just loop the boot loader indefinitely to prevent the MCU to run into undefined behavior.

Improve this answer
\$\endgroup\$
2
  • 2
    \$\begingroup\$ +1. Indeed, AVRs will just execute instructions no matter what. \$\endgroup\$ – Tom Carpenter Jan 24 '17 at 19:09
  • \$\begingroup\$ +1 @TomCarpenter Thanks for information about AVR just running through memory locations until it hits a valid instruction. And for information on "proper" bootloader behavior (that it should check memory at location 0 before jumping there). \$\endgroup\$ – Oystein Jan 25 '17 at 7:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.