how to reset UC3A mcu via software

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

Hi,

 

Can someone suggest how I might hard reset my UC3A from C code? - is their any ASF function to do this?

 

If it cannot be done in C, then some ASM inline code maybe? e.g. jump to reset vector?

 

I need the software reset to reset everything software related e.g. stack etc. and reboot as if booting and running main() for the first time

 

I have look for previous thread but found nothing related to UC3A

 

Thank you

This topic has a solution.
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use the watchdog. Actually there should be a few threads describing that strategy here on the forum.

Here’s the quick run-down:

1. Enable watchdog with a short timeout.
2. Enter an infinite loop and wait for the reset.
3. After reset, make sure to disable or reconfigure the watchdog.

Beware that the reset interval cannot be too short because otherwise your device will keep resetting itself before you can disable the watchdog.

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

Thanks for the reply, its an option, but i was thinking a simple jump to reset vector somehow might be easy option - no?

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

If you can't connect a GPIO pin to the N_RESET pin to perform a hard reset directly, the most common approach is to use the watchdog.

Set a reasonable timeout value, enable watchdog reset and wait inside a while(1); loop for it to time out and reset the chip.

Globally disabling interrupts prior to entering the while(1); loop should prevent any event handlers from clearing the watchdog timer unintentionally. (Who in their right mind clears the watchdog timer inside a ISR ?)

 

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

Heh... I'm slow today, or the new AVRFreaks server has some serious cache inconsistencies going on...

 

You shouldn't just jump to the reset vector because it's not going to reset anything at all...

The stack is going to be re-initialized but re-initializing the peripherals while they are already initialized could cause some weird stuff to happen.

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

After DukerX felt the need to elaborate on my replies today, I now feel the need to elaborate on his reply. ;-)

 

Just jumping to the reset vector is possible and there’s actually a Reset_CPU() macro in the compiler.h of the ASF 1.7 that I’m (still) using, which resets all the CPU registers and status flags, then jumps to _start.

 

As DukerX mentioned, this strategy doesn’t actually reset anything. I’m using it for a project where connecting the reset pin externally or using the watchdog both aren’t possible and it’s quite a pain. You have to make sure that all peripheral modules and all interrupt sources are disabled or things will start acting funny as soon as you globally enable interrupts. For example, according to the datasheet of the A3, disabling the USBB will reset it. However, that isn’t really true, as some registers, like those controlling USB DMA, are not reset. If you don’t clear those registers, the DMA controller might suddenly write somewhere into your RAM once you enable the USBB after the reset. Fun times.

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

Thanks for all your advice fella's, I have opted for using the watchdog timer method

 

I have added WDT - Watchdog Timer (driver) to my Atmel Studio Project and added #include "wdt.h" to my main.c file

 

It compiles ok without any errors

 

I am calling wdt_reset_mcu() ..... but its not happening, it just seems to freeze not restart

 

Something is happening because the leds attached to my RS232 TX lines go out but it does not appear to start running main()

 

Anyone got any ideas why?

 

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

Are you calling wdt_reset_mcu() soon after startup ?

Last Edited: Fri. Sep 12, 2014 - 05:43 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

No mikech not soon after startup

 

I have changed my code to the following and it now resets:

 

 

cpu_irq_disable();

// Enable the WDT

wdt_opt_t opt = {

.us_timeout_period = 1000000

};

wdt_enable(&opt);

while (1);

 

 

It seems that wdt_reset_mcu() resets the cpu but then HOLDS the cpu in a reset state - I cannot imagine why you would want this to happen

 

The code above causes a reset every second so I had to add a wdt_disable() to the start of main() - why?

I thought a watchdog reset was going to perform a full reset - surely then the watchdog timer would be disabled following this ... but apparently not

 

If anyone can shed any light on these two anomalies I would love to hear the explanations of why the above happens even though I have a working solution now

 

Thanks Guys

Last Edited: Fri. Sep 12, 2014 - 07:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you look at the UC3Axx datasheet in the Power Manager documentation, there is a table (13-4 on page 65 in my copy) showing what is actually reset by the different reset sources. Watchdog control register is one of several registers not reset by a watchdog reset.

 

That's why you must give yourself enough timeout to disable or reconfigure the WDC after the reboot.

Last Edited: Fri. Sep 12, 2014 - 08:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok I see, thank you for that, so watchdog reset is not quite the same as an external reset doh. I thought they were, so thanks for clearing that up DukerX

Last Edited: Fri. Sep 12, 2014 - 09:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No problem Rookie.

I'm not sure you noticed in the datasheet, but there are a few thing snot even the external reset would clear.

Only a Power-On reset is going to clear everything that is clearable.

 

One thing to note is that SRAM is only ever actively cleared by a "chip erase" command.

After Power-On reset the memory is going to fall into a pattern that got introduced from tiny variations in silicon manufacture, and would probably be unique for each die.

This is another good reason why you should never ever use un-initialized variables.

I've found that as long as the chip is powered, the SRAM is going to retain it's data through all the kinds of resets I was able to throw at it, and I have used this one time to track down a really nasty bug that manifested very rarely.

Right at the reset vector, I added code to check for a watchdog reset, and if the watchdog had reset the chip, it would just dump the entire SRAM to a USART without touching it.

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

The reason why "wdt_reset_mcu()" appears to hold the cpu in a reset state is because this function does exactly what your code does except it sets ".us_timeout_period" to zero before going into a while(1) loop. The watchdog module registers are not reset by a watchdog reset, so the cpu will enter a reset loop because it most likely will not be able to complete the idata loop in startup_uc3.S before another watchdog reset occurs and before the main function is executed where you can change the us_timeout_period. I ran into this issue a few months back ended up doing basically the same thing that you are. I also found an open bug http://asf.atmel.com/bugzilla/sh... .