[WP 34S] I finally bricked it :-(

[John Galt]

It took some effort, but the sacrificial machine I had been using for testing is not only merely dead, it's really most sincerely dead.

During a routine flashing, MySamBa reported a failure to acknowledge midway through the transmission. After the erase procedure the calculator had always drawn about 8 mA from the power supply. It now draws only 1.8 mA no matter what. If there's a way to recover, I don't know what it is.

I tried:

- numerous erase cycles
- using the LM1117 regulator as well as a bench power supply and batteries
- shorting the battery contacts together

It's difficult to estimate the number of erase cycles since I did not start counting anything until after the first flash was successful, but I estimate it to be approximately 100, but certainly less 200 erase cycles.

[walter b]

I can only recommend to strictly follow the procedures given in the manual (watch the applicable footnotes, too, and go to the Troubleshooting Guide if necessary). It's actually pretty hard to brick this calc IMHO.

d:-/

[John Galt]

I will do that Walter. Thanks for reminding me.

[BarryMead]

(02-01-2015 04:42 PM)John Galt Wrote:  It took some effort, but the sacrificial machine I had been using for testing is not only merely dead, it's really most sincerely dead.

I don't personally have such equipment or even know someone who does, but it has been reported in other postings within this forum that SOME have recovered from such a flashing error by loading the firmware into the calculator's flash using the "JTAG" connector. For this to work someone needs an ARM compatible JTAG programming device. The JTAG device is able to write to the flash without assistance from the processor running code in the "BOOT PARTITION" which is how the normal flashing operation works. You might ask around to see if anyone can "UNBRICK" your calculator with a JTAG programmer.

Best of luck, Barry

[John Galt]

The problem is almost certainly within the calculator's hardware. The exact same equipment and exact same procedures using my other, non-sacrificial calculator is completely successful.

(02-01-2015 05:12 PM)BarryMead Wrote:  I don't personally have such equipment or even know someone who does, but it has been reported in other postings within this forum that SOME have recovered from such a flashing error by loading the firmware into the calculator's flash using the "JTAG" connector.

Thanks Barry, that's way beyond my comprehension at this point but I'll keep it in mind. If someone with the knowledge and equipment wants to try it, let me know. At this point I'm regarding the calculator as a parts unit.

[PANAMATIK]

(02-01-2015 06:15 PM)John Galt Wrote:  During a routine flashing, MySamBa reported a failure to acknowledge midway through the transmission. After the erase procedure the calculator had always drawn about 8 mA from the power supply. It now draws only 1.8 mA no matter what. If there's a way to recover, I don't know what it is.

It is a common mistake in boot loader software design, that it is not completely immune against midway interruption. Even in some Application Notes of processor manufacturers you may find these wrong designs. I think the MySamba compatible boot loader is hardcoded in the ARM processor, but possibly they made the same mistakes there.

The new ACTs boot loader is immune against midway transmission interruption.

Bernhard

[John Galt]

(02-01-2015 10:50 PM)PANAMATIK Wrote:  It is a common mistake in boot loader software design, that it is not completely immune against midway interruption. Even in some Application Notes of processor manufacturers you may find these wrong designs. I think the MySamba compatible boot loader is hardcoded in the ARM processor, but possibly they made the same mistakes there.

That sounds like a reasonable explanation for what occurred. In the past I intentionally interrupted the transmission just to see what happens, but a subsequent erase cycle was successful. That appears not to be the case this time.

[John Galt]

(02-01-2015 05:03 PM)walter b Wrote:  ... It's actually pretty hard to brick this calc IMHO.

Walter, in another thread I came to the realization that the erase cycles to which I was subjecting this calculator may have been completely unnecessary:

(02-02-2015 06:40 PM)Marcus von Cube Wrote:  You shouldn't ERASE a working 34S. Instead do the following:

1. Press ON+STO+STO to save RAM to flash.
2. Press ON+D to unlock the next step.
3. Press ON+S+S to enable SAM-BA boot mode.
4. Connect the calculator and arm MySamba.
5. Turn ON the calculator and start the transfer.
6. Reset the Calculator when done.
7. On power on the saved RAM contents will be restored.
   

The library will be replaced by what comes with the flash image but the RAM contents will be preserved.

I thought "erase" was always a prerequisite to "flash". Apparently this was a grievous misconception on my part.

Did I contribute to this calculator's demise by erasing it too many times?

On the one hand I would feel bad about having suffered the consequences of my own ignorance, but on the other I really would like to know how I killed it so that I don't do that any more.

[walter b]

(02-02-2015 06:54 PM)John Galt Wrote:  Walter, in another thread I came to the realization that the erase cycles to which I was subjecting this calculator may have been completely unnecessary ...

John, the manual's your friend once again. Please see App. A, "Updating Your WP 34S", concurring with Marcus' statement.

(02-02-2015 06:54 PM)John Galt Wrote:  Did I contribute to this calculator's demise by erasing it too many times?

I doubt it. Even you would not have been able to flash it 10 000 times.

d:-)

[John Galt]

(02-02-2015 07:57 PM)walter b Wrote:  I doubt it. Even you would not have been able to flash it 10 000 times.

It was not from lack of trying :-o

Does the erase action do anything at all, if flash memory has already been erased?

The reason for asking is that I did not flash it nearly as much as I erased it. I understand the flash (write) limit as you explain, but over the course of my initial experiments the number of erase cycles easily exceeded those by 10x. Still, I think those erase cycles (or attempts at erase cycles) was < 200 or so. The total number of actual, successful flash (programming) events was ten or fifteen. No more than that.

[MarkHaysHarris777]

(02-02-2015 07:57 PM)walter b Wrote:  John, the manual's your friend once again. Please see App. A, "Updating Your WP 34S", concurring with Marcus' statement.

(02-02-2015 06:54 PM)John Galt Wrote:  Did I contribute to this calculator's demise by erasing it too many times?

I doubt it. Even you would not have been able to flash it 10 000 times.

d:-)

I doubt it too. But, we are now touching on 'why' I am providing contact bounce conditioning in my flash box (its not for the lights, its for the CMOS).

What I suspect you are running into is NOT bricking, in that sense of the word, but a catastrophic hardware failure caused 'usually' by ESD (electrostatic discharge). It is possible during plug-in of the flash clip, or during 'reset' or 'erase' switch press to stress the CMOS inputs of the calculator effectively 'blasting' the hardware with a 'lightening' strike from which it will never recover. Discharging oneself before flashing is a good idea, as well, having a 'static free' exchange (which can be minimized with the control circuits of the 'flash-box' but which (alas) cannot be eliminated at all times. This is also one reason why I'm nervous about flashing my unit. I realize that each and every time may be its last. On the other hand, many people have flashed their units repeatedly (dozens of times, reportedly) without incident. In fact you may have the dubious honor and distinction to be the ONLY person to ever brick their unit. I read in another thread that said emphatically, " not even one person has bricked their 30b! " Apparently, we have ONE. :-}

ESD has killed yet another CMOS circuit/

marcus

[walter b]

(02-02-2015 08:23 PM)MarkHaysHarris777 Wrote:  ESD has killed yet another CMOS circuit/

Well, if we're talking about ESD protection then we'd need a conductive grounded floor, a special chair, grounded table mats, conductive shoes and straps, a properly grounded flash cable, etc. and NO PLAIN PLASTIC anywhere near the open calc. Though looking at the calc itself I doubt that's necessary here - but honestly I've to admit I don't know.

d:-?

[John Galt]

(02-02-2015 08:23 PM)MarkHaysHarris777 Wrote:  ESD has killed yet another CMOS circuit/

I seriously doubt it. I've worked with CMOS all my life and never killed a single thing through static discharge, sometime even after repeated and deliberate attempts to do so.

If this HP were that sensitive I would have killed many others through disassembly and repair, in addition to normal usage.

Bernhard's explanation makes a lot more sense.

[Marcus von Cube]

(02-02-2015 08:49 PM)John Galt Wrote:  I've worked with CMOS all my life and never killed a single thing through static discharge, sometime even after repeated and deliberate attempts to do so.

My first development unit has developed a serious fault. It can no longer be flashed through the serial port, only through its JTAG connector. The input to the processor seems to be broken.

So it is possible to kill a (in my case) 20b.

[MarkHaysHarris777]

(02-02-2015 08:49 PM)John Galt Wrote:  

(02-02-2015 08:23 PM)MarkHaysHarris777 Wrote:  ESD has killed yet another CMOS circuit/

I seriously doubt it. I've worked with CMOS all my life and never killed a single thing through static discharge, sometime even after repeated and deliberate attempts to do so.

If this HP were that sensitive I would have killed many others through disassembly and repair, in addition to normal usage.

Bernhard's explanation makes a lot more sense.

Its not whether the HP is sensitive to this... its whether CMOS is sensitive to this (ESD). Back in the day of MOS (predated CMOS) in IBM circuits many hundreds of thousands of dollars of equipment were lost to ESD before it was fully understood what was happening. The entire field engineering group (of which I was a part) were specially trained in the proper use of static mats, ESD straps, and clothing... there were certain fabrics we were not permitted to wear, and there were many procedures put in place (including the anti-static wrapping used on almost all CMOS boards today) to put an end to the monetary losses resulting from ESD. It worked. I have personally seen many planar boards 'blown' due to a noiseless, invisible 'lightening' strike(s) which literally blows holes (and shorts) the capacitive front-ends to the CMOS junctions. You can read about it here.

Cheers

[PANAMATIK]

(02-02-2015 08:19 PM)John Galt Wrote:  

(02-02-2015 07:57 PM)walter b Wrote:  I doubt it. Even you would not have been able to flash it 10 000 times.

It was not from lack of trying :-o

Does the erase action do anything at all, if flash memory has already been erased?

The reason for asking is that I did not flash it nearly as much as I erased it. I understand the flash (write) limit as you explain, but over the course of my initial experiments the number of erase cycles easily exceeded those by 10x. Still, I think those erase cycles (or attempts at erase cycles) was < 200 or so. The total number of actual, successful flash (programming) events was ten or fifteen. No more than that.

Erasing and programming flash memory is my daily work. The 10000 cycles are the number of guaranteed erase cycles by the datasheet of the manufacturer. You will have to flash the same chip for years to get over this limit. If you flash ten times a day you need three years. And the not guaranteed cycles can exceed the guaranteed by factor 3 up to 10. The programming cycles dont count. While developing my ACT I flashed the same chip about 50-100 times every day for debugging. There is no practical limit.

If programming is not longer possible it can have two reasons, the serial input/output or the whole chip is defective, or the boot loader firmware has overwritten itself or at least the interrupt vector table or the reset vector. This is the most common boot loader software mistake. There is a very short window when the reset vector will be written, about 10 ms, if the transmission is interrupted at that moment, the bootloader cannot start up the next time.

If you have JTAG tools and a complete binary file including the bootloader you could restore the chip. This is the engineers approach. The practical approach is to buy five other HP30b's, this is cheaper than the JTAG development system.

Bernhard

[John Galt]

(02-02-2015 09:56 PM)PANAMATIK Wrote:  . The 10000 cycles are the number of guaranteed erase cycles by the datasheet of the manufacturer. ... The programming cycles dont count.

Thanks!

[BarryMead]

(02-01-2015 10:50 PM)PANAMATIK Wrote:  It is a common mistake in boot loader software design, that it is not completely immune against midway interruption.

For this reason I have chosen to equip my WP-34S calculators with a "SOLID" flashing connector. One of my calculators uses Harald Pott's internal micro USB board, and the other two have a 2.5mm headphone jack glued down with epoxy. I feel that the "Pogo Pin" programmers are prone to lost or flaky connections if you move the cable during flashing unless you are lucky enough to own one of the original factory made programming cables which are designed to lock into place and permit NO-WIGGLE or alignment issues.
With these ROCK SOLID connections I can rest assured that the programming cycle will not be interrupted by a poorly connecting pogo pin connection.

[John Galt]

I agree a reliable programming port connection is essential Barry.

The connector I had been using was far from perfect. Making it so that it won't move isn't terribly difficult, just tedious, and I had been putting that off. It's now "rock solid" as you describe and from now on I'll tolerate nothing less.

By the way I believe the connection that may have broken half way through programming was J31 (Vcc). I was intentionally supplying calculator power through that pad, and it was that side of the connector that needed adjustment.

MarkHaysHarris777 you might want to keep that in mind, since your design is using the same idea.

[MarkHaysHarris777]

(02-03-2015 03:08 AM)John Galt Wrote:  I agree a reliable programming port connection is essential Barry.

The connector I had been using was far from perfect. Making it so that it won't move isn't terribly difficult, just tedious, and I had been putting that off. It's now "rock solid" as you describe and from now on I'll tolerate nothing less.

By the way I believe the connection that may have broken half way through programming was J31 (Vcc). I was intentionally supplying calculator power through that pad, and it was that side of the connector that needed adjustment.

MarkHaysHarris777 you might want to keep that in mind, since your design is using the same idea.

I too agree that a tight clean connection on the pogo pads is essential; which is why I chose the larger pointed pogo tips (they are more expensive, but worth it). John makes a good point too about the J31 Vcc pin. i have decided to place an electrolytic cap 1 mf 6v across Vcc (J31) to ground. My connector is tight and clean (I mean electrically it doesn't move at all) but why take the chance?

Thanks.