EEC-IV and EEC-V Hardware Notes/talk

[jsa]

Here's a snippet of AICE code, reading data via SFR 17 & 15

Code: Select all

     # JNB   from L02685 DATA = 0                                                  Sub02635
0268a: af,f0,02,4c        ldzbw R4c,[Rf0+2]      FGTMP2L = AICE_VERS;
0268e: 08,01,4c           shrw  R4c,1            FGTMP2L >>= 1;

     # JNE   loop from L026AA                                                      Sub02635
02691: b3,4d,d6,91,4e     ldb   R4e,[R4c+91d6]   FGTMP3L = [FGTMP2L+AICES_RD_DIG];
02696: c4,15,4e           stb   R4e,R15          LSSO_A = FGTMP3L;
02699: b1,07,48           ldb   R48,7            FGTMP0L = 7;

     # DJNZ  loop from L0269C                                                      Sub02635
0269c: e0,48,fd           djnz  R48,0269c        FGTMP0L--;
                                                 if (FGTMP0L != 0) goto 0269c;
0269f: b0,17,48           ldb   R48,R17          FGTMP0L = LSSI_B;
026a2: b0,15,4e           ldb   R4e,R15          FGTMP3L = LSSI_A;

8065 Watchdog single and multibank

Code: Select all

2084: 17,05               incb  R5               Watch_Dog_Tmr++;

     # DJNZ  from L0253A                                                           Sfg0252B_Sftwr1_Int
02556: 17,05              incb  R5               WDG_Timer++;

Alternate 8061 Watchdog

Code: Select all

563f: 11,05               clrb  R5               Watch_Dog_Tmr = 0;

Alternate LSO time wasting. B6_R2 happens to be AC_WOT_RLY in this bin.

Code: Select all

5730: 91,00,47            orb   R47,0            BIDI_IO = BIDI_IO;                #  OR 0 leaves bits unchanged
5733: a0,46,58            ldw   R58,R46          .lso_ctl_bits. = LSO_Ctl_Bits;
5736: 85,00,00,58         xrw   R58,0            .lso_ctl_bits. = .lso_ctl_bits.;  # XOR 0 leaves bits unchanged
573a: b0,58,02            ldb   R2,R58           LSO_Port = .lso_ctl_bits.;        # Write LSO bits to LSO Port
573d: b0,59,03            ldb   R3,R59           BIDO_Port = .bidi_io.;            # Write BIDI bits to BIDI Port

DARC pins labelled MBUS2, actually SPI, that makes sense of the info in the strategy docs. The handbook pinout names must be outdated.

1.2mHz is good info to know.

Yep, no RAM over J3.

[DWS]

Have you seen what 8065 does for the hardware watch dog? I don't remember which generation I first started poking at, but I attempted a bin from scratch and just made it loop the normal cpu watch dog method and flip on HSO0 for a visual ref. It was in a reset loop.

Much more recently, I did more or less the same thing on 8061, and saw the same reset pattern and found the LSO6 pin pulses on stock bin while mine it was missing and that's how I determined that was the requirement. Lot more going on for the 8065 boards, I'm thinking the AICE chip would be related to the process. On the 806, I actually removed the watchdog chip to validate it was what was commanding the reset. Of course it does a bit more than just hardware watchdog, can disable the feature by disconnecting the reset pin and the LOS control pin, probably not a good idea in case of a hardware fault (crashed cpu for example).

If you have a scope/LA, should be able to see the reset looping in the low ms range.

Side note working with a 83gb LA raw data dump capture, hopefully something of interest can be found in it =). I get to write a script to convert it into a more usable data structure and massively reduce the file size.

[jsa]

I've not seen a hardware watchdog in action on the 8061 & 8065 EEC boxes I've tested.

For 8065 with I/O expansion, SFR2 Bits 0, 1 & 2 are talking to expansion chips.
For 8065 with Memory expansion, SFR2 Bits 4, 5, 6 & 7 are the Bank Select lines.

GUFB is supposed to be using SFR2 Bit 6 as a CPU-OK watchdog, but that is not one one I've messed with.

That is a lot of data to reduce to something useful.

[DWS]

Yep

83gb -> 5.1gb -> 46mb -> 32.9k

Now to attempt to reconstruct the logic w\o the OBD2 overhead involved and just put delays to bloat out the time to mimic the orig read/write speeds and tighten till issues show up then back off some safe factor, assuming what I'm thinking is correct for the process.

R2 controls the LSO pins.

Maybe you haven't created a long enough program from scratch, if you have a scope and an 8061 computer, look for LSO6, or the 74001MC chip, pin 4 is where LSO6 is connected to. If the pulses stop, the 74001MC chip will pulse reset on pin 3 and flip the state of pin 7 to disable cpu control. It's part of the LOS strategy when the cpu crashes. I haven't dug too far into different variations, that's all based on SFI-SD3 hwid, but I've seen similar designs on several of the era. I'm not sure how it's handled on newer computers, but would be good to work out for running custom code on them.

Ideally once my FPGA comes in, I can create a mbus sniffer and stream the data to usb. I'm not sure if USB will be quite fast enough though, might have to add some sram for buffer space. In raw csv style text format (bloated a bit), 5.1gb over 125 sec capture boils down to 41.8MB/s stream rate. I guess that shouldn't be too hard for a computer to keep up with. My dev board has like 2MB of SRAM, so probably logical to build a small buffer. Have a feeling it's gonna take me a while to get the code working though (weeks, months, year?) since I have zero experience with FPGA's lol. I'm sure it will be a nice steep learning curve for me lol.

On the plus side, I can see instructions as they are ran, how long they take, memory the hits the mbus, etc. Here's a little snippet of a loop.

Code: Select all

4.621056730	SPC_ADD	820de	
4.621057100	INST	820de	11 05
4.621057600	INST	820e0	a2 31 34
4.621058480	MEM_READ	82070	20bc
4.621059100	INST	820e3	68 32 34
4.621059600	INST	820e6	69 03 00 34
4.621060220	INST	820ea	c6 33 36
4.621061100	MEM_WRITE	80a18	e7
4.621061600	INST	820ed	c6 33 34
4.621062470	MEM_WRITE	80a19	a1
4.621062970	INST	820f0	c6 33 35
4.621063850	MEM_WRITE	80a1a	36
4.621064350	INST	820f3	89 78 0a 32
4.621064970	INST	820f7	de e5
4.621065600	SPC_ADD	820de	

The memory read of words might be bugged a little, bytes should be reliable though. The extra LSO pins for ram bank switching I don't have logged, either I'd have to capture that, or monitor the register and keep track of the op codes in the script.

One down side and the main reason it's still a large bloated file is because loops are unwrapped, would be nice to wrap them back up and log the related memory addresses related per loop to track the changes over time (or no changes).

[jsa]

The lenght of the program is irrelevant. As already stated sfr2 bit6 (yes that is LSO6) is driving the a/c wot relay. It's not doing watchdog duty in the boxes I've tested.

Compare DUCE to non-DUCE boxes and see what you get. You have to realise implementation of features is not universal.

[DWS]

The 74001MC based one was an EEC-IV non-DUCE. I'll have to look at the newer ones to see when the chip dissapeared.

A cpu crash is very bad, it can turn on say the coil drivers on solid and fry coils. I don't see why they'd remove that style of protection in later versions except for cost cutting, possible they dropped the feature, but 2 of 2 have it in some form from my testing. The EEC-V I tested on was ~2000 era, pretty sure it had the EPIC version of the 8065.

Either case, my core focus isn't hardware based watchdog atm, but it's on the list of things to work out.

[jsa]

They didn't remove LOS, they moved it to DUCE which is software configurable (part of the RAM and/or DARC chip package).
Some 8065's should be running a pulse every 1mS on bit 3 of SFR 2 (LSO 3).

On the plus side, I can see instructions as they are ran, how long they take, memory the hits the mbus, etc. Here's a little snippet of a loop.

Code: Select all

4.621056730	SPC_ADD	820de	
4.621057100	INST	820de	11 05
4.621057600	INST	820e0	a2 31 34
4.621058480	MEM_READ	82070	20bc
4.621059100	INST	820e3	68 32 34
4.621059600	INST	820e6	69 03 00 34
4.621060220	INST	820ea	c6 33 36
4.621061100	MEM_WRITE	80a18	e7
4.621061600	INST	820ed	c6 33 34
4.621062470	MEM_WRITE	80a19	a1
4.621062970	INST	820f0	c6 33 35
4.621063850	MEM_WRITE	80a1a	36
4.621064350	INST	820f3	89 78 0a 32
4.621064970	INST	820f7	de e5
4.621065600	SPC_ADD	820de	

Nice, is that on an 8061?

[DWS]

Nice, I haven't looked into DUCE too much, so far I haven't seen a DUCE chip on a 8061 board.

The capture was on a EEC-V 216k board, cpu running at 24mhz.

[jsa]

Hardware codes with an SMD prefix should havd DUCE.

Have you got any capture snips for banks 0, 1 & 9?

[DWS]

Yea, it's the same thing except it says the bank number at the start, it's based on BS0 and BS3 pins in context of the eeprom/j3 port. I didn't monitor the between pins on the cpu (not 100% sure what they go to, haven't focused on eec-v as much at the hw level).

Ahh you're right, I did see that on a SMD hwid before. I was crossing some things. 81c65 vs 81c66 is CART vs EBC, for some reason I was thinking DUCE was the difference, but both have it >,<. Being a DIP chip, I should desolder one and play around with it some on the bread board lol.