Is there any difference between power-on, watchdog, and external resets?

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

I have a very strange problem where some code which triggers a watchdog reset and then jumps to the boot loader only works if an external reset has not happened since the last power-on reset. HWB is tied to GND.

Last Edited: Mon. Feb 27, 2017 - 06:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Memory contents can be retained when the power remains ...

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

I know that, but for some reason the external resets keep working while my code fails.

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

the fact that data persists can cause trouble when you have uninitialised vatiables

 

can also show-up other bugs in your could which just happen to "work" by "luck" after a power cycle, but not other resets...

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

The MCU status register keeps a record of what resets have happened.  Maybe the bootloader checks this.

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

It does check MCUSR, but my code clears it during startup.

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

Are you sure you clear the bits?  According to the manual they are cleared by writing zero bits.  I believe that's backwards from the Xmega.

 

A debugger would tell you where the bootloader is going wrong.  I don't know just how to go about debugging the bootloader. 

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

Yes, here's what I do.

MCUSR = 0;
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I now have a new but very similar problem, where my application will only run after a power-on reset. It will not run if the boot loader calls it. Does anyone have any ideas?

Last Edited: Mon. Feb 27, 2017 - 02:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not enough info to go on.

 

Also do you have any diagnostic aids like a debugger?

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

and I have a baffling problem that is the opposite of that. Here is my problem that I would appreciate any clues about fixing:

 

I am using ATMEGA1284 and JTAG ICE MKII.  I am getting on pretty fine programming two different projects in ATMEL assembler.

 

The first project board talks to a PC via the AVR UART, controls relays, flashes LEDs, drives steppermotors and measures voltages and currents all very nicely and "at the same time" using an RTOS.

It works under the JTAG ICE MKII debugger, and also without the debugger, doing power-up reset all on its own fine.

 

The second project uses an almost identical circuit and almost identical software, and same Xtal.

The difference is, it uses the SPI port to drive things instead of bit bashing.

This project also works fine when I download code with JTAG ICE MKII and set it running.

It continues to run fine after I unplug the JTAG dongle without first removing power form the board.

But if I then remove power from the board, it will not power-up restart on its own.

 

So here is what I have suspected and tried:

 

(1) Changed the processor. All chips do the same

(2) Tried checking "Use Exrernal Reset" and also not checking it. No difference.

(3) Tried all settings of Brown Out Detector fuses. No difference

(4) Tried different settings of Xtal fuses. No difference

(5) Tried changing external reset delay (which is provided by a TI TPL9201 chip) between 0 and 8mS. No difference.

(6) Questioned whether the SPIEN fuses chould be checked or unchecked. Since I was using the SPI port to control hardware,

     I thought it should be checked. However, the SPI port works fine without this fuse being checked, as I am setting port bit usage in start-up code.

      So I am now thinking that the SPIEN fuse is only for when you want to do debugging via the SPI port instead of JTAG. Can't see any documentation to that effect.

      I read somewhere that if the SPI port clock in particular is toggled while holding RESET low, that can cause corruption. I guess that is only if SPIEN fuse is checked?

      Anyway, that is not happening.

(7) Suspect that IVSEL is not getting reset back to 0 to put the interrupt vectors back to the start instead of into the boot zone.

     So, I am trying to monitor MCUCR that contains the IVSEL and IVE bits while single stepping at start-up.

     It is not clear where I should be looking at this register: Is it address 35 or 55 in data mapped I/O?  So I give both values:

      data mapped I/O address hex35 containes 0 at start up under JTAG. Data mapped I/O address hex 55 contains  17

 

      Now I single step through the power-up initialization routine, setting port pin data directions etc, until I get to a piece of code that will set IRAM

      addresses $0100  to $0110 to $FF in the following loop:

 

                   SER R16                        ; SET R16 TO $FF
                   LDI R17,  NUMBER_OF_PROCESSES         ; = 16 DECIMAL
QLOOP1:    ST Z+,R16
                   DEC R17
                   BRNE QLOOP1

 

Z = (R31,R30) is  set to $0100  upon entry   and R17  to $10

 

I step though this to BRNE QLOOP1 and upon executing that it returns to QLOOP 1 as it should first time round,

BUT, I notice data mapped I/O register has changed to $01 simulatneously with executing BRNE

 That means IVE is now set to 1 !!  Who did that ? Some little hardware wrinkle that only works when the JTAGEN fuse is set?

Why did it pick then to do it?  (These things need to be documented please!)

 

Now I do 4 more steps and data mapped I/O register 35 becomes 07. That means IVE and IVSEL are now 1.

That seems to be executing the protocol that you have to set one first then set the other within 4 cycles to switch the

interrupt vectors to the boot zone.

 

That is as much as I know, but one of things that some expert may be able to tell me is what is the AVR sensing that made it

do that then, that it would not be sensing if I was doing power-up reset without JTAG plugged in?

 

Are the JTAG pins expected to be at any particular potential (via pull downs or pull ups) when JTAG is not plugged in to prevent

switching the interrupt vectors to the boot zone?

 

Thanks,

Paul Dent

 

 

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

PaulWDent wrote:
BUT, I notice data mapped I/O register has changed to $01 simulatneously with executing BRNE That means IVE is now set to 1 !!

You lost me.  Do you mean IVCE instead of IVE?

 

And "interesting" how your your loop apparently affects 0x55.  And how did you find that anyway?  The bit turned color when stepping?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

PaulWDent

 

Forget about fiddling with the spi for the moment & all the confusion factors between SPI/Jtag...does your chip even come out of reset & the boot area and run normal code?  Set  the DDRx for a port pin & then toggle the pin it endlessly (your short program will do NOTHING else)....does at least that power up & run?  Is it twiddling at the expected freq (so you know the correct clock setting is also as expected).  If it makes it to this code & runs properly, then a lot of options must be set properly & functioning. Once you know that is working, you can investigate your spi issue & whether you can actually send data over it.

When in the dark remember-the future looks brighter than ever.

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

PaulWDent wrote:

 

(7) Suspect that IVSEL is not getting reset back to 0 to put the interrupt vectors back to the start instead of into the boot zone.

 

 

If you have a bootloader relocating interrupts to the boot section then you need to make sure your main program code changes your vectors back to the main program.

But you really should have the bootloader RESET to your main program via a watchdog reset by doing checks for the reset cause.

This will make sure all registers are cleared to a know state before you continue with the main program set-up.

 

 

 

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

ront1234 wrote:
But you really should have the bootloader RESET to your main program via a watchdog reset
+1

 

In fact why is the bootloader even using interrupts anyway? You make the code hugely less complicated (and hence easier to test and debug) if you stick to polling actions in the botloader. Given that it's a piece of software that probably only runs about once avery 3 to 6 months for 1..2 minutes it's not worth the effort to do a load of "fancy stuff" that would require the use of interrupts.

 

At the end of the day the only piece of software in the system that MUST work is the bootloader (as it's the only bit you cannot replace) so the essence of it is to keep it as simple as possible (and hence bug free).

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

e_l_tang wrote:

I now have a new but very similar problem, where my application will only run after a power-on reset. It will not run if the boot loader calls it. Does anyone have any ideas?

I have lots of ideas, most of them bad.  wink

 

I guess what you mean is the application won't run if it has just been put into flash by the bootloader.  I've had that problem myself but I don't remember the solution.  I've also had the opposite problem where the application would run only if it was just flashed. 

 

If the bootloader uses interrupts, it should disable the individual interrupts and the interrupt priority levels and the global interrupt.  Not doing so can obviously cause problems.

 

It may use different clocks than the application is using, but no problems that might cause come to mind. It also uses various devices and sets them up differently than the application does. 

 

Your application may start running and get hung up is initialization.  Having a JTAG debugger or whatever debugger could come in handy.  Some debuggerless folks put in code that turns on a LED.  And then moving the turnon code further into the initialization until the led no longer gets turned on.

 

 

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

ront1234 wrote:

If you have a bootloader relocating interrupts to the boot section then you need to make sure your main program code changes your vectors back to the main program.

It seems to me, putting the vectors back should be done by the bootloader.

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

ront1234 wrote:

But you really should have the bootloader RESET to your main program via a watchdog reset by doing checks for the reset cause.

Yes, maybe, but I'd want to know if I got watchdog resets because my software or hardware was bad.  This muddies the waters.

 

What would be nice is to have software resets for this.  Xmegas have one.  I want two.  One for my "deluxe" application wink so I can get to the bootloader from the application without having to hold down two buttons on the board.  The other software reset would be used by the bootloader to get to the application.

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

steve17 wrote:
I'd want to know if I got watchdog resets because my software or hardware was bad.  This muddies the waters.

So you set a flag in RAM when you do a deliberate reset, and check that - along with the Reset Cause - when the code restarts.

 

Thus you can distinguish a "fault" watchdog reset from a "deliberate" watchdog reset...

 

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

awneil wrote:

So you set a flag in RAM when you do a deliberate reset, and check that - along with the Reset Cause - when the code restarts.

Wouldn't the bootloader and the application have to use the same RAM location?  How would you do that?   It might be easier to use EEPROM.

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

steve17 wrote:
Wouldn't the bootloader and the application have to use the same RAM location?

Yes.

 

It might be easier to use EEPROM.

Indeed - but bootloader and application would still have to "agree" on what location within the EEPROM to use ...

 

 

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

steve17 wrote:

ront1234 wrote:

If you have a bootloader relocating interrupts to the boot section then you need to make sure your main program code changes your vectors back to the main program.

It seems to me, putting the vectors back should be done by the bootloader.

 

I don't use interrupts in the bootloader but if I did (and didn't use a wd reset) I might think about the best place to restore the vectors. Bootloader section does make sense but locating the vector change in the program might be a good reminder that you that you're using interrupts in the bootloader.

 

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

Theoretically, you can tell whether a watchdog reset has happened from the bootloader (which you can assume is "bug free", right?) or the application.  A couple people have posted possible solutions to this for Optiboot.

In practice, I think it ends up being a bit more complicated (and I haven't yet "accepted" any of the Optiboot proposals.)  It's similar to the "double-reset" boot procedure that a couple of SAMD boards have implemented (one reset - start the bootloader with it's normal (short) timeout.  An additional reset during that short timeout - lengthen/eliminate the timeout.)

 

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

steve17 wrote:

ront1234 wrote:

But you really should have the bootloader RESET to your main program via a watchdog reset by doing checks for the reset cause.

Yes, maybe, but I'd want to know if I got watchdog resets because my software or hardware was bad.  This muddies the waters.

 

What would be nice is to have software resets for this.  Xmegas have one.  I want two.  One for my "deluxe" application wink so I can get to the bootloader from the application without having to hold down two buttons on the board.  The other software reset would be used by the bootloader to get to the application.

 

You can still use the watchdog normally in your program since the bootloader will always jump to the program on wd reset. That's not really a problem is it? What would you have the bootloader do if it did hit a wd timeout? If the bootloader did hang (and it shouldn't since it should be rock solid code) then you could just do another bl reset manually.

 

Yes, the xmega sw reset is a nice feature, xmega's do have some excellent features.

I don't typically use any buttons to start a bl, I like to use a 2 second time-out at boot-up and hit an ESCAPE key via uart to enter the bl.

 

 

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

ront1234 wrote:

You can still use the watchdog normally in your program since the bootloader will always jump to the program on wd reset. That's not really a problem is it?

awneil and I covered this.  We might want to occasionally check to see if there have been any watchdog resets caused by problems with the system.  Therefore we need to be able to distinguish between these and those caused by the normal operation of the bootloader.

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

Maybe I'm missing something that you want to do. If the boot reset fuse is set to bootloader then the bootloader will always handle any and all resets first. If trapped a wd reset can be detected in the bootloader and it will always jump to the program. This works completely normal for using the watchdog in the program. Of course using this reset method will depend on the bootloader programming the flash and then using a wd reset to go to the program.

 

However, if you want to make use of the watchdog in the bootloader also then you can let the wd reset go ahead and jump to the program or re-direct it back to the bootloader which would be a little more complex.

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

Since I was making no progress fathoming why my app would not start from power up but only via JTAG ICE, I had to go away and do something else. Now I am back on it and here is my problem:

 

I have two projects, one small andone big, that run either if started via JTAG ICE MKII or if started from power up with no ICE.

 

Then I have two others which are very similar, that start and run fine via ICE but will not run from power up on their own.

Even if I started them with ICE and then unplugged ICE while they were running, they would continue to run fine.

 

I realized a difference was that the latter two use the SPI port to drive serial peripherals while the first two don't.

They do  drive the peripherals beautifully when started up via ICE.

 

So I commented out all calls to use the SPI port and LO! they now start up and run from power-up fine

 

So I think I am on the track of something.

 

Do I understand this correctly:  When you are debugging via ICE, it sets the OCDEN fuse and then whenyou  stop debugging, it resets it.

But if I unplug ICE while it is running in debug, OCDEN is left enabled. In that situation, the program continues to run fine.

But I believe that when you power up standalone, wihtout ICE, OCDEN is disabled.

 

What could that have to do with the SPI port unctioning, I wonder?

 

Can anybody see what I might be missing?

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

unplugged ICE while they were running,

.

.

But if I unplug ICE while it is running in debug

DON'T DO THAT! That's a dangerous thing to do, your ICE might just "melt"!

So I commented out all calls to use the SPI

What peripherals? What does that code look like? Is the micro expecting some response from them?

At times peripherals wake up later that the micro and if you are expecting some response you need some power up delay before starting the comms.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Is it the old recurring problem of not setting the SS as an output in spi master mode? If not done the master will not function and the code polling it will continually loop.

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

Kartman wrote:
Is it the old recurring problem of not setting the SS as an output in spi master mode?

Possible.  My guess, which I'll opine is more likely, is that OP is "racing" an external SPI device at startup, and it ain't ready yet.  OP's "driver" code doesn't have any "fail" provisions.

 

[Character LCDs are not SPI, but they are quite slow to be ready at power-on, and may appear as OP's symptoms.  ]

 

 

OP has JTAG -- should be able to "break" the app and see where it is.

 

We don't know what "doesn't work" means.  Uninitialized local usually manifests itself in the other direction.  Anyway, check build results for "use before setting" and similar warnings.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Thanks for all the hints above. SS was definitely on my radar screen to check. I was setting it to "output" in the power-up initialization routine,

but I put in a couple of extra code steps to reset the whole of port B DDRB every time I call a SPI I/O routine.

 

This got me forward one step: It now starts up on standalone power-up

But it still never returns from the first call to the SPI port routine,.but a previously started  interrupt-driven waveform generator is still running fine.

 

I will now inch through the SPI port code to see where the hang-up occurs.

 

It's still a puzzle why this doesn't manifest itself when started via JTAG.

 

I have a question in to Microchip support about that.

 

 

 

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

I have found the answer to programs starting under JTAG ICE but not on standalone power up or vice versa

I carried out many small experiments to see if the ATMEGA had any unpublished quirks, and it passed all tests fine.

 

What I came to realize is that, if a  program has a fault in it  that corrupts the stack, the program can go off wandering in the weeds.

 

But the weeds are not the same under JTAG ICE,  that has a bootloader resident and OCDEN set, as compared with a standalone power-up reset.

 

So you can get different and unpredictable results in the two cases when you have a bug.

 

I had scattered multiple stackpointer reset opportunities throughout my code in the hope of buying some immunity to such faults, and

it so happened that the program was stumbling across one of those in the JTAG ICE weeds, masking the fault, but not in the power-up weeds.

 

So we just have to accept that a piece of software that is working under JTAG ICE does not guarantee it working under standalone power-up and vice-versa.

 

To all those who have experienced similar problems, I would suggest that the program is probably off "wandering in the weeds"