Electronics > Repair
Fluke 8840A Faulty CPU
essele:
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.
jaromir:
Great job, great post! Keep them coming, please.
essele:
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 ;-)
essele:
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.
essele:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version