How to do a reset in Assembler?

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

Hello, how to do a reset without having to press the button of the  Atmega 2560 microcontroller, using ASM? Is it possible?

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

You can trigger a WDT reset.  The WDT stays enabled after a WDT-triggered reset, so be sure to correctly disable it early in your init code.

See 'Detailed Description' here:

http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

jmp 0 or rjmp 0x0000 would do nicely, unless you've relocated your boot vectors (see the fuse settings).  Too obvious?  S.

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

Scroungre wrote:
jmp 0 or rjmp 0x0000 would do nicely

This is not good way to reset. It only restarts your code, not the microcontroller.

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

True, the MCU could be left in some indeterminate state, but since my code initializes everything important right after reset, what the rest of the CPU is doing is irrelevant.  It's what my code does after power-up, so it's roughly equivalent.  There are default values for everything, but I generally assume that no state on powerup can be trusted.  Set them all in code.

 

I saw somewhere in a datasheet once something about software yanking on the /RESET pin causing a software reset.  Sounds like a better alternative than wiring pins together (which you can do if you want to...)  I will have to go look that up.  S.

 

Edit:Unfortunately it looks like the OP's 2560 doesn't have any alternate port functions on the /RESET pin, so there is no easy software way to yank on it.  As far as I know.  S.

Last Edited: Wed. Oct 25, 2017 - 08:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
I saw somewhere in a datasheet once something about software yanking on the /RESET pin causing a software reset. Sounds like a better alternative than wiring pins together
But to do that a pin HAS to be connected to _RESET. Until you reach Xmegas then tiny/mega cannot invoke their own rest (except by WDT as already suggested).

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

Scroungre wrote:
True, the MCU could be left in some indeterminate state, but since my code initializes everything important right after reset, what the rest of the CPU is doing is irrelevant.  It's what my code does after power-up, so it's roughly equivalent.  There are default values for everything, but I generally assume that no state on powerup can be trusted.  Set them all in code.

I can't agree. Why somebody wants to reset the MCU? It's not something you do when everyting goes as expected. Maybe the code found out that the MCU is in unexpected state for any reason - because of software issue or electromagnetic noise for example. In such case you can't assume that all MCU registers you didn't touch are in their default states. Restarting your code and initializing only the registers you use is not the reliable way to reset the device.

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

Thought I saw it somewhere.  Must admit I can't find it now.  I did find one other way:  An ATmega32U4 can be reset by USB signalling, and I think you can force it to reset itself that way.  Not sure.  Not going to try.  S.

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

MarekJ71 wrote:

I can't agree. Why somebody wants to reset the MCU?

 

A good question.  Ask the OP.  S.

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

volterius wrote:
Hello, how to do a reset without having to press the button of the  Atmega 2560 microcontroller, using ASM?

Volterius, why do you want to reset the MCU?

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

One very common reason is to end a bootloader. The bootloader may have enabled various peripherals so to get the machine back to a "clean state" so the app just sees the AVR as if it just powered on the bootloader sets a flag to itself to say "I am doing this reset deliberately". It then invokes the watchdog and enters a non-resetting tight loop and waits. After the WDT period the AVR then resets and restarts with everything reset EXCEPT that MCUSR has the WDRF bit set. The bootloader looks for this condition in its early start up (and possibly the flag that says "this is deliberate") and when it sees this condition it jumps to the app code at 0x0000. Now the app starts in what looks like a power on AVR with no evidence that the bootloader has been running before it (apart, perhaps, from trace evidence in the RAM it was using for stack).

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

This is why: 

Scroungre wrote:
... but I generally assume that no state on powerup can be trusted. 

 

Is it considered rude to quote oneself?  S.

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

Scroungre wrote:
I generally assume that no state on powerup can be trusted.

Again, I can't agree. Initial state of the MCU on powerup or reset for any other reason is indicated in the datasheet. If it weren't known the MCU would be unusable. You wouldn't know what the MCU does until your code finishes initialization and you couldn't even be sure that your code will run at all.

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

It is a bit of a belts and braces approach, I freely admit. 

 

For example, I as practically cut-n-paste boilerplate always have my AVRs set all their pins to high-impedance inputs as about the first thing in every program.  Every single one.  Then I go back in, later on in the code, and turn on this and that output or peripheral as application requires.

 

It's not particularly efficient.  The code could be smaller and faster if I depended on default powerup conditions.  But it doesn't matter - initialization is trivial compared to the rest of the program.  The MCU works, and it does what I want it to do when I want it to.  Furthermore, since I write in assembler, I know exactly what the MCU is doing on each and every cycle of the clock, while initializing or not.

 

The ultimate test?  My code runs.  Every time*.

 

S.

 

* except when the bonehead driving the keyboard has done screwed up, that is...  wink  S.

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

So exactly which of the values documented in the datasheet as "reset value" don't you trust? For example do you trust it when it says that the initial value for PC will be 0x0000 (or the BOOTSZ address if BOOTRST active) ? If PC didn't start at 0x0000 at every power on then all kinds of problems would ensue!! So why do you trust THAT initial value more than the others in the datasheet. For example it tells you that all DDR registers will reset  to 0 (so inputs). Which bit of that do you not trust?

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

I trust the ones I can do nothing about, because I have no choice.  Those I can do something about, I set appropriately.  S.

 

Edit:  PS - Those my program can do something about are exactly the ones that some other program could have done something nasty to.  S.

Last Edited: Wed. Oct 25, 2017 - 09:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
For example, I as practically cut-n-paste boilerplate always have my AVRs set all their pins to high-impedance inputs as about the first thing in every program.  Every single one.  Then I go back in, later on in the code, and turn on this and that output or peripheral as application requires.   It's not particularly efficient.  The code could be smaller and faster if I depended on default powerup conditions.

This is what I also do, but not because the code wouldn't work without this. This is called "defensive programming" and makes code more reliable, but it wouldn't be needed if we assumed that nothing unexpected can happen.

 

Scroungre wrote:
Furthermore, since I write in assembler, I know exactly what the MCU is doing on each and every cycle of the clock, while initializing or not.

Unless there is an interrupt. Or PORT state that prevents hardware from working correctly or damages it.

 

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

MarekJ71 wrote:

Unless there is an interrupt. Or PORT state that prevents hardware from working correctly or damages it.

 

True, dat.  I fried half a dozen 32u4s before I found out that my "Five Volt" power supply was actually putting out more like six.  They'd work for half an hour, and then died, badly.  Scroungre's lab - Where AVRs go to die.  S.

 

PS - Mostly through sheer boredom, because writing assembly takes forever!  S.

 

Last Edited: Wed. Oct 25, 2017 - 10:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
I fried half a dozen 32u4s before I found out that my "Five Volt" power supply was actually putting out more like six.

Interesting in itself...

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

That was the annoying part.  They'd run for half an hour or so.  Smoking off those 32-pin packages got real old real fast (don't have a real SMT rework station).  Then I'd put on a new one, test it, it works, program it, it works, okaygreat, get back into coding up and testing a few more modules, and suddenly total silence, as the chip just dies.  No visible evidence, just won't run, won't reprogram, can't read signature anymore - dead.

 

Probably wasn't exactly six volts, either.  As you may have gathered from the previous post, the regulation on that supply was not what it should have been.  Even if I'd measured it at 6.0000V I wouldn't have used it, because riding that close to a max rating is not, generally, a good idea*.  At 5V(ish) they worked beautifully, and the problem went away.

 

S.

 

*Of course, I do run them at their max rated clock speeds (almost) all the time.  Consistencies, foolish, hobgoblins, &c.  S.

 

PS - It didn't help my state of mind that at the time I'd bought out Digikey's entire stock of 32u4s, and they were being hard to find elsewhere.  I recall it was fewer than ten.  I cooked most of them.  Fortunately the supply has improved since.  S.

 

Edit:  And getting off the next 12 pins was even harder!  S.

Last Edited: Thu. Oct 26, 2017 - 04:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
I fried half a dozen 32u4s before I found out that my "Five Volt" power supply was actually putting out more like six.

I believe it was annoying. But I mean something different. I think about MCU pins states that, if they would be undefined on reset, they could be by accident in state that could cause malfunction of devices connected to the MCU. No electronic devices manufacturer would buy such MCU to use it in his products.

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

You are right, that would be bad.  But most of my systems can tolerate a moment or two of indecision.  Some can't - Spacecraft reaction thrusters, for example* - and they get much more careful treatment than a simple 'and now we set them all as inputs' instruction.  Still, I set them all even for the cheesy ones.

 

I've never met an AVR that didn't do what it said it was going to do as long as I gave it the right stuff to do something with.  Still, I set all those I care about and can do something about.

 

Scroungre wrote:
... have my AVRs set all their pins to high-impedance inputs as about the first thing in every program.

 

I'm quoting myself again.  This is very poor style.  S.

 

* For stuff like that you use a complex initialization sequence that is just about impossible to ever occur by chance.  In case you happen to be designing spacecraft bits.  FYI.  YMMV.  S.

 

As another aside, this entire thread has gone completely off the rails and we've not heard a peep from the OP since the WDT timeout remark, which I will say is still probably the best way, although there may be others.  All the rest of this is esoterica.  S.