Hard off switch on the Hammer Head

Genesis

Two things here that bother me about this...

1. The system apparently doesn't know it reset due to a brownout. That's not cool. Power problems are serious and should be flagged to the user along with the system taking whatever steps it is able to attempt to prevent a second occurrance.

2. It also goes through its full startup test when underwater, which is what everyone's garfing about.

But - if #1 was flagged then there wouldn't be a problem either..... a brownout reset SHOULD set a flag that prevents actions that are likely to cause a SECOND reset (e.g. firing the solenoid) along with alarming so the user knows it happened.

__________________
"A venturesome minority will always be eager to get off on their own, and no obstacles should be placed in their path; let them take risks for Godsake, let them get lost, sunburnt, stranded, drowned, eaten by bears, buried alive under avalanches - that is the right and privilege of any free American."
http://www.denninger.net
http://www.diversunion.org/liability.htm - Fix the Diving Cert racket

jradomski

actually its not really a brownout.. there is a supervisor to monitor voltage levels.. when it is below a certain threshold it performs a reset of the processor.. this looks exactly like a power up reset.. if ground is lost... the processor resets..its not a low voltage condition.. its usually a no voltage condition..

I am not going to say what parts Kevin is using even though I figured them out myself... I use the same family as him for many of my projects.. Its a great chip, but when programming in C.. determining different power conditions is not a trivial task.. If the app was written is ASM it would be fairly easy.. But this type of app does not lend itself to asm programming.. I usually program in ASM myself, but I wouldnt even attempt it here..

__________________
Joe Radomski
CCR Trimix Instructor Trainer
ANDI Instructor Trainer Director #10

All posts are personal opinions and DO NOT reflect any affiliated agency unless specifically stated.

Genesis

Yeah, its a brownout. Most processors have a brownout detection circuit. SOME of them leave a flag in a register when they reboot as a consequence of a power trip - but not all. Some of the supervisory circuits just hit the RESET pin and hold it for some period of time. Those suck. Better ones make sure there's a flag left in the processor state.
There's no reason why you shouldn't be able to query the flag register in the CPU if your code is in "C". If that's being cleared on startup, then sub your own "main()" startup routine in there during link-time and jump to the compiler-provided one once yours has run and stashed away the state flag somewhere.

If you've got a chip that can't do that, IMHO its not well-suited for this sort of application.

I write code in both HLLs and assembly - "C" is fairly close to the metal and any decent compiler for an embeded system (irrespective of the actual language) should be able to directly query processor state registers.

__________________
"A venturesome minority will always be eager to get off on their own, and no obstacles should be placed in their path; let them take risks for Godsake, let them get lost, sunburnt, stranded, drowned, eaten by bears, buried alive under avalanches - that is the right and privilege of any free American."
http://www.denninger.net
http://www.diversunion.org/liability.htm - Fix the Diving Cert racket

silent running

Alright Mark, Joe question: given that the solenoid is the biggest power consumer in the system, wouldn't it be better if the unit automatically disabled the solenoid in low voltage conditions and only displayed sensor data and HUD? My guess is the solenoid firing in low volt conditons is going to keep the the thing rebooting as when it fires, it draws the dying batt down lower and causes endless reboots til the bat dies. Low volt disabling of the solenoid seems like a no brainer much safer choice for handling such a situation. Then at least you'd have the displays and deco info for however long the batt lasts and you can inject manually... -Andy

PCDiver

Great suggestion. Driving the HH manually with the primary providing deco and the hud/secondary for cell monitoring is a piece of cake.

jradomski

I prefer external supervisors that hold a processor in reset myself.. I have used chips that do brownout detection, but in my experience its only good for certain things.. I have had more than one device get corrupted by depending on a brownout circuit.. (usually when writing to flash).. The external supervisors respond much quicker than the included brownout detection.. Even chips that are supposed to have very sensitive brownout detectors like security products, dont respond fast enough (this is how may smartcards are dumnped!!) to an undervoltage condition in critical apps (many of these you will see secondary supervisors).. In these apps you have to prevent the brownout in the first place..

If A chip does have internal brownout detection it usually has some type of flag that gets set, otherwise there is no flags to look for..
My comment about "c" not being friendly to these tye of apps is now you need to write custom bootloaders, to first try to determine if there is the possibility that there was a brownout, is ram valid?? or just a POR.. now you have to take the place of the compiler and initialize all the data and stack that the C compiler assumes is supposed to be initialized and set.. Remember alot goes on before the processor ever hits the "main" function..

Alot of c compilers dont even have an option for a "no initialize" section.. Sonow you have to write you C code in a way that you will initialize everything yourslef and hope the c compiler doesnt optimize it in a way you can;t control.. ANSI C has very specific behaviours they are supposed to follow and things that are clearly left up to the compiler.. Some of these behaviours you have absolutely no control over.. If data is not explicity used, and passed out of a function, the compiler usually just throws this away, and that IS the correct thing its supposed to do..

take a simple delay function called from another function

void delay(void)
{
int i
for(i=0; i<65535; i++)
{

main{
for (; ; )
Delay();

}


The compiler does not have to generate ANY code for function delay nor does it have to call it.. The compiled code can simply be an infinite loop..

basically

main{
for (; ; )
}

even if I added something like
a=a+i; within the loop of the delay function, If I don't pass 'a' out of the function it would not be created either..

but if I made delay return a status, then checked it in main then it would be created.. Most of this as programmers we dont care about, but if you are going to take over initializations you really need to know everthing the compiler for your particular chip is doing, and realize the code may not be portable anymore.. You also run the risk that an updated compiler will break your application on future builds.

__________________
Joe Radomski
CCR Trimix Instructor Trainer
ANDI Instructor Trainer Director #10

All posts are personal opinions and DO NOT reflect any affiliated agency unless specifically stated.

jradomski

I agree partially, but most of the resets are not due to this, its due to the system losing the ground of the battery.. In apps that I have a Powerhungry component, that I usually determine some threshold that I stop it from working, generate an alarm, and try and maintain the rest of the system in alarm state..
On a life support system this gets to be a tricky choice... If I am monitoring a serious condition like low o2, and I know I am past my threshold that will likely reset my device and lose all my data, do I try and see if I can solve the most immediate problem that is.. low o2,, I say thats probably the better choice, since its the most pressing issue, even though we know what the probably outcome is, but we MAY still be able to raise the o2 and solve The most pressing issue....

What good is deco data if you die of anoxia..

__________________
Joe Radomski
CCR Trimix Instructor Trainer
ANDI Instructor Trainer Director #10

All posts are personal opinions and DO NOT reflect any affiliated agency unless specifically stated.

Genesis

Well, nothing obviously.

Now if you hit the solenoid though knowing you can't actually get it open without the voltage rail collapsing then you both fail in the desired test and lose the deco data. You also lose the ability to alarm (since you reset) which is worse, because although the system cannot raise the PO2 in that state, the human can - if he knows he needs to.

I don't think there is ever an argument for attempting an action that is likely to fail, especially if there are other actions you can take which require less power (and thus are either known capable of success or highly suspected of being able to do so) which will raise an alarm.

This is doubly true if you can't maintain supervision over the processor state across a brownout, as appears is the case here.

I can see attempting the required action (hitting the solenoid) ONCE, but if you take a reset doing so, you must assume that further attempts are futile and you then go to the next-best option (e.g. audible alarm?) - if THAT elicits a reset as well then you're left with blinking the backlight (assuming that draws less power), or whatever's left.....

What I find unacceptable from a design perspective is continuing to beat your head against a wall having already failed at the task at hand.

Joe, I understand the issue with C "startup routines", but in an embedded systems development environment you had better have decent control over this sort of stuff (e.g. access to processor registers delineating WHY the unit went down) OR you need either (1) a more appropriate development environment or (2) hardware that supports the information you need to have to make intelligent decisions.

I just don't see why this sort of thing is happening in a commercially-sold system when the issue and risk is well-understood. It can't be hard to at least avoid the multiple-reset situation by not firing the solenoid if the wet switches are closed on a powerup. I guess there's an argument to be made that trying to play "parachute" if the PO2 is under .21 is sane in any event simply because by then there's a death about to occur - but that's an argument I believe could be convincingly made in either direction.

As a guy who's written a lot of embedded control code, some of which has gone into safety-critical systems, I would have never found it acceptable to be unable to know why a system reset occurred. One of the more hairy installations I was responsible for was an antenna controller for satellite earth station gear - swinging an 11 meter dish around on a 120mph-windload-rated mount, with BUILDING beyond both of the stops. Mistakes there could very easily kill or do incredible amounts of property damage (think "antenna knocks brickwork off top of 35 story building onto downtown Manhatten street below!") A reset in that system that went unnoticed could easily lead to the loss of 100 or more "counts" on the encoder, which in turn could lead to an attempt to overrun the limits. While in theory there were PHYSICAL switches on the rail to prevent this, we all know what happens when you rely on ONE safety system right?

__________________
"A venturesome minority will always be eager to get off on their own, and no obstacles should be placed in their path; let them take risks for Godsake, let them get lost, sunburnt, stranded, drowned, eaten by bears, buried alive under avalanches - that is the right and privilege of any free American."
http://www.denninger.net
http://www.diversunion.org/liability.htm - Fix the Diving Cert racket

sensor330

Gee this thead didn't get off topic at all .

Genesis

I don't think so. The issue was a "hard power off" and the reason it was requested was the potential problem with the primary deciding to go into an infinite reboot/injection loop when the power was low, which screws you hard even if the secondary handset is perfectly functional.

I'm pointing out the ways in which the "reboot/inject" cycle could be avoided in the first place, which would allow the unit to adhere to the desired behavior (that is, "its never off" due to the desire to provide an "automatic parchute") yet not cause the problems that people requesting the "hard off" option are using as justification for the desired option.

__________________
"A venturesome minority will always be eager to get off on their own, and no obstacles should be placed in their path; let them take risks for Godsake, let them get lost, sunburnt, stranded, drowned, eaten by bears, buried alive under avalanches - that is the right and privilege of any free American."
http://www.denninger.net
http://www.diversunion.org/liability.htm - Fix the Diving Cert racket