Easy Reset from Software?

Status
Not open for further replies.
Teensy 3.2 here. It's working flawlessly, yakking over USB with a central control system running on a Linux box.

It seems that this question must have been asked by somebody but I can't find what I'm looking for.....

This system will eventually need to run unattended for unlimited periods of time. So, issues of the millis() timer overflowing and other possible corruption are an issue. I have tens of thousands of systems running out in the world, some still running non-stop since the late 1980s. Many are in life-safety and other critical applications. One of my practices is for such systems to reboot themselves periodically, like once a week, at a safe time. (No, this particular system is not for a life-safety application.)

Can I simply create a C function and insert a bit of machine code to jump to location 0 to induce a restart? Will this clear the millis() counter or does that require an actual hardware reset? If necessary, I'll do that.
 
Around on the forum somewhere I found this that works for me - looks like this :
Code:
#define CPU_RESTART_ADDR (uint32_t *)0xE000ED0C
#define CPU_RESTART_VAL 0x5FA0004
#define CPU_RESTART (*CPU_RESTART_ADDR = CPU_RESTART_VAL);

Excute with :: CPU_RESTART
 
Excellent. Thank you.

I could have studied the manual, but I wanted reassurance from somebody who knows. Now, I'll have to go study the processor manual to understand how that works. Seems like an interesting way to restart a processor by writing certain bits to a certain address.

Best regards. Thank you again.
Phil
 
I hope you're using hardware-watchdogs for your critical applications.

All the systems I've designed over the past 30+ years used hardware watchdogs that performed an actual hardware reset of everything. Rebooting was simply a matter of deliberately letting the watchdog shoot me in the head. This application isn't serious enough for that. I just want to boost stability by using the weekly reboot trick.

This gadget has two processors doing completely different things and there's a heartbeat sent between the two every 30 seconds, plus any other communication, which is all ACKed. Loss of communication is flagged and visually apparent to the user. I'm considering giving both processors the ability to hardware reset the whole system. The odds of both processors crashing at once is small.

But, again, this isn't that critical an application like those I've done in the past so I'm still thinking about it.
 
If you connect the reset signal of both, both Teensy3.2 will reset - might be useful.

Yes, I've considered that it might be that simple, but haven't looked into it yet. In this case, it's a Raspi 3 and Teensy 3.2 working together. Right now, I'm developing on my ordinary Linux laptop with the Teensy, and will port the laptop software to the Raspi when it's done. Only then can I test, so I'll look into it at that point. It would be very nice if it's that simple. I'd like for either processor to be able to pull the trigger on the whole system and restart it.
 
I have not used the Raspi for a very long time - Is there still the issue with the corrupted/destroyed filesystems with unexpected power-off or reset?
 
I don't know. This project is my first venture into the Raspi world.

I'd use reboot/shutdown in this case.. and be sure to always have the latest backup of your SDCard.
That's the main reason why my raspis get dusty in the drawer. A gadget that can't be turned off at any time, and every few weeks makes trouble with the SD card is too annoying for me.
But maybe that has improved in the last years?
How long does it need to boot nowadays?
 
Hmm. I'll be on the lookout for that problem. Don't know on the boot time yet either. I haven't bothered to unbox the Raspi because I'm not ready for it. All development is happening on my Linux Mint laptop and the Teensy. Unboxing the Raspi and porting the software over is pretty much the very last step.

I've been tempted to unbox it and play with it a little, but I don't want to waste time.
 
Status
Not open for further replies.
Back
Top