Author Topic: Fluke 8840A Faulty CPU  (Read 2989 times)

0 Members and 1 Guest are viewing this topic.

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Fluke 8840A Faulty CPU
« on: May 21, 2019, 06:22:25 pm »
I picked up a couple of faulty 8840A’s a little while ago and have just got around to having a quick look.

Both were completely blank screens, with one doing absolutely nothing, and the other clicking a relay fairly regularly.

Focusing on the first one I did a bit of prodding around and came to the conclusion that the CPU was faulty ... a quick swap with the second CPU and it all sprang into life and looks good.

So the main CPU is a Zilog Z0861108PSC and these seem available online from China at least, but a bit of googling shows that they have a 4K write-once prom, so I’m assuming I can’t just replace it?

There are some comments about potentially reading and re-writing the prom, but I can’t find anything that makes me think anyone has been successful.

Does anyone know if this is possible? Or a source for a properly programmed one?

Thanks.

On a side note, both units came with the AC option (which was a surprise), but both of them seem to drag the power rail down and cause the blank-screen relay clicking, I’m hoping it’s as simple as a shorted tantalum, but I’ll get to that later!
 

Offline bdunham7

  • Frequent Contributor
  • **
  • Posts: 302
  • Country: us
Re: Fluke 8840A Faulty CPU
« Reply #1 on: May 21, 2019, 07:36:01 pm »
In a sane world your best source for a replacement Z8 CPU would be a parts unit.  I doubt they fail often.  However, as you may know--and I know from looking for parts for my 8842a--these go for stupid money.  A wrecked unit that looks like it fell out of one lorry only to be run over by another and was then scraped off the road by a vagrant goes for $50-75 USD here. 

I can't answer your question as to reading out and writing the PROM, but what did you test to determine the CPU was bad?  I had a similar problem with a different brand DMM and the "dead" ADC chip turned out to be an instability in the crystal oscillator, presumably caused by too high impedance of the crystal.  It is possible that I could have replaced the chip and the new one would shift things enough to start the oscillator, but it turned out simply replacing the crystal with a lower impedance "full-sized" AT cut model solved the problem entirely.  I just wonder if maybe you have something similar going on.  In my case, one the tests I did was to connect a 10M oscilloscope probe to a signal generator putting out the correct clock frequency sine wave  (8 MHz in your case) at 1V P-P or so and probing the 2 XTAL pins on the chip.  When I got the right one it started right up.  Just an idea to try.

 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #2 on: May 21, 2019, 09:01:56 pm »
Thanks for the reply ... I initially followed the troubleshooting guide looking for display related signals on the various display chips but saw nothing.

Eventually I started looking at the CPU, I could see a valid clock, but no activity on any of the data or address lines, so it wasn’t even starting to try to read memory, so I then switched it and all was fine.

It has crossed my mind that it could have been not properly making contact with the socket, so I will try it again, but I suspect it’s dead.
 

Offline ignilux

  • Supporter
  • ****
  • Posts: 29
  • Country: us
Re: Fluke 8840A Faulty CPU
« Reply #3 on: May 21, 2019, 10:12:11 pm »
I have no idea if this will help you or not, but I have an 8840A that needed some TLC before earning a permanent place on my bench. Mine would be working perfectly fine for 15 minutes or so, then the screen would go blank and sometimes a relay would click. After some time of combing the forum, I found someone who had different erratic problems (I don't have the link saved unfortunately). Turns out that it's somewhat common for the solder joints on the main transformer to be cold / incomplete / cracked. I cleaned and redid all of the pins, and it's been rock solid ever since.

I'm not saying it's your problem, but it might be worth a shot before spending some cash on a new CPU.
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #4 on: May 22, 2019, 07:09:04 am »
Thanks Ignilux, but the clicking relay issue is a separate one and that only happens when the AC module is plugged in, my guess is it's either a power supply not being up to the task (although they all check out ok) or a fault on the AC board. I do have two AC boards exhibiting exactly the same problem, but also the same problem in two different 8840A's .. so there is some investigation still to do. I will check out the transformer joints though, thanks.

The CPU issue (I think) is pretty clear cut ... absolutely nothing going on, replace the CPU and it all works. I do need to just stick the old one back just to make sure it wasn't a seating issue, but my money is definitely on a dead CPU.
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #5 on: May 22, 2019, 02:40:38 pm »
So a bit more investigation on the CPU...

The Z8611 has a 4K mask programmed ROM, so not re-programmable, so the only option using this specific device would be to grab one from an otherwise broken 8840A.

But, there are other options...

There is a Z8613 which is effectively a prototyping solution where it has a non-ROM version with a piggy-back socket for an EPROM.

There is also a 44pin version of the Z8611 which includes a ROMless pin which disables the ROM, so you could build something similar to the above.

There's the Z8681 which seems to be a romless version, so again you could build a small module that included some glue logic and an EPROM.

There is also a Z86E11 which has the EPROM built in ... although you need to jump through a few hoops to program it with a normal programmer.

Most of these seem very difficult to obtain ... the Z8681 and Z86E11 being the most available via eBay but at a bit of a premium, but still may be worth a punt. It's also not clear how easy it would be to read the contents from the original Z8611 rom to even be able to write it somewhere else.

More investigation needed...
 

Offline Paul Moir

  • Frequent Contributor
  • **
  • Posts: 872
  • Country: ca
Re: Fluke 8840A Faulty CPU
« Reply #6 on: May 22, 2019, 04:18:10 pm »
. It's also not clear how easy it would be to read the contents from the original Z8611 rom to even be able to write it somewhere else.
http://www.bitsavers.org/components/zilog/z8/1983_Z8_Microcomputer_Technical_Manual.pdf
Ch 8 pg 4 talks about the test mode which will allow you to execute your own code on an external ROM.  You can use that to read out the internal ROM.  Still a bit of work.
 

Offline bdunham7

  • Frequent Contributor
  • **
  • Posts: 302
  • Country: us
Re: Fluke 8840A Faulty CPU
« Reply #7 on: May 22, 2019, 06:33:49 pm »
So, not to hijack a thread, but I was looking around for a parts 8840a thinking the OP and I could share--I would like a VFD, handle and maybe some bits--when I ran across this unknown (to me) option.  Anyone know what it is?
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #8 on: May 22, 2019, 07:42:15 pm »
@Paul -- thanks for the info, that's useful ... sounds like quite a lot of work, but may be fun.

@bdunham7 -- one of my units has that "option" ... I'm not sure it really is an option, I think it just takes some of the power and ground lines (that would normally feed the GPIB board) out to that connector on the back ... not sure what it's for, I had assumed it was really just a glorified blanking plate.

So I've done a bit more experimenting ... the CPU was definitely dead, swapping them around gives entirely consistent results.

The fact that both the AC boards caused the relay clicking issue concerned me, so I just jumpered the 'ac sense' pin to simulate the board being installed and I got the same behaviour ... further digging showed that it's actually the watchdog reset from the A/D which triggers if there is no activity on CS7. So at this point I'm a bit confused as CS7 is driven by U208 which is obviously fine when the AC board isn't installed... and the input for U208 is directly from the CPU, so it almost feels like a firmware issue. I might try reading the EPROM to see if I get consistent results (I think the official firmware is around somewhere as well.)

The second unit has a different behaviour (when I put the good CPU in it) ... but I haven't checked power supplies or anything yet. So I'll probably want to do a bit more digging before considering breaking for parts.

EDIT: I pulled both ROMs and checked them, the first looked OK (version 2.5, checksum 0x0006 0x6c48) although I have nothing to compare it with and can only find v2.3 anywhere online. Does anyone have a v2.5 prom they could dump?

The second one was garbage. When I put the first EPROM into the second unit it was fine, but had the same issue with the AC board, which makes me think it's still a firmware issue as it's unlikely that both units (and two AC boards) have the same hardware fault ... although I only have the one 'working' CPU, so that could also be at fault.
« Last Edit: May 22, 2019, 08:10:04 pm by essele »
 

Offline xwarp

  • Frequent Contributor
  • **
  • Posts: 336
  • Country: us
Re: Fluke 8840A Faulty CPU
« Reply #9 on: May 22, 2019, 10:47:30 pm »
I believe I might have 1 or 2 8840 boards in storage. I'll try to look this weekend. If I do, I'll let you know.
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #10 on: May 23, 2019, 03:44:45 pm »
Looking at the various CPU options I'm finding it really difficult to understand how you would attach an external PROM to replace the internal one without using an extra address line ... I'm sure it's possible as I've found a few comments about it, but I just can't seem to get my head around it.

So, I'm liking the Z86E40 ... it seems to be a modern version and is reasonably priced and available (Mouser and Digikey) it has a different pinout, and a few more capabilities, but it seems to be backwards compatible from a register perspective, and it has a fairly standard method for programming once you translate the pins, therefore using it in a PLCC or LQFP format you could probably build a simple board that includes the pinout for programming and then use a normal TL866 type programmer.

I'll look at this in some more detail once I get a bit more time.
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #11 on: May 24, 2019, 05:21:43 pm »
You only seem to be able to get the PLCC or DIP40 version of the Z86E40, so I've pulled together a couple of board designs based on the PLCC44, one is the actual board that would go into the 8840A and the second is the one you'd use to program it (the schematic is mostly taken from the Z86E40 data sheet.)

They were both a real pain to route, but I think they are ok.

I'm just going to check a few things (like will it actually fit in the 8840A) and go through the data sheet in a bit more detail to make sure that it stands a chance of working.


 

Offline Kleinstein

  • Super Contributor
  • ***
  • Posts: 6303
  • Country: de
Re: Fluke 8840A Faulty CPU
« Reply #12 on: May 24, 2019, 06:54:19 pm »
For such an adapter board I would also include a decoupling capacitor close to the chip. One can still not populate it, but it can help to have the option.
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #13 on: May 25, 2019, 10:58:07 am »
Thanks Kleinstein ... I've added a decoupling cap as close to the socket as I could sensibly get it.

The boards are being made now, so hopefully I should have then in about a week.
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #14 on: May 27, 2019, 05:09:41 pm »
I've just found an old 8840A/AF which also wasn't working ... and I've learnt the hard way that the bloody newer TL866II Plus doesn't actually have the capability to burn older EPROMS requiring >18V, so I had to buy a new programmer. Grrrr.

So I now have two different "working" CPU's ... one from the second 8840A and one from the 8840A/AF.

The prom from the AF (v2.5) matched one I found online, the label EPROM sticker was floating around in the device, so I assumed it was not going to work, but it seemed fine (I've burnt a new copy anyway.)

I've also found two different v2.3 images online, including one with a matching image for the Z8.

The v2.3 images didn't work with either CPU ... but that's to be expected as I understand you need a match between Z8 firmware and the EPROM.

The 8840A/AF cpu in the first 8840A didn't work with the v2.5 original image, however it did work with the newly burnt v2.5 which matched the one actually in the 8840A/AF ... which was strange since that combination didn't work in the AF, so that's either a chip seating problem, or there is another issue with that unit (one for another day.)

So now I have one complete 8840A, with a working RMS board, and it seems to be really nicely calibrated.

The second unit now has the prior "working" CPU with the original v2.5 image and it's still showing the problem with the RMS board ... so I'm no nearer to really understanding this, it could still be the CPU or the PROM since they are paired.

And I have the 8840A/AF which is now missing a CPU and PROM.

So ... I'm now fairly dependent on my adapter and programming boards. I have the v2.3 paired versions which I'm hoping I can get onto the Z8. The boards are due to arrive on Friday, so I can see the weekend being fun ;-)

The other option is to use the 'test mode' that Paul suggested to see if I can read the image from the working CPU I have, but that's going to mean rigging up a test bed with a clock, an octal latch for the address/data demultiplex, and writing some code to read the ROM and spit it out the serial port ... sounds like a great project, but a real time burner!
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #15 on: June 01, 2019, 05:54:07 am »
Some slight progress... I’ve managed to find a disassembler for the Z8 (surprisingly hard to find a free one, finally found one as part of MAME, unidasm) and it’s really clear why the CPU code and prom code need to match ... the prom is just an extension of the CPU code, so it’s effectively a single 8K image. So even a minor difference won’t work as the location of subroutines will be different.

My boards and components arrived (very impressed with JLCPCB again, and this was my first with KiCad!) ... although the programmer doesn’t appear to work!

Just trying read I’m getting an overcurrent error if I use the TL866ii plus (set to a 13v Vpp) and if I use a GQ-4X then I get inconsistent results that aren’t all 0xFF (and it’s the same without the external 12.5v supply, so it doesn’t look like it’s latching into EPROM mode.)

I need to double check all the programming voltages and then start looking at the timings, but re-reading the data sheet has worried me as there are some errors and inconsistencies in it.

The other issue is that the Z86E40 doesn’t have a serial port (it has two comparators instead), this seems to be only used for the GPIB card, so that wouldn’t be a viable option with this solution, even if I could get it to program.
 

Offline TheDefpom

  • Frequent Contributor
  • **
  • Posts: 273
  • Country: nz
  • YouTuber Nerd
    • The Defpom's Channel
Re: Fluke 8840A Faulty CPU
« Reply #16 on: June 07, 2019, 01:05:56 am »
FYI Some time ago I received a faulty 8840A / 8842A unit and found it had the WRONG AC board in it, there is a connection difference between the two units, BUT the same AC board can indeed be used in both units, you just have to modify the interconnect wiring a little bit.

I will see if I can dig that info up for you, I did note it down somewhere for my future reference, it might have even been in one of my repair videos.
« Last Edit: June 07, 2019, 01:08:36 am by TheDefpom »
 

Offline TheDefpom

  • Frequent Contributor
  • **
  • Posts: 273
  • Country: nz
  • YouTuber Nerd
    • The Defpom's Channel
Re: Fluke 8840A Faulty CPU
« Reply #17 on: June 07, 2019, 01:07:31 am »
Here you go, I found it.


Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #18 on: June 07, 2019, 12:01:24 pm »
Thanks Defpom - that is really interesting.

That difference is very relevant since it also impacts one of the outputs of U208 which would be effectively shorted to GND when it shouldn't be, which could well be impacting CS7 and the associated watchdog.

I have got three AC boards, one of which (the one from the AF) is fairly different looking to the other two so I will check the out.

I'm assuming that pin 1 and 8 is also just swapped on the motherboard side (because of U208) so it's likely to be a pure hardware change and not a software related issue ... which doesn't explain why swapping CPU and PROM fixed it ... which probably means it's not my actual issue, but there are enough similarities that it definitely needs to be checked.

Thanks.

BTW ... I am losing the will to live with the Z86E40 ... will spend some more time this weekend, but I'm not hopeful about even being able to program it successfully.

UPDATE: I checked all three and they are all the same, the boards match the first diagram (pin 1 connected to U803 pin 11) and the motherboards all have pin 8 directly connected to the CPU. So they would all seem to be compatible. I have now given up on the Z86E40, I have decided I hate Zilog, and I'm looking at the feasibility of a radical approach! More later.
« Last Edit: June 08, 2019, 11:15:08 am by essele »
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #19 on: June 21, 2019, 08:48:17 am »
Further info on my radical approach ... I'm going to try sticking in a PSoC4 running a kind of Z8 emulator!

Initially I was considering a pure Z8 instruction emulator, however I don't think the performance will be there, the PSoC is 48MHz vs. the Z8 at 8MHz and the arm is pretty efficient, but for full emulation I don't think it's enough headroom to get close to native speed given the emulation complexity of some of the instructions that the Z8 handles in a very few clock cycles. [I'm not sure that performance is a particular issue in this case, so may be something to experiment with later.]

So option 2 is to re-spin the firmware and effectively translate it into C with probably some assembly if needed, although the compiler will probably be better at optimising than I would be.

I have written a simple disassembler in Perl ... stage 1 was to completely match the output of the MAME disassembler which is done (with the exception of the indexed LD instructions for which the datasheet is really vague and the MAME one seems to disagree with ... but thankfully it's not a problem.)

Stage 2 was to update the disassember to actually follow the code paths so that I could work out which bits of the firmware were code and which were data (which is the reason why the indexed LD isn't a problem!) -- this is also done.

The next step here is to update it again to isolate truly independent subroutines (i.e. ones that aren't jumped into by something else) so that they can be pulled out as separate functions, and then to start looking at detecting reads and writes to the control registers. The actual control registers look to be simple, RP is only set to 0xF0 in one place and is then followed by a load of RP relative code, the rest of the firmware uses a fully qualified read or write (for want of a better phrase.) So I'm working on having the disassembler identify RP relative access that can be fully qualified because no other code path gets in between the RP set and the access. The port access reads/writes are going to be a little more challenging and unfortunately some might need to be checked at run-time.

There is a minor issue in the keyboard interrupt code since this uses a jump table in the firmware, so I think this is probably going to have to be manually re-written in C, although I want to try to avoid this if I can so the code translation is as automated as possible to cope easily with different versions.

Other than that, from a software perspective, I think this is entirely doable. I would like to get my hands on other versions of the actual Z8 bit of the firmware.

Hardware wise ... I've looked at the PSoC capability of driving the "external bus" using pure software, and whilst I think it might work, it's a bit fraught, it's at the limits of the performance of the device (using direct register writes, none of this API rubbish), interrupts would probably need to be disabled for most of the time, and it just feels wrong.

I've put together a hardware bus component using verilog which is an approximation of the bus access process for both read and writes, mostly to see if it would fit within the available logic and it seems fine (with a fair amount of headroom), so it feels like that's the way to go. The good thing about the PSoC is that the same board could easily use the hardware or software option, and in fact reconfiguring the ports to not be address/data bus can be achieved through software so it would be possible to emulate that as well (although not needed for the 8840, other than a test mode I've found in the firmware.)

The clock is an interesting point ... the IMO on the PSoC isn't as accurate at the crystal in the 8840, which may or may not be a problem. My plan was to use the IMO to generate the 8MHz clock internally and output it on XTAL2 so it can be used by the ADC (leaving XTAL1 unconnected.) I'm not convinced timing is critical (it's not an integrating ADC as far as I can tell) so this may be fine. There are three other alternatives ... (1) an external crystal on the board, (2) an external WCO to trim against, or (3) use the 8840's 8MHz crystal directly ... I think I can put together a board where all of these are an option, I just need to make sure it doesn't screw up the routing as some of the clock inputs are right in the middle of a contiguous port on the device I'm considering.

Reset is another interesting consideration, if you use a normal pin for reset input you can choose to ignore the watchdog reset in the device which will simplify debugging.

So next step on the hardware is to put together a board, I think I can squeeze a TQFP64 in between the DIP40. Once I have a board then I can start debugging in a live unit.

Yes ... I know I'm mad.
 

Online coromonadalix

  • Super Contributor
  • ***
  • Posts: 2061
  • Country: ca
Re: Fluke 8840A Faulty CPU
« Reply #20 on: June 22, 2019, 06:03:07 am »
Im "mad"ly impressed by your tought process

I hope it will work for you, i would like to have this kind of knowledge,  i have a crazy idea for a new controller board ( arduino based / mega 2560 ) for an meter Ie: keithley 196 or an tektronix dm5120, the analog board is controlled by shift registers and the analog board values are read by somekind of a pwm signal ...
 

Offline fixitanonymous354

  • Contributor
  • Posts: 5
Re: Fluke 8840A Faulty CPU
« Reply #21 on: June 26, 2019, 02:39:36 am »
Hi i have recently acquired an 8842A with the Z8613RS and have dumped the 2732 roms for the CPU and IEEE board using an Enhanced Willem.
I had to use an VCC jumper fix described on the Willem forums to get the Willem to read the ROMS but the U222 ROM matches to whats available on xDevs so i think the dumps are reliable.

U202 is rom on top of main CPU
U901 is rom on the GPIB board
U222 was the same as available on xDevs
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #22 on: June 26, 2019, 09:54:48 am »
Thanks for these ... I’ll have a look at them in the next couple of days ... I believe there are quite a few differences between the 8840a and the 8842a, but I can’t see a reason why the same approach couldn’t be adopted.
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #23 on: June 28, 2019, 03:46:27 pm »
Making some progress...

First stab at a PSoC based board ... only done some very simple testing so far, it powers up, can be seen and programmed by the MiniProg3, and I can generate an 8Mhz clock, unfortunately the pins for the external crystal don't allow routing, so if the native 8840A crystal doesn't work I'm stuck with a PWM generated clock, but that all seems ok based on this first test.

Step 2 will be putting it on some breadboard with a crystal, then step 3 will be in the 8840A. Hopefully the native crystal will be fine. Not sure if I'll be able to power it from the MiniProg and leave the 8840 powered off for now, I suspect not.

Oh ... and yes, I will populate the decoupling caps - I was just keen to see if the MiniProg would see it!

UPDATE: just tried it in some breadboard with a random 8Mhz external crystal in the 8840A configuration (i.e. no caps, and 10M in parallel) works fine as a source for the PSoC, I can generate a much more accurate 1Mhz test signal from the ECO rather than the IMO, however pin 2 doesn't swing much (looks like 1V max) so I am doubtful if this will be sufficient to drive the ADC, but I'll try it over the weekend as it may be different with the particular crystal, or may well be sufficient.

FURTHER UPDATE: doesn't seem to work from the onboard crystal, it's oscillates but only at just under 1V, I can see the 8MHz signal getting to the ADC, but no sign of the 1MHz output. Programming whilst installed works fine, and a quick test of the 8MHz PWM output seems to work, I see a 1MHz output from the ADC and that reaches the keyboard/screen controller. So this should be sufficient to start working on the bus access bit in Verilog. I should be able to get a test program to read the EPROM or maybe even attempt to update the screen. I may consider a separate crystal for the next version, although I'm still not sure how important accuracy (or matching the onboard one) is.


« Last Edit: June 28, 2019, 05:53:22 pm by essele »
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #24 on: July 01, 2019, 07:05:20 am »
Well it's getting a bit exciting ... I've now got a working bus read capability, and I can read bytes from the U222 EPROM using my Verilog bus access module, this should also work for reading from the ADC, the Cal Memory, and the keyboard/display controller (assuming I've got the timing right.)

Next step is the write side of it .. testing that is going to be slightly harder, I guess I'm going to need to get the display to output something!

One slight worry at this stage ... because the XTAL2 pin (chosen because of the potential use of the external crystal) is not routable inside the PSoC then my only output option for an 8MHz clock is a PWM. This is then not synced with the UDB 8MHz clock that's used for the read/write logic ... not sure if it's really a problem, but it feels like something I should fix. I may just bodge another pin over to it for now so I can directly output a clock.
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #25 on: July 01, 2019, 01:46:54 pm »
And bus writing now also works :-) ... I can initialise and write to the display, and once I stopped testing with an 8840A that seems to have a broken display everything sprang nicely into life -- so it looks like this is really going to be possible. The timing all seems ok, at least with the keyboard and display controller and the EPROM, it may be a little more challenging with the ADC, I'm not sure if the reads and writes are clock dependent.

I love these PSoC devices .. that extra capability to do some clever stuff at the hardware level really makes a big difference. With my current implementation I'm at 63% UDB usage, but that's with zero optimisation, and there are quite a few things I could do if needed. It's looking like everything else can be done with software, so this shouldn't be required.

Now to focus on the translation of the firmware, there do seem to be a few register indirect accesses to firmware addresses presumably for lookup tables or preset data, so these will take a bit of manual effort ... the rest I'm hoping can be fully automated, and then I can worry about tidying later.
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #26 on: July 07, 2019, 09:42:06 am »
A quick update...

I've spent quite a lot of time on automated code-path discovery so I can track RP, tests-followed-by-conditional-jumps etc, all with the aim of being able to automate reasonably efficient code generation, however I'm going to have to put that on hold for a bit ... there are quite a few nasties in the code that mean I need to rethink it slightly ... things like popping an extra return address off of the stack so you don't actually return from the CALL you think you should, and pushing FLAGS so you can use an IRQ handler (and IRET) as a normal CALL.

I still think this is the best approach, but I need some time to work out how best to code it ... my current solution doesn't revisit already travelled paths, which then makes it virtually impossible to properly track stack usage.

So, instead I've built a basic CPU emulator for the Z8, which should hopefully be good enough to prove the whole principle. The basic emulator is done, I'm now working on translating the register reads/writes into PSoC related code to simulate the same behaviour, then I'll need to figure out the interrupt side of things. It wasn't until I was well into this that I discovered there is also an emulator in MAME ... that was very useful in checking my logic. The MAME one isn't really focused on speed, so I've had to approach things a little differently.

I've discovered a few things that need some work...

1. The power line frequency is determined by counting how long P20 stays low, this is a tight loop and therefore dependent on execution frequency, it would actually work for me as is (since 50Hz is the slowest), however I'll need to think about how to address this for 60Hz and 400Hz line frequencies. The simplest way would be to adjust the compares in the firmware, but it will be interesting to see how far off the performance is by default (I can do an isolated test for this) and I'm not really sure how I can test 60Hz/400Hz ... maybe I can test outside of the unit and inject a signal.

2. Timer0 is used as the baud rate generator for the UART for the GPIB board. This is only ever used at a fixed 31250 baud so that can simply be hardcoded into the UART for now. It's relatively easy to translate the prescaler values into PSoC baud rates, so I could get a bit more flexible (not sure if the 8842 uses a different rate?)

3. Timer1 is used to set the ADC sampling rate, these vary depending on line frequency and slow/med/fast speed setting. So I've added a PSoC PWM module to output the timer and can translate the prescaler/initial-value settings into PSoC friendly calls.

4. Most annoyingly it seems that the ADC reads are all done using 'extended bus timing', this is a slower version of the bus interface that adds cycles to allow for slower devices. Interestingly the datasheet says it adds two cycles to the DS phase, however the timing diagram only shows one. (Did nobody ever proof read these things? There are loads of errors!) I am going to have to revisit my Verilog component to cater for this, at the moment I don't have a free control bit to switch modes, but I have a way to work around that.

5. On the interrupts ... we have keyboard, ADC, serial-in, ADC-timer ... two aren't used - the other timer (serial baud) and serial output. Serial output appears to be polled. I don't think there are any real issues here, I just need to figure out how to translate the whole priority side of things and make sure the behaviour of the various registers is the same.

Lee.
 
The following users thanked this post: jaromir

Offline TheDefpom

  • Frequent Contributor
  • **
  • Posts: 273
  • Country: nz
  • YouTuber Nerd
    • The Defpom's Channel
Re: Fluke 8840A Faulty CPU
« Reply #27 on: July 07, 2019, 09:56:47 am »
I am genuinely impressed by your project, and I thought I was doing well decoding the ADC a few years ago in one of my first YouTube videos whilst fault checking a 8842A

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #28 on: July 07, 2019, 11:18:39 am »
Thanks DefPom ... I'm actually really enjoying this, it's a throwback to some assembly stuff I did when I was 16 (and that was a very long time ago!)

I've just done the first performance tests and things are actually looking reasonable. I've recreated the code that does the power line frequency checks, so it's pretty simple and doesn't really involve any complex instructions, so optimising further may well be a bit of a challenge. However...

As I mentioned above the code goes into a tight loop incrementing a register pair until the power line signal changes, so I'm assuming this is timing the 'off-time' of the  'freq ref' line from the power supply, so the number increases as the frequency decreases.

The firmware looks for the following (if I'm reading it correctly):

1. If it's less than 0x200, then we assume 400Hz supply.
2. If it's more than 0x470, then we assume 50Hz supply ... I assume this would actually be the 55Hz point, well that's what I would use.
3. Otherwise it's 60Hz.

Bearing in mind I'm on a 50Hz supply at the moment, I can only currently read the 50Hz value, but I've extrapolated based on that, and I get the following:

For 50Hz I get a value of 0x578, with optimise for speed, I get 0x5c8.
For 60Hz that extrapolates to 0x48e, and 0x4d1 with optimisation ... so this would miss and be assumed at 50Hz.
For 400Hz it would be 0xAF, or 0xB9 with optimisation.

So it's actually pretty close ... obviously you would want to be well inside the values to have some margin to play with, but whilst it means that this bit may not function it shows me that the emulator is actually running at a reasonable speed. I may well have to resort to cycle counting to have a better estimate of what the actual Z8 values would work out to be ... I can then look to see if I can further optimise .. but that's a job for later.

The other thing is that it proves that my external port access to port20 is working ... and that was just two lines of code!

EDIT: I'm a muppet ... I've just been trying to work out the actual cycle count and realised that actually the emulator is running faster than the original Z8 ... it's bloody obvious because my numbers are bigger than the expected ones, therefore I manage to go around the loop a few more times! That's really good news, it's much easier to slow it down ;-).

So the Z8 manages to go round this loop in 128 clock cycles (8Mhz), therefore it can do it 62500 times a second. I'm managing 70000 and 74000 depending of whether I'm optimised for speed! So it looks like I'm between 12% and 18% faster ... these are simple instructions though, I'm sure once we're in to some of the maths ones with loads of flags this won't hold.
« Last Edit: July 07, 2019, 11:43:01 am by essele »
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #29 on: July 09, 2019, 07:57:33 am »
I've now implemented the extended bus timing (but only for reads, since it's only needed for the ADC reads), the datasheet was actually correct, I was mixing clock cycles, machine cycles and the various other cycles they seems to have made up for the Z8.

I can read the 5 values from the ADC and they all come back and seem to be 6 bit values which is a good sign ... the actual values are a bit questionable, but I'm currently not reading them straight after the interrupt, so they could be a mix of samples or values mid-sample. I've got a plan for the interrupt mechanism and I'll use this as the first test.

I was looking again at the performance numbers ... actually I think I had misunderstood the performance of the Z8 and it's four times slower than I had thought...

The external clock (8MHz) is divided by 2 to give you the internal clock (obviously now 4Mhz), then the instruction 'cycle counts' seem to be "timing states" which pretty much seem to take 2 clock cycles each anyway (although some of the timing diagrams show it as 3.) So that actually means that an instruction taking 10 cycles on the Z8 is really 40 cycles at 8Mhz, which then gives us 240 cycles on the 48Mhz ARM to emulate the same behaviour.

This is born out by the tight loop for power line frequency detecting ... that was a 32 'cycle' loop (INCW, TM, JR), but actually working it through assuming I was right about my 55Hz cut-off we had 62500 iterations per second, which equates to 128 cycles at 8Mhz per iteration, so for 32 'cycles' on the Z8 that means it's effectively divide-by-4. So it's really a 2MHz CPU.

I've figured out a nice way of handling interrupts that doesn't require me to check something each cycle, and I think I've worked out how to map the various interrupt request, mask, and status lines.

I still need to work out how to deal with the Z8 reset line ... it's a normal GPIO for the PSoC, but since there's the potential for getting stuck with interrupts disabled I don't really want to handle it as a normal IRQ ... I think the watchdog reset might have potential here. I will also experiment with using another pin wired directly to the PSoC reset line, that way taking that pin low should reset the device, I can then optionally internally connect that pin to the Z8 reset line to give a configurable reset (experiments to follow -- not sure how often this is actually used during normal operation, presumably it's just an error condition.)

So next steps...

1. Interrupt mechanism + mapping interrupt registers.
2. Finish off the port configuration registers (inc. serial and timer configs.)
3. A debug exception mechanism for handling illegal instructions and register configs I don't deal with (external stack for example.)
4. Mechanism for timing instructions to see how close to the Z8 we can get.

Then I should be on to actual firmware testing -- exciting.

If it works then I think it will be worth building a board to try to extract the internal firmware from the Z8 so that we can get at the different versions, I only have v2.3 for the 8840, and I've got a working Z8 and EPROM that seems to be v2.5 that I'd love to extract.
 

Offline jaromir

  • Supporter
  • ****
  • Posts: 242
  • Country: sk
Re: Fluke 8840A Faulty CPU
« Reply #30 on: July 09, 2019, 09:13:59 am »
Great work. I'm really impressed by your progress so far.
Is there a chance you could release your work to public? I'm pretty sure that apart from being useful to folks with broken meters, it could also serve as source of knowledge to those ones being interested in how things work.
My hobby projects: https://hackaday.io/jaromir ----------- http://jaromir.xf.cz/
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #31 on: July 09, 2019, 11:14:52 am »
Hi Jaromir,

Absolutely -- I fully intend to release this all once I get it working. I'm starting to put things into github, and I'll switch it to public once it's in a usable state.

Lee.

 
The following users thanked this post: zucca, jaromir

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #32 on: July 13, 2019, 05:36:52 pm »
Huge Progress...

- Implemented an interrupt mechanism (although more on this later)
- Finished off the port control stuff, and all the register read/write translation
- Added a debug mechanism to trap some stuff that shouldn't happen
- Fixed decrement-and-jump-if-not-zero instruction so it wan't increment-and-jump-if-zero (I must have been having a bad day)
- Fixed a few other instruction issues
- Banged my head against a brick wall for quite a while

... and ...

It works ...  mostly. It boots up, will accurately read DCV, DCA and Ohms, autorange works, front/rear selection works, it detects the lack of AC board (haven't tried that yet), the self tests will run (and pass) ... the calibration looks ok, so I suspect it's properly reading the existing cal ram.

How pleased am I!!!

There's still some work to do ... to get this far I've had to do some stuff in the interrupt handling that I shouldn't really have done, so I need to understand that a bit more, also some of the small buttons on the right cause an exception where it's trying to execute code at an address that doesn't exist. Then there's the serial stuff to check for the GPIB card.

I don't think the interrupts are working properly ... I don't see any timer interrupts at all, although that doesn't stop the basic functionality, the rate button doesn't do anything at the moment, so I suspect it might be related, and the execution of dodgy code does highlight I've got something else wrong somewhere, so once I find that other things may start working ok.

QUICK UPDATE:  I've fixed the bad code issue (was a mistake in the register-pair call code) so now all of the small buttons seem to work, I can change the rate, selected external trigger etc.

« Last Edit: July 13, 2019, 06:32:58 pm by essele »
 

Offline TheDefpom

  • Frequent Contributor
  • **
  • Posts: 273
  • Country: nz
  • YouTuber Nerd
    • The Defpom's Channel
Re: Fluke 8840A Faulty CPU
« Reply #33 on: July 13, 2019, 07:42:08 pm »
nice work, well done.
 
The following users thanked this post: wasyoungonce

Online Johnny10

  • Frequent Contributor
  • **
  • Posts: 659
  • Country: us
Re: Fluke 8840A Faulty CPU
« Reply #34 on: July 13, 2019, 10:13:02 pm »
Essele your talents are showing!
Tek TDS7104, DMM4050, HP 3561A, Tek 2465A, HP8903B, DSA602A, Tek 7854, 7834, HP3457A, Tek 575, 576, 577 Curve Tracers, Datron 4000, Datron 4000A, Fluke 181 Nanovoltmeter, Dos4Ever uTracer, HP5335A, EIP534B 20GHz Frequency Counter, TrueTime Rubidium, Sencore LC102, Tek TG506, TG501, SG503, 1062LS101
 

Online coromonadalix

  • Super Contributor
  • ***
  • Posts: 2061
  • Country: ca
Re: Fluke 8840A Faulty CPU
« Reply #35 on: July 14, 2019, 01:12:08 am »
Wow  im totally impressed by your work  :-+
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #36 on: July 14, 2019, 11:07:25 am »
Thanks for the compliments! I am feeling quite pleased with myself.

Anyway ... I've reworked the interrupt code and it seems a lot better, all of the buttons are more responsive than they were. I've tested the AC board and that all works perfectly ... which is good, because that's partly where this all started ;-)

I've done some side-by-side testing with a standard Z8 based unit and I can't see any difference.

Just the GPIB board (and hence the serial connectivity) to test now ... I need to get my USB GPIB adapter working on a bit of normal kit first so I know what good looks like. Oh, and I still should probably do something with the reset input.

If anyone feels like donating an 8842 with a faulty CPU , I'd love to get that working as well ... it may just work (with appropriate firmware) but there may be features it uses that I haven't implemented. (Just make sure the screen is ok, I wasted quite a few hours on an 8840 that turned out to have a broken VFD.)
 

Online coromonadalix

  • Super Contributor
  • ***
  • Posts: 2061
  • Country: ca
Re: Fluke 8840A Faulty CPU
« Reply #37 on: July 14, 2019, 01:23:44 pm »
If your substitue cpu work,  can you add an serial port instead of the gpib ?? or an usb "rs232" port too ??

Maybe a mix of this project ??
https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/

thks


Would be nice to have a 8842 donnor ...
« Last Edit: July 14, 2019, 01:26:02 pm by coromonadalix »
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #38 on: July 15, 2019, 07:35:19 am »
Hi Coromonadalix,

The CPU communicates with the GPIB card using some kind of serial protocol, so there's no reason I can see why you couldn't develop a different card that provides an external serial or USB port if you wanted to. You would just need to reverse engineer the protocol which I imagine could be done fairly easily by sending individual GPIB commands and then tracking what internal serial comms happens.

You could also hack the firmware to send/receive serial data straight out of the unit, or you could add extra routines in the PSoC to so something similar, but either way that would require a lot more firmware understanding to know where to pull the data from and how to trigger state changes. It's definitely doable, but not something I'm planning on looking at.

The other interesting thing that could be done is to build a completely different interface to the display, this display output code is really easily found in the firmware and could actually be trapped quite simply in the PSoC (it's just writes to the keyboard/display controller) ... so creating something that would drive an LCD for example would be reasonably straightforward. Since I have a machine with a broken VFD I might consider this once I've got everything else working.
 

Online coromonadalix

  • Super Contributor
  • ***
  • Posts: 2061
  • Country: ca
Re: Fluke 8840A Faulty CPU
« Reply #39 on: July 15, 2019, 10:34:22 am »
Hi  essele

You have some 3.2" oled  who where used to convert an hp34401a vfd ...   made by qu1ck

https://www.eevblog.com/forum/repair/hp-34401a-dmm-with-leaking-segments/msg1572961/#msg1572961
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #40 on: July 18, 2019, 07:49:22 am »
Further quick update...

I've been working on the GPIB side of things ... spent quite a bit of time trying to understand why I wasn't seeing any serial response from the card at the PSoC, despite being able to see the data at the card ... turned out to be an almost invisible solder bridge between the serial-in pin and GND.  It's amazing the things that burn hours!

I've done some further work on the serial emulation and there is some progress, but it's not quite right yet.

The card is detected, and I can press the local button and I get presented with the GPIB address, so there is a level of working comms. However I see some spurious behaviour which looks like the unit is responding to random/corrupted commands (although it appears repeatable on each power cycle) ... my guess at this point is either reception problems due to framing/baud mismatches, or problems with IRQ handling.

Timing looks ok on the scope, and matches the timing diagrams in the manual.

The job for the weekend will be to add some framing/overflow/underrun detection to rule that in or out, and then to re-think the way I'm doing serial interrupt handling. Fingers crossed this will all be done in the next few days.
 

Offline jaromir

  • Supporter
  • ****
  • Posts: 242
  • Country: sk
Re: Fluke 8840A Faulty CPU
« Reply #41 on: July 19, 2019, 07:58:41 am »
Great job, great post! Keep them coming, please.
My hobby projects: https://hackaday.io/jaromir ----------- http://jaromir.xf.cz/
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #42 on: July 21, 2019, 11:20:42 am »
More battling with the serial side ... I've checked the GPIB board in a standard 8840 and it works fine, I've check the PSoC CPU in the working 8840 and that behaves exactly the same way, so I've eliminated any issues with the board or other parts of the 8840.

I was slightly worried about the timing accuracy (as per comments way back), so I tried a few different ways of generating the clock, but with no difference to behaviour, even with quite a major variation in frequency, so it doesn't seem to be that.

I've now got a protocol analyser (Analog Discovery) hooked up and I've looked at the serial rx/tx lines for both the working unit and the PSoC based one from power up ... an example of a small section (where there is a difference) is shown in the photo, the top sequence is the working one.



The data is pretty much identical, but what changes quite dramatically is the timing. I did implement one fix which actually slows down multiple byte transmissions, because the PSoC was much quicker, but that didn't change anything.

So I think there are a couple of avenues to still explore:

1. The strange lack of timer IRQ's ... there is a full ISR in the firmware but I never get a valid IRQ trigger for it. I need to recheck this, since it's doesn't feel right to me. I'm not convinced it's this problem though since that would more likely result in a lack of something happening, rather than something happening too quickly.
2. IRQ handling again (although I have redone this a few times now), but it could be a prioritisation thing where I'm allowing the receive IRQ when I shouldn't be, or a window with enabled interrupts that shouldn't be there. Again I don't think that's the case, but I will go through it again.

This has been a really interesting journey into lots of different things ... but I do want it to end soon ;-)
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #43 on: July 23, 2019, 09:02:53 am »
I'm not sure I'm making much progress on this.

I've reworked the IRQ system yet again ... and I see exactly the same behaviour whichever way I implement them, so I'm fairly sure that the overall mechanism isn't contributing to the problem.

The timer ISR looks to be fine ... my interpretation of the code is that the ADC irq drops through into the timer ISR when needed (which makes sense given it's the timer that triggers the ADC), so the timer ISR is only likely to be called as an interrupt in specific circumstances, perhaps when external triggers are used?

I have three things to follow-up on now:

1. The two pin based IRQ's (ADC and Keyboard) have slightly different behaviour to the Z8 version because they share an interrupt on the PSoC, so I'll rework them to use DSI routing and individual interrupts. I really don't think this is the issue.

2. The serial system is slightly different because of the FIFO and the way you clear the IRQ, so I'm actually considering building a UART (at least the RX side) in the digital logic to more closely resemble the Z8 version. Again I don't think this is the issue as I think I understand the way the code interacts and I can't see how it would cause a problem.

3. The other option is that I still have a misbehaving instruction which is only used (or only a problem) in the serial code. So I'll go through the implementation again checking everything, but it does work for short period of time, which makes it feel more like a timing/IRQ issue than an instruction problem.

EDIT:  And potentially there is: 4. From re-reading the Z8 manual it seems that the interrupt mask register can't be updated unless the DI instruction has been used to disable interrupts, you can't simply write a 0 to bit 7, my implementation doesn't enforce that. Then the manual isn't clear if writing a 1 to bit 7 is ok to enable, or you have to use EI. There is a chance the firmware relies on these controls, so that's a fairly easy combination of things to test as well.

Lee.
« Last Edit: July 23, 2019, 10:43:21 am by essele »
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #44 on: July 25, 2019, 09:38:32 pm »
So I’ve implemented independent IRQs for the keyboard and ADC, no major change in behaviour, but it feels better as it’s more closely aligned to the Z8 approach.

I’ve built a UART, well actually a UAR, in Verilog ... surprisingly easy if you skip most of the error conditions ... and it seems to work ok and more closely mirrors the Z8 approach. Again no significant change. (As an aside, I never thought i’d be building UARTs in Verilog ... how cool is that???)

I’ve also rechecked all the instructions, put a load more debug in to check for strange things, and tried all the variations of EI and DI control, and nothing seems to impact the behaviour.

However ... it’s now very consistent and repeatable, so I think some of these changes have helped resolve issues.

I have then also started looking at the timer implementation since I was a bit too quick to dismiss some of the intricacies ... I’ve redone this with a proper down-counter with correct behaviour at re-load (which took some more Verilog and a reversion to the old UART for space reasons for now.)

The upshot is that I now have a rock solid external trigger (with GPIB board) setup, but there are still challenges with local trigger if the GPIB board is connected ... I’m fairly sure it’s timer related, so some more work is needed - but it’s time for a weekend of well earned gin.

Lee.

BTW - I’m intending to publish the git repository on Tuesday, maybe others can help get this over the line.
 

Offline essele

  • Regular Contributor
  • *
  • Posts: 156
  • Country: gb
Re: Fluke 8840A Faulty CPU
« Reply #45 on: July 30, 2019, 05:02:05 pm »
Ok .. I've had enough for a while on this, I just can't get over this last issue.

I've even implemented a more efficient serial receiver using a datapath component so that I can fit it all in to the programmable logic, but no change in behaviour, so I think the serial side is actually a red herring (especially given the external trigger, which is over serial, seems to work perfectly.).

For the time being I've just dumped all of the code, schematic, and pcb stuff into GitHub ... I haven't tidied it much, so there are lots of remnants of debugging in there and still quite a few things to tidy.

https://github.com/essele/Fluke_Z8_Emulator

If anyone feels like getting stuck in then please let me know.
 
The following users thanked this post: lowimpedance, edavid, jaromir

Offline SilverSolder

  • Frequent Contributor
  • **
  • Posts: 759
  • Country: 00
Re: Fluke 8840A Faulty CPU
« Reply #46 on: July 31, 2019, 12:28:40 pm »
I noticed this sticker on your meter:




 :-DD
 

Online coromonadalix

  • Super Contributor
  • ***
  • Posts: 2061
  • Country: ca
Re: Fluke 8840A Faulty CPU
« Reply #47 on: July 31, 2019, 07:03:52 pm »
yep  broken sticker  loll

Keep up the good work,  hope you find the little buggar ..
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf