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

[John Galt]

(02-03-2015 03:40 AM)MarkHaysHarris777 Wrote:  1 mf 6v across Vcc (J31) to ground.

Why so little? You're thinking like a digital designer. It's the power supply. Go big.

[MarkHaysHarris777]

(02-03-2015 05:26 AM)John Galt Wrote:  

(02-03-2015 03:40 AM)MarkHaysHarris777 Wrote:  1 mf 6v across Vcc (J31) to ground.

Why so little? You're thinking like a digital designer. It's the power supply. Go big.

My bad... I meant 100 mf ... <sorry> you can see it in the latest pics on the photojournal.

[walter b]

(02-03-2015 11:23 AM)MarkHaysHarris777 Wrote:  My bad... I meant 100 mf ... <sorry>

An error of two orders of magnitude only, so don't care ...

d;-/

[John Galt]

Well, if you're going to make a mistake, make it a big one!

MarkHaysHarris777, I'm poking fun at myself, not you. Little mistakes aren't worth my time :-) As a matter of fact I'm sure I brought this misery upon myself because I decided to forego everyone else's recommendation to use the sharp point (J series) spring pins you're using. The reason is that I knew I'd be making many modifications to the connector and did not want to abuse the programming pads while doing so. I don't know how thick the copper is. So I used spring pins with hemispherical tips (B series) thinking they might result in less abuse. I have both varieties. If you don't try different things, no one learns anything, and the reason for undertaking this project is to learn things.

It would be nice to determine if a power interruption during flashing caused hardware damage, or if hardware damage even occurred, but for the time being I'd advise caution to maintain power within limits during flashing.

[walter b]

(02-03-2015 03:30 PM)John Galt Wrote:  Well, if you're going to make a mistake, make it a big one!
... As a matter of fact I'm sure I brought this misery upon myself because I decided to forego everyone else's recommendation to use the sharp point (J series) spring pins you're using. ... I used spring pins with hemispherical tips (B series) thinking they might result in less abuse. ...

It would be nice to determine if a power interruption during flashing caused hardware damage, or if hardware damage even occurred, but for the time being I'd advise caution to maintain power within limits during flashing.

Hmmh, can you elaborate a bit about what you think your mistake was? To me, you're talking in riddles although you write you're sure. And an experimental proof would be appreciated.

d:-?

[John Galt]

Walter, I do not know. I wish I did. I have only a suspicion that my mistake was permitting an interruption to Vcc during the flashing operation. I did that intentionally once before, but only once, to verify error detection and recovery in the event it were to occur unintentionally.

During that one, controlled test, a normal Erase function restored the ability to flash it again. It appears that was not to be the case this time.

Additional testing under controlled conditions may verify this suspicion, but if they do not duplicate the failure in a short amount of time a reasonably definitive conclusion may remain elusive.

Until then the only recommendation I have for others using the equipment and procedures I am using is to ensure any programming port connector ("pogo pin connector") they choose to fabricate on their own is both electrically and mechanically secure from failure as practicable.

The only similar failures I experienced in the past using flash memory (and the bootloader programming software involved - that's important!) were correlated to unreliable power or poor power regulation. None of them involved any HP products, and there were very few such failures. For certain critical systems I use triply redundant power supplies, so failure is essentially impossible.

One more quick fact to point out: the "flash box" I built and was using during the failure was both designed and intended for use by those who want an external power supply and status / Tx / Rx LEDs for whatever reason they may want those features. In the vast majority of cases in which only a firmware update is required, it is much easier and safer to use a simple connection with the calculator's own power, requiring only the external data signals supplied by whatever USB to serial device the user desires.

[MarkHaysHarris777]

(02-03-2015 04:27 PM)John Galt Wrote:  ... it is much easier and safer to use a simple connection with the calculator's own power, requiring only the external data signals supplied by whatever USB to serial device the user desires.

I tend to agree, only you still have to address the problem that the CR2032 lith cells can't hack the current drain. i thought about a 3.0v "D" cell battery pack with alligator clips (would power the 30b with flash for years!) Or, picture a balsa insert (same size as the 2032) as an adapter plug from the 3.0v "D" cell?

PS... I also agree with your statement about "large" errors... I had a choir director one time tell us to sing out (because 'large' flat notes were easier to correct).

PSS... if the device we are repurposing cost big $$$bucks, well there would be a different story to tell. The cost of the 20b|30b hardware is nominal/ outside of pride, if you brick one no real harm done.

[John Galt]

(02-03-2015 07:18 PM)MarkHaysHarris777 Wrote:  I tend to agree, only you still have to address the problem that the CR2032 lith cells can't hack the current drain.

What does that mean in engineering terms I am likely to understand?

[MarkHaysHarris777]

(02-03-2015 08:13 PM)John Galt Wrote:  

(02-03-2015 07:18 PM)MarkHaysHarris777 Wrote:  I tend to agree, only you still have to address the problem that the CR2032 lith cells can't hack the current drain.

What does that mean in engineering terms I am likely to understand?

Use the calculator's batteries to flash; tell me how long your CR2032 cells last... those things were designed for 'voltage' over time, not current. The flash process draws too much current. I wiped out a set of cells experimenting with my first PL2303HX chip. Just saying. Powering through the cable (box) is the best option, if its done right. On the other hand, maybe the best option if you're not willing to do it right, is to use the calculators batteries.

Cheers

[John Galt]

(02-04-2015 12:13 AM)MarkHaysHarris777 Wrote:  The flash process draws too much current.

How much current?

[John Galt]

I discarded one set of batteries after a few days of playing with it also. I was initially unaware that pressing Reset will power down the calculator no matter what.

Anyway, I never measured the current required during flashing. I was hoping you would do that for me but I got tired of waiting :-)

After discarding the partially depleted batteries I used the external power supply to obviate any uncertainty regarding their remaining capacity. With no firmware and the calculator "on" it will draw a consistent 8.0 mA. That quickly diminishes once the flash operation begins. I recorded average current from the bench 3.0V power supply of 5.9 mA for the 19 seconds it takes to flash the unit.

The WP 34S draws much more than that during certain operations. I measured consistent current of 20.75 mA during operation by running N-Queens. Although Eric's spreadsheet compilation does not indicate what it was running and I cannot find Marcus's post from 2011 to determine that, his records are consistent with my measurements.

Conclusion: even one onboard battery is capable of supplying more than sufficient current for flashing, provided it has at least enough capacity to supply an operable WP 34S.

[MarkHaysHarris777]

(02-04-2015 01:50 AM)John Galt Wrote:  Anyway, I never measured the current required during flashing. I was hoping you would do that for me but I got tired of waiting :-)

Alas, and I'm sorry I have not measured it either; I'm not plugging my unit back into the flash-box again until I have to-- which means I need to update the firmware to support the crystal and caps I'm planning to install (still don't have them in hand, mails are slow with the storms and all).

Well, CMOS circuits are voltage devices and draw negligible current (I'm surprised its even 5ma). Now 'flash' on the other hand is really what interested me. I'm interested in the flash cable idle current.

PS I also was not initially aware that the reset (whether on-board or flashbox) was powering down the device. It would be interesting if strobing the reset would power-on... then the whole thing could be automated. What if the flashbox were to employ an Arduino micro controller that would not only initiate and time the erase-power-on-reset sequence but also prompt the Sam-ba transfer; one button automation. I have not experimented with strobing the reset pin to see if things poweron (dont think I will either)

Cheers

[John Galt]

(02-04-2015 05:14 AM)MarkHaysHarris777 Wrote:  What if the flashbox were to employ an Arduino micro controller that would not only initiate and time the erase-power-on-reset sequence but also prompt the Sam-ba transfer; one button automation.

Power down is no problem. I believe the obstacle to automation will be powering it on.

AFAIK there is no way to do that from the programming port and meatware has to press the on button. Otherwise I'd be thrilled about automating it.

(02-04-2015 05:14 AM)MarkHaysHarris777 Wrote:  Now 'flash' on the other hand is really what interested me. I'm interested in the flash cable idle current.

I'm not sure what you mean by "idle current". While it was waiting to be flashed, it's a consistent 8 mA. That's the only way I could determine it's really "on". While flashing it was 5.9 mA.

[walter b]

(02-04-2015 05:14 AM)MarkHaysHarris777 Wrote:  I also was not initially aware that the reset (whether on-board or flashbox) was powering down the device.

RTFM! >:-(

[MarkHaysHarris777]

(02-04-2015 07:37 AM)walter b Wrote:  

(02-04-2015 05:14 AM)MarkHaysHarris777 Wrote:  I also was not initially aware that the reset (whether on-board or flashbox) was powering down the device.

RTFM! >:-(

That was before I even downloaded the FM. :-}

I have now officially RTFMCTC , thank you very much.

:-p

[rprosperi]

(02-04-2015 07:57 AM)MarkHaysHarris777 Wrote:  

(02-04-2015 07:37 AM)walter b Wrote:  RTFM! >:-(

That was before I even downloaded the FM. :-}

I have now officially RTFMCTC , thank you very much.

:-p

Aaaah. A new and useful acronym. Thanks Marcus

[jayemel]

Hi,

I have a brand new 30b that seems to have suffered a similar fate to John's during flashing with WP34s firmware.

The calculator was flashed following the normal procedure. It was powered from a lab power supply at 3.2V and flashed with a FTDI USB to UART adapter (UM232R) and MySamBa running on a Windows XP virtual machine.

Part way through flashing MySamBa reported a failure to acknowledge. I attempted to erase and reflash but MySamBa is unable to connect.

It still turns off when reset, and on when ON/CE is pressed, however, as with John's the on current draw is only ~2mA. My other 30b/WP34s draws more like ~15mA when on in bootloader mode.

It is possible that the interruption was as a result of losing power, although I think UART is more likely as the connection was precarious, or possibly an issue with using a virtual machine.

John, did you manage to recover this hardware?

Regards,
-- Josh

[John Galt]

Hi Josh,

No, I have been unable to resurrect the calculator since the failure. It occurred part way through flashing it, exactly as you described. It's in storage in the event I can ever find someone with a JTAG development system who would like to attempt to fix it, or to definitively diagnose what's wrong.

It is almost certain the damage occurred due to an interruption in power during flashing. There is little or no reason to suspect any problems using a VM, but there is every reason to believe Bernhard's explanation was in fact the cause:

(02-02-2015 09:56 PM)PANAMATIK Wrote:  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.

Since that event I have been cautious to use a "very solid" connection to the calculator's serial port. Fabricating that connector has always been the most challenging aspect of this project. If you want to avoid damaging your HP beyond repair, what I wrote earlier is essential:

(02-03-2015 03:30 PM)John Galt Wrote:  ... I'd advise caution to maintain power within limits during flashing.

[walter b]

There will be an extended warning in the manual taking care of that.

d:-)

[Marcus von Cube]

(11-03-2015 05:13 PM)jayemel Wrote:  Hi,

I have a brand new 30b that seems to have suffered a similar fate to John's during flashing with WP34s firmware.

The calculator was flashed following the normal procedure. It was powered from a lab power supply at 3.2V and flashed with a FTDI USB to UART adapter (UM232R) and MySamBa running on a Windows XP virtual machine.

Part way through flashing MySamBa reported a failure to acknowledge. I attempted to erase and reflash but MySamBa is unable to connect.

It still turns off when reset, and on when ON/CE is pressed, however, as with John's the on current draw is only ~2mA. My other 30b/WP34s draws more like ~15mA when on in bootloader mode.

It is possible that the interruption was as a result of losing power, although I think UART is more likely as the connection was precarious, or possibly an issue with using a virtual machine.

John, did you manage to recover this hardware?

Regards,
-- Josh

When MySamba is interrupted midway then the boot bit has already been set and the SAM-BA loader is no longer active. You will need to ERASE again before you can reflash.