Threaded Mode | Linear Mode

Massimo Gnerucci · 12-21-2017, 08:45 PM

(12-21-2017 04:21 PM)Helix Wrote: I have pushed the faulty keys alternatively towards the top and towards the bottom of the PCB, with the hope to produce some lateral movement underneath that would remove some dust or some other imperfection.
I have also introduced the tip of an extremely fine knife, between the side of the white key and its mount, here again alternatively on the upper side and the lower side of the key. I am pleased to report that the defective keys on my two NP-25 work now as expected.
Maybe this can solve some NP-41 key problems.

Actually after wiggling around the "9" key inside its shell seems to have improved its responsiveness quite a bit.
Thank you, Jean-Charles!

Guenter Schink · 12-21-2017, 09:00 PM

(12-21-2017 01:50 PM)Chris Chung Wrote: So if you want to reverse the purchase, please let me know and I will provide a refund to you.

Hi Chris.
thanks for the offer. No I'm not going to reverse my order. I'm well aware that those "home brew" systems may show difficulties. I'm glad that you strive to get everything resolved.
BTW your explanation of the key tests was very helpful. So what I saw, in addition to the frozen ATAN etc., was expected behaviour, thus no additional problem.

As previously stated I'm not in a hurry, so please take your time as necessary to test and relax Smile

Günter

Massimo Gnerucci · 12-21-2017, 10:01 PM

(12-21-2017 01:50 PM)Chris Chung Wrote: I am also looking at the ROM modules. I have only the Math-1C.bin and the PHYSICS.bin to play w/. If you know other ROM sources, please let me know a few so that I can try more as well.

I updated the firmware and all is fine. Wiggling the "9" key rendered it more responsive, so I'm quite delighted by my new toy.
I then tried to load Extended functions and CCD-OSX modules, but the unit became shaky and I had to clear again all ROM pages.
Oh well: I have a 41CV clone for now. Waiting to be able to load ROMs...

As always: thank you Chris!

Massimo Gnerucci · 12-21-2017, 10:17 PM

(12-21-2017 10:01 PM)Massimo Gnerucci Wrote: I updated the firmware and all is fine. Wiggling the "9" key rendered it more responsive, so I'm quite delighted by my new toy.
I then tried to load Extended functions and CCD-OSX modules, but the unit became shaky and I had to clear again all ROM pages.
Oh well: I have a 41CV clone for now. Waiting to be able to load ROMs...

Ok, uploaded Ext-Func module!
I will try different combinations in the next days.

**rprosperi** · 12-21-2017, 10:29 PM

(12-21-2017 10:01 PM)Massimo Gnerucci Wrote: I then tried to load Extended functions and CCD-OSX modules, but the unit became shaky and I had to clear again all ROM pages.

The current CCD-OSX requires LIB4, which likely can't be loaded here.

Or are you using an older, non-LIB4 version, and if so, which one? I feel like a 41 is crippled without having OSX installed.

**rprosperi** · 12-21-2017, 10:31 PM

(12-21-2017 10:17 PM)Massimo Gnerucci Wrote: Ok, uploaded Ext-Func module!
I will try different combinations in the next days.

Does the NP-41 have RAM in the right address range to emulate Extended Memory? Can you do EMDIR?

Massimo Gnerucci · 12-21-2017, 10:44 PM

(12-21-2017 10:29 PM)rprosperi Wrote:
(12-21-2017 10:01 PM)Massimo Gnerucci Wrote: I then tried to load Extended functions and CCD-OSX modules, but the unit became shaky and I had to clear again all ROM pages.

The current CCD-OSX requires LIB4, which likely can't be loaded here.

Or are you using an older, non-LIB4 version, and if so, which one? I feel like a 41 is crippled without having OSX installed.

Yes, older image w/o LIB4, from a 2010 Clonix collection.

Massimo Gnerucci · 12-21-2017, 10:45 PM

(12-21-2017 10:31 PM)rprosperi Wrote:
(12-21-2017 10:17 PM)Massimo Gnerucci Wrote: Ok, uploaded Ext-Func module!
I will try different combinations in the next days.

Does the NP-41 have RAM in the right address range to emulate Extended Memory? Can you do EMDIR?

Can surely do it: no "DIR EMPTY" msg, just 124 in X...

**rprosperi** · 12-21-2017, 11:21 PM

(12-21-2017 10:44 PM)Massimo Gnerucci Wrote: Yes, older image w/o LIB4, from a 2010 Clonix collection.

Please send that on over (email) when you have free time. No rush, I'm still awaiting delivery of my USB/TTL serial adapter and jumper pins from China.

(12-21-2017 10:45 PM)Massimo Gnerucci Wrote: Can surely do it (EMDIR): no "DIR EMPTY" msg, just 124 in X...

And you can successfully SAVEP/GETP programs to/from X-MEM? If so, that's cool, but unexpected.

Egan Ford · 12-22-2017, 02:15 AM

(12-21-2017 04:17 AM)Chris Chung Wrote:
(12-20-2017 10:41 PM)Egan Ford Wrote: Update. My unit will no longer power up. Cable or battery. Or at least the display is blank. Is there a reset? Thanks.

Egan, may try to reinsert battery, and press X key if display is blank. If the charge pump failed, the X key in key test mode will toggle charge pump on and off. Toggle off charge pump makes the unit to use Vcc for LCD biasing.

Tried. Didn't work. Any other ideas? Thanks.

Chris Chung · 12-22-2017, 01:46 PM

(12-22-2017 02:15 AM)Egan Ford Wrote:
(12-21-2017 04:17 AM)Chris Chung Wrote: Egan, may try to reinsert battery, and press X key if display is blank. If the charge pump failed, the X key in key test mode will toggle charge pump on and off. Toggle off charge pump makes the unit to use Vcc for LCD biasing.

Tried. Didn't work. Any other ideas? Thanks.

Hi Egan,

Only other thing you can try is to bootload firmware, although I think it's more of hardware issues based on the fact that the cold-start screen also does not show. If you have USB-Serial please try new firmware. Otherwise I can only do a refund or a replacement unit.

For a replacement unit, there will be a longer wait. For the new 2 units I assembled (Dec 12 and 18th) one of them already failed and I had to re-flow the chip to fix it. And It now got a problem which one of the 1st match had. I.e. locked up / freeze at MEMORY RESET, which is due to FRAM corruption. I had bootload firmware again to make it work. But this is not acceptable. I had some clues now but no solution. For some reason the internal Vcc voltage measured is way less than my multimeter tells me. I.e. 2.88V vs 2.05V on battery. This somehow leads to FRAM corruption. My good unit have the internal Vcc voltage close to the real voltage. I suspect some of the units failing have the same symptom. A temporary fix would be to bootload firmware again. This has to be investigated.

I may not be able to deliver good units in 1 / 2 weeks, as if they are not reliable, it benefits no one except the postman. Even the working order units may fail sometime. Please let me know if you are able to wait longer for a replacement (say 5-6 weeks) or you want to have a refund.

I am ordering (hopefully today) new PCBs which should help the current problem. After studying design notes and such. I am moving the charge pump capacitor close to the chip and add ground plates around it. On the top side, the PCB will have a lot of ground plates to help w/ noise. Also reduce optional component to reduce trace (say bias resistors for external contrast control). We will see if this can eliminate the stability problem. Also working on firmware for FRAM protection and problem detection.

Egan Ford · 12-22-2017, 05:51 PM

(12-22-2017 01:46 PM)Chris Chung Wrote: Please let me know if you are able to wait longer for a replacement (say 5-6 weeks) or you want to have a refund.

I can wait. Even months is fine. No rush here. No pressure. Send me a message with next steps whenever you are ready. I'll keep trying other ideas.

Thanks.

Massimo Gnerucci · 12-22-2017, 06:50 PM

(12-21-2017 11:21 PM)rprosperi Wrote:
(12-21-2017 10:44 PM)Massimo Gnerucci Wrote: Yes, older image w/o LIB4, from a 2010 Clonix collection.
Please send that on over (email) when you have free time. No rush, I'm still awaiting delivery of my USB/TTL serial adapter and jumper pins from China.

(12-21-2017 10:45 PM)Massimo Gnerucci Wrote: Can surely do it (EMDIR): no "DIR EMPTY" msg, just 124 in X...

And you can successfully SAVEP/GETP programs to/from X-MEM? If so, that's cool, but unexpected.

SAVEP doesn't return an error, GETP yes: FL NOT FOUND.
Of course no X-MEM available, so...
But I was interested in X-FUNCS.

mwthomasjr · 12-27-2017, 08:34 PM

(12-14-2017 01:18 PM)Chris Chung Wrote:
(12-14-2017 12:42 PM)mwthomasjr Wrote: I will send my unit back to the return address on the package as soon as I can, hopefully today or tomorrow.
Hi Milton,

Just send them back when you got a chance, no need to rush.

I have spare boards and had ordered the microcontrollers (just take 1 or 2 days to get them). I am lacking only the piezo buzzers (only 2 left) and it will take 3 or 4 weeks from ebay China seller. I can produce more replacement units.

Chris,

The second device works great. I have not tried anything with the serial port yet, but otherwise it looks good. The first device is en route back to you as of today (12/27).

Thanks,

Milton

Chris Chung · 12-28-2017, 02:25 PM

(12-27-2017 08:34 PM)mwthomasjr Wrote: The second device works great. I have not tried anything with the serial port yet, but otherwise it looks good. The first device is en route back to you as of today (12/27).

Thanks,

Milton

Thanks. I actually fixed (kind of) Sylvain's faulty unit. It was a hardware issue. With fresh battery the chip measured 2.2V. I used hot gun to remove the chip, clean the pad and re-solder the chip. And have to burn the firmware again to revive it. The memories were corrupted. Unfortunately it only worked for another day. The pad / traces took too much heat and became not reliable to use, I am abandoning it and used it for parts / tests only.

I got 10 new PCBs coming in (snail pace from Hongkong). These are with a lot of ground planes which I ignored to put in on the older PCB designs. With the intermittent H/W issues, I tend to think that it's my soldering skill, plus the poorly designed PCBs, which makes the units less tolerating. And tend to fail when the soldering is less ideal. I will have to try these boards and report later.

The two 2nd-batch units (one failed and fixed) are working well. I put much more time (say 20 min more intense testing / day, plus 5+ times a day just turn-on-off, run program) on them. Also writing special firmware to do burn-ins. If they are reliable enough, they could be the replacement units for the other 2 failed units.

Chris Chung · 01-10-2018, 01:53 PM

An update on the current NP-41 status

New batch of PCB had left Hongkong and not yet arrive. May be a few more days.
The 2 second batch units built earlier are running well w/o issues.
1 recovered unit (Sylvain's) repaired after reflowing the MCU, but PCB now have burnt tracks, so goes to parts department.
Another recovered unit (Milton's) actually just need to reload the firmware.
I had discovered the main reason on how the 1st batch units failed when reaching my customers. Did not exactly find out why and am working on a solution.
There are risks to other working 1st batch units that they may fail.

Dumping all the memory from Milton's faulty unit I compared it w/ the original firmware image. There are isolated spots (3 word size memory locations) got overwritten by a same word of 0xF81A. They are on the code area and depending on the runtime situation, it could cause a freeze or a reboot.

I had since studied related datasheets and other technical documentation regarding this chip and still cannot understand how this could happen.

I then accidentally "bricked" my test unit. I.e. for some reason it could not reach the emulation mode (i.e. cannot get to MEMORY LOST w/ the ON + <- sequence). And I dumped the memory and found that the same memory corruption w/ the same overwriting 0xF81A word.

The thing I was doing was snapping the battery on and off, which I did quite a bit during testing. It is the intermittent power applying to the unit that is causing the memory corruption.

I can now reliably brick the unit by holding the battery against the housing and rub around it (to apply power intermittently) and this will cause the memory corruption.

I had tried to debug the code, had introduced memory locking (deny write permission on code areas), install interrupt triggers, etc. And still the problem exists.

I finally tried removing the bootloader and the problem went away. So it was the introduction of the bootloader that had somehow caused this issue.

Tracking back on the delivery, all the 10 units were sitting on my bench for 6+ months (built in April and May) and back then, they do not have the bootloader. My other 2 test units were used for active development, including the newish ROM loading and bootloader.

When I decided to sell the units, I updated the firmware on all the 10 units (w/o removing battery) so they all have the bootloader. I continue to test them for a week or so without problem (again w/o removing battery). It is when it's time to ship that I remove all the battery and put them into the boxes. As postage does not allow shipping overseas lithium batteries.

When customer's received the units, they would insert a fresh battery. And if as such the insert was not done in a swift way (w/ some jiggling into the housing), there is a high chance to cause memory corruption, which I can now reliably reproduce. I would suspect that many failed units failed this way.

I am trying to understand why the bootloader is causing this problem. Looking at how the bootloader operates differently than a normal firmware. This bootloader is a custom made one, as the on-chip factory bootloader requires a lot of extra circuitry. I had used the many year old trick of replacing the reset interrupt pointer to point to my bootloader 1st, so that bootloader takes control when unit powers up, and bootloader will check if the USER key is on-hold, and release control / branch to original firmware only if the USER key is not pressed. The bootloader is small (<256 bytes) and designed to be that way. It resides very high in the memory (to avoid overwriting itself). It skipped a lot of general initialization like most peripheral initializaton, stack setup and other memory initialization. I will be looking into these areas / differences to find out how it causes the memory corruption. It is possible that this occurs when power was interrupted when the MCU is in the bootloader and not yet reach the general setup code segment.

First batch units cautions

In the meantime, first batch owners should use caution to replace the batteries. You need to do it swiftly when both removing and inserting a battery. Since there is no physical power switch, any jiggling when replace battery may cause the memory corruption. I think placing a plastic slip / tape underneath the cell when inserting and pull it out after inserted might help.

When using serial interface, leave battery in-place, and not to connect the V+ power from the USB dongle. This will avoid power resets to the unit. Power resets does not cause problem, it's the jiggling of power that will cause problem.

There is also a chance to brick the unit during a bootloader firmware update. It is caused by the fact the the reset interrupt vector is only replaced at the end of the firmware update. So during a firmware update (takes about 25 seconds) if the unit got interrupted, you will lost the bootloader.
burning a wrong image will not, so if you found out during download you forgot to set binary mode, or you had selected a wrong image, leave it alone and finish the download.

I will provide the next firmware w/ the bootloader vector in the beginning of the image so as to reduce the chance of this would be incident.

I will provide update when additional progress is made.

+Guenter, +Egan,

The two 2nd batch units are running good and I have confident that they will behave well once the bootloader issue can be resolved. Still I will compare them with new PCBs when they come in.

I will update you w/ our options when I get a solution to the memory corruption issue, which shouldn't take long. (or at least have a good work around on it).

Also other owners, if your unit fails on you please don't hesitate and let me know. You have a 1 year warranty on them.

cheers.

Guenter Schink · 01-10-2018, 11:31 PM

(01-10-2018 01:53 PM)Chris Chung Wrote: +Guenter, +Egan,

The two 2nd batch units are running good and I have confident that they will behave well once the bootloader issue can be resolved. Still I will compare them with new PCBs when they come in.

I will update you w/ our options when I get a solution to the memory corruption issue, which shouldn't take long. (or at least have a good work around on it).

Thanks for the update. As said before, take your time, no need to rush.

Günter

everettr · 01-10-2018, 11:36 PM

Have you considered a capacitor across the battery as a low-pass filter?

Massimo Gnerucci · 01-11-2018, 07:41 AM

I seem to have issues only when I load ROMs: I can usually list one ROM's content fine via CATALOG, but functions, if invoked, aren't executed or, if I load more than one ROM, I can see gibberish interspersed in CATALOG listing.

I need experimenting more.

Chris Chung · 01-11-2018, 03:38 PM

(01-10-2018 11:31 PM)Guenter Schink Wrote: Thanks for the update. As said before, take your time, no need to rush.
Günter

Thanks for your patience.

(01-10-2018 11:36 PM)everettr Wrote: Have you considered a capacitor across the battery as a low-pass filter?

On the PCB, I had 4 pads that I can place low-pass filters, currently I only placed one 100nF. I had been experimenting w/ placing all 4 caps, also w/ some higher values. They really don't make a difference in my testing. After reading / researching on the topic, I am more inclined to think that ground planes are more important as the unit operates on battery only, and I will find out when the new PCBs arrives. I read that w/ increase MCU activity (and speed), the rapid switching on the traces will cause interference, and we do have that happening on key scanning and LCD multiplexing.

Examining the evidence, it is appearing that the bootloader induced memory corruption problem is the main concern. I had very reliably brick a unit just by jiggling the battery on its housing.

The H/W problem is mainly due to workmanship and quality / design of PCB, I think. Both are improving and longer burn-on tests should help.

(01-11-2018 07:41 AM)Massimo Gnerucci Wrote: I seem to have issues only when I load ROMs: I can usually list one ROM's content fine via CATALOG, but functions, if invoked, aren't executed or, if I load more than one ROM, I can see gibberish interspersed in CATALOG listing.

I need experimenting more.

Yes, this is known to me. And I will spend time to work on it. I don't really quite understand the underlying mechanism other than what I learnt from Eric's code. Will ask the forums help when doing that. The TONE command also does not produce proper frequency, etc. There are many improvements to be made.

Also the next firmware I had added an option to fix the display update logic. Currently I skip some display update calls to save time. There is a lot of segment mapping calculation in the emulator when display need to be updated. I guess in original HP-41C it is partially done in H/W logic so it is fast. The new firmware will allow for full display update and the unit will run slower. But when you do CAT 0,1,2 you will be able to catch the names properly w/o sometimes some names appear on the right.

Please do more experimenting. Just beware of the battery replacing issue. Also let me know what kind of improvements is needed.

In your last few messages, you mentioned some memory problem / finding. I don't understand them but I like to learn (after we fixed the bootloader issue) and work on them. I am really not familiar w/ the HP-41C and only start to write small / simple programs with it.