Optiboot reset flag

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

Good day All,

 I have been playing with the reason for watchdog reset stuff in optiboot, but having difficulty getting a meaningful answer out.
Using the latest version of optiboot, and the following code:

 

// NOTE: This code will work with a recent version of 'optiboot' as the bootloader:
uint8_t resetFlags __attribute__ ((section(".noinit")));
void resetFlagsInit(void) __attribute__ ((naked)) __attribute__ ((section (".init0")));
void resetFlagsInit(void)
{
  // save the reset flags passed from the bootloader
  __asm__ __volatile__ ("mov %0, r2\n" : "=r" (resetFlags) :);
}
...
...
int(main) {
    ...
    // TODO: This will show how many resets... after the R
    send_string_p(PSTR("Rx LiFePO4 Charge Controller for ESP-120 PSU's. V:0.2.0. Jasper Aorangi 2014. Have a nice day 8): "));
    send_uint16(resetFlags);
    send_string_p(PSTR(" x\r\n"));
    ...
    
}

The reset flag is always '8', even when starting afresh.

I need to disable all processes and flash lights, make noises etc if reset by watchdog...

 

Any ideas what I am doing wrong??

Cheers

Jasper.

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

Scarletpimpernal wrote:
I need to disable all processes and flash lights, make noises etc if reset by watchdog...
Have you looked at the OptiBoot source code?  The bootloader uses a watchdog reset to start the application code.  How do you plan to distinguish that watchdog reset from one caused by a timeout in your application?

 

You'll note that the bootloader starts the application immediately if the EXTRF bit is not set in the MCUSR register.  If the EXTRF is set it sets up the watchdog and then waits for commands, resetting via the watchdog if none timely arrive.  It may be useful for you to create a small test application to run an a device without a bootloader to see what reset flags are present under various conditions, e.g. brownout reset, power on reset, external reset, watchdog reset.  Armed with that knowledge you can then deduce what flags your app will see under various conditions under control of the bootloader.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

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

Thank you dkinzer,

 I did not grok the optiboot code.

 

Now that I have an USBAsp I guess I can go without a bootloader and get access to the watchdog reset flags. I suppose there must be some that are useful tho, toerhwise why impliment the feature (as you say, probably brown out)

 

Cheers.

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

Scarletpimpernal wrote:
I guess I can go without a bootloader and get access to the watchdog reset flags.

It is possible to use a bootloader *and* have fully useful reset flags.  Our ZBasic devices do.  The changes to the OptiBoot bootloader were proposed by me (first appeared in v4.6) and are implemented nearly identically to the ZBasic implementation.  The main difference is that the ZBasic bootloader doesn't use watchdog reset to exit the bootloader and begin execution of the user program.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

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

dkinzer wrote:

 

Scarletpimpernal wrote:

I guess I can go without a bootloader and get access to the watchdog reset flags.

 

 

It is possible to use a bootloader *and* have fully useful reset flags.  Our ZBasic devices do.  The changes to the OptiBoot bootloader were proposed by me (first appeared in v4.6) and are implemented nearly identically to the ZBasic implementation.  The main difference is that the ZBasic bootloader doesn't use watchdog reset to exit the bootloader and begin execution of the user program.

 

So if I am using the lates optiboot from git then I should already be using your changes? Or do we have to modify Optiboot to use another mechanism to eit bootloader?

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

I think the problem is that since optiboot USES "reset by watchdog" internally, any application will never see that as a reset reason (or perhaps see it MORE often than required - you can distinuguish between "restarted by an application watchdog timeout" and "restarted by the bootloader."

 

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

Scarletpimpernal wrote:
So if I am using the lates optiboot from git then I should already be using your changes?
Yes.  As I indicated, support for passing reset flags to the application has been in OptiBoot since v4.6.  Prior to that, the concept didn't exist in OptiBoot.  (A brief summary of the change history is present in the source code file optiboot.c.)

 

You might be able to come up with a clever way to distinguish between watchdog resets caused by the bootloader and ones caused by your application.  Alternatively, you can use a different bootloader that doesn't use watchdog reset (and, probably, modify it to pass reset flags to the app).  Or, don't use a bootloader at all.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net