How to choose a firmware partner - Page 5

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: How to choose a firmware partner
Quoted text here. Click to load it

Are you joking?  I don't see a smilely.  I can run my PC for 2 or 3
weeks without lockup.  Does that prove that Windows 2000 has *NO* bugs?
Funny, it usually doesn't go much beyond about 30 days without locking
up.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: How to choose a firmware partner

Quoted text here. Click to load it

Yes.

-Hershel

Re: How to choose a firmware partner
snipped-for-privacy@tesco.net ( snipped-for-privacy@tesco.net) wrote in

Quoted text here. Click to load it

I give it a 3.  Not terribly original, but it is getting responses.

--
Richard

Re: How to choose a firmware partner
On 26 May 2004 13:54:08 GMT, the renowned Richard

Quoted text here. Click to load it

Yes, the TROLL-O-METER needle is flickering upscale a bit.

Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: How to choose a firmware partner
Quoted text here. Click to load it

Damn, I got trapped :-)
---
42Bastian
Do not email to snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: How to choose a firmware partner
Quoted text here. Click to load it

So this may seem (a troll), to some people, but won't anyone even
consider this for a moment:

1) A one byte loop is lockup-proof.

2) So for a standalone, MCU, lockup proof code is only a matter of
scale.

3) Evidently the MCU hardware itself cannot become inherently "stuck"
because that would make the clearWDT instructions inaccessible and a
mockery of the whole watchdog scheme.

I am guessing that the above posters are talking of complicated,
multiproccessor, asynchronous systems; which is a little narrow
minded.

A better response could be: "The OP probably means 1/2k of code
running in a 12C505, heh heh, he'll grow up eventually!"

Cheers
Robin

Re: How to choose a firmware partner
Quoted text here. Click to load it

Yes, I did consider that for a moment, but then the Troll-o-meter
kicked in, as it did on the first post. -jg


Re: How to choose a firmware partner
Quoted text here. Click to load it

Untrue.


I've used watchdogs (external hardware watchdogs, i.e. cannot be disabled)
in systems with a single 8-bit CPU, 128 bytes of RAM, and under 2k of ROM.

Again, you're missing the main point of using a watchdog. It's nothing to do
with software.

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com




Re: How to choose a firmware partner
Quoted text here. Click to load it
So you've never run code on a standalone MCU in an electrically noisy
environment then?
--
Tim Mitchell

Re: How to choose a firmware partner

Quoted text here. Click to load it

Unless, of course, theres a glitch on the power rails or something that
sends the PC off to neverland.

Quoted text here. Click to load it

Assuming your hardware is perfect, which it's not.

Quoted text here. Click to load it

Of course it can becom stuck. If the "clearWDT instruction becomes
inaccessible" then something is very wrong. The watchdoing will timeout
and reset the CPU. Thats the whole point!

Quoted text here. Click to load it

If your 12c508 code is expected to be very reliable, then I'd include a
watchdog.

Al

Quoted text here. Click to load it


Re: How to choose a firmware partner
Quoted text here. Click to load it

Yes, that was a dumb of me to "derive". But it suggested this idea:-

You fill your MCU with NOPs plus one (RAM less) IO toggle and run it
under EM and ES duress. If it latches permanently, you know the core
is inherently vulnerable and you don't use that device.


Quoted text here. Click to load it


We have to enable WDT to conform. I hate it because the only post
production failure we had was WDT induced:

At cold temperatures the (CR) period of the (independent) WDT reduces
by 20%. I did not realise this. I set all WDT reset-times at the most
infrequent possible (at room temperature).

At low temperatures, our system became locked in a constant re-boot
cycle.


Cheers
Robin

Re: How to choose a firmware partner
Quoted text here. Click to load it

"Latching permanently" - do you mean a) CMOS latchup (which would be down to
poor integration); b) other excluded logic state (fixed via a reset); or c)
loss of software control (also fixed by a reset)?

I don't understand how any of these affect the choice of CPU.

Quoted text here. Click to load it

Ah, I see where you're coming from. The lesson here is not to avoid
watchdogs; it's to make sure you read the datasheets. I'm afraid this was a
hardware/software integration error. The watchdog was doing its best to save
your ass, but you misprogrammed it.

I'm a bit puzzled by this statement:
Quoted text here. Click to load it
temperature). <<

How exactly? Surely you didn't use a timer; that would be pretty silly.
There are various approaches to watchdog-kicking, but assuming it's an
external hardware device kicked via an I/O pin, then a well-proven scheme
follows:
  - Take the I/O pin high in the heartbeat interrupt (e.g. every 5ms or
whatever - regular signal)
  - Take the I/O pin low as the lowest priority task in your roundrobin (or
scheduler - i.e. the highest-level non-interrupt driven task).

This scheme has the added advantage of giving you a crude but effective CPU
utilisation monitor on the I/O pin. Watching this pin with a scope gives you
a good view into how busy your CPU is.

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com



Re: How to choose a firmware partner


Quoted text here. Click to load it

It's worse than that, read on.

Quoted text here. Click to load it

So what you seem to be saying is, "I don't read datasheets and when
things go wrong for me it's the manufacturers fault".  If you think it
can only vary by 20% then you will be rudely educated again.  For
example on a 16F628 the acceptable limits (according to the datasheet)
is 7 - 33mS with 18mS being "typical" (no prescaler assigned).  I'm
really not trying to be an ass, but you absolutely have to RTFM when
working with these things.


Re: How to choose a firmware partner
Quoted text here. Click to load it

No, I do read data sheets but I have a small attention span and a bad
memory so I expect to make mistakes.

Therefore the simpler the system, the more likely it will work (for
me).

The more sensible the job the more likely it will fascinate my brain.

The sillier the job the more likely my brain will wander, and make
mistakes.

Therefore I expect to make more mistakes implementing e.g. <wdt>
types. It may be that I am unique but I doubt it. I think some others
do likewise and I think the sheer dullness and difficulty
(impossibility) of optimising the placement of the wdt_resets
(ignoring future maintainability horror) will likely lead to wholesale
sloppiness sooner to later and agressive management or timescale
pressure will guarrantee it.

Cheers
Robin

Re: How to choose a firmware partner
Quoted text here. Click to load it

Remind me not to hire you ;).

Quoted text here. Click to load it

Errr... see my earlier post. There is no "dullness" or "horror" involved in
kicking watchdogs - one just has to be methodical. And since being
methodical is the name of this particular game (embedded design), I can't
help but wonder whether you've chosen the right career.

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com



Re: How to choose a firmware partner
Quoted text here. Click to load it

Why? Do you have a short attention span and a bad memory too? =:)=

Cheers
Robin

Re: How to choose a firmware partner
On 3 Jun 2004 00:45:31 -0700, snipped-for-privacy@tesco.net

[...]
Quoted text here. Click to load it


Misreading (or not reading, or forgetting) the datasheet was a silly
mistake.

But the sillier one was trying to "optimize" your WDT updates.  There
is really no reason to do so.

For my superloop code, the WDT is updated in exactly two places:
immediately after reset, and at the top of the superloop.  Combined
with special "come from" tests to ensure the program flow is as was
expected, our systems have no trouble surviving some really nasty ESD
testing required by our customers.  (Without a WDT, I _guarantee_ your
system will fail these tests.)

Multitasking systems also update the WDT in exactly two places:
immediately after reset, and in a low-priority periodic task that
checks to make sure the system is operating correctly.

Under normal operation the WDT is being updated several orders of
magnitude more often than is necessary.  Who cares?  It's abnormal
operation I care about, and what the WDT is supposed to remedy.

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: How to choose a firmware partner
snipped-for-privacy@hotmail.com (Dave Hansen) wrote in message
Quoted text here. Click to load it

<snip>

Quoted text here. Click to load it

Yes it's a silly mistake that *anyone* can make.
 
Quoted text here. Click to load it

Very well, _guarantee_ that this code will fail without the wdt
enabled:-
  ...
  jmp      test
  jmp      test

test
  bitset   PORT,test_bit
  bitclear PORT,test_bit
  jmp      test
  jmp      test
  ...

Quoted text here. Click to load it

So a high energy particle changes your program counter and you have a
random GOTO occur but your program does not reset because the chances
of the GOTO landing near a wdt_reset is now "several orders of
magnitude" higher? And you say "Who cares?"

Cheers
Robin

Re: How to choose a firmware partner
Quoted text here. Click to load it

I'm not sure I understand your point, but in any case, if your test_bit is
the watchdog output, then it's not a good idea to output both states in the
same place. I and others have given you examples of watchdog-kicking
strategies - have you read and understood them?

Quoted text here. Click to load it

Eh? I'm sorry, this makes no sense at all to me. To reiterate: in normal
operation, software will periodically kick the watchdog (high and low, in
two wholly unrelated places that both need to happen to accurately represent
"normal operation") to stop it timing out and hence resetting the CPU. If
the program loses control, then the watchdog is not kicked in those two
places, it times out, and the CPU gets reset. Whether a random GOTO lands
near a watchdog kick (one state only) has nothing to do with anything.

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com



Re: How to choose a firmware partner
On 4 Jun 2004 00:58:45 -0700, snipped-for-privacy@tesco.net

Quoted text here. Click to load it
[...]
Quoted text here. Click to load it
That will fail whether or not there's a WDT.  You've made another
silly mistake.

[...]

Quoted text here. Click to load it

And another.

Remember, there are exactly _two_ places in the code where the WDT is
reset, not "orders of magnitude."  It's a loop.  And if we _do_ jump
to the top of the loop from somewhere in the middle, the "come from"
test will fail, triggering a reset.

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Site Timeline