Let me try again... Why would anyone, these days, design a chip that needed such a voltage just to erase the contents of memory?
Then you've designed the wrong product.
Nonsense. Just require an enable pin, or some such, before erase.
wrote: ....
on
There is someone who ha snever had to chase down faults on enable or worse still power rail sequencing. Many past devices had specific requirements for the extra 12V programming rail, which required external circuitry (even if simulated by software in a micro) mainly to ensure VCC was stable before 12V or whatever programming voltage, as often the protection for 12V on those pins ONLY worked when VCC was stable otherwise you fried the device.
I have seen several faults on systems where the VCC was shorted or came up slow by some other fault, which meant 12V programmed devices fried as well!
Great way NOT to recover devices.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
Timing Diagram Font
GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
For those web sites you hate
Different discussion but you don't need JTAG for debugging. Stuff that isn't realtime is best developed on a PC so you can run large test benches against the code very fast. Besides that, affordable debugging tools for a PC are far more evolved than for embedded platforms.
If you need to debug realtime, JTAG is no option since you really don't want to halt an interrupt because before you stepped through the code, you'll have missed a boat load of other interrupts. Realtime debugging is best done by using counters in software or external signals to monitor state changes. When writing things which like PWM controllers it is best to write code which is safe by design.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
"Realtime" isn't the issue. That, too, can be simulated (often better and easier than "live"). The issue is hardware. Hardware, particularly hardware that you don't have the design for, is a lot more difficult to simulate. It's usually just not worth even an attempt, in an embedded system.
Sure, the only real option is tracing back from a failure (or checkpoint).
Suddenly I recall a co-worker had a similar problem with a Stellaris chip. It is a very commnon problem and there is a work-around:
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
Thin twice - if you're not very tight on processing time,
-O2, or still better, -Os gives better results in embedded controllers.
To look at the optimization, add -Wa,-ahlms=myfile.lst to the gcc command line and look at the generated assembly code.
You should also have most of the compiler warnings turned on, to catch subtle blunders which bite in the higher optimization levels.
-- Tauno Voipio
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.