Corvette CCM Reverse Engineering Anyone?

[NomakeWan]

I wasn't implying using the arduino delay() routine as a permanent solution, and maybe not even as a troubleshooting aid. Crude stuff there. I wouldn't even consider using a non-blocking mechanism that watches millis() as something "savvy". There are plenty of timer / counters available in the mega.

I'm afraid I'm not familiar with directly addressing timers for the AVR. I do consider non-blocking mechanisms like watching millis() to be savvy, at least compared to something blocking like delay().

Good deal. I figured as much but wouldn't have personally gone to the trouble of removing all of my debugging assistance (any of it actually) until I had a working proof-of-concept firmware. Having evidence that your message was received by the other devices on the bus is a critical part of that milestone. Thus my reason for questioning whether the sliding window logic was known to be working.

As steveo mentioned, this is a time-sensitive protocol on a bus with no hardware collision avoidance mechanism. The only way the nodes of the network can detect if they've read a bogus message is the checksum byte. Everything you've mentioned thus far points to the possibility that the receiving nodes aren't finding the checksum to be valid and are therefore ignoring the message. Please don't shoot the messenger, I'm genuinely trying to help because I want your project to work.

It may seem like I'm shooting the messenger, but I'm really not. I'm just responding to what's posted with the information on hand.

The issue with that theory is that I've plugged my laptop into the ALDL port and ran idle scans while letting the Mega fire up using the PCM's blue connector for both power and ALDL connection. And when I do that, I do not see the transmission. None of it. Not a single byte from the Mega shows up in EEHack's idle scan. So it's not that the CCM isn't reading the whole message and thus the checksum isn't matching...it's that the message does not appear on the line at all.

[steveo]

you know, theres no shame in blocking if there's nothing to do

everything you do blocks in one way or another

sometimes the task at hand is just hanging around for a bit waiting for the smoke to clear

its not like you have a user interface to service here, the program you're writing barely has any work to accomplish

anyway for your arduino issues i think a bigass regular diode will solve it. you're right that the tx line is holding the bus high you just need to kill that

[NomakeWan]

Hi guys,
I am loving following along. Am old school, just want to remind we are dealing analog/digital. Time is a huge factor.

Transport delay is a factor for a lot of things.

Thanks for the fun :)

You (and everyone else) were of course correct. I wasn't accounting for the analog traits of this circuit. Had I used GM's own circuit design, I have no doubt that I wouldn't have run into this problem at all, since their CMOS gate array would handle the analog shaping of the signal and thus the delay in question as the line changed signal levels. But since I didn't build GM's exact circuit, I was running into exactly that problem. And had I bothered to do idle scans of every single circuit layout I tested, rather than only one or two of the last ones, I would've noticed that issue a lot sooner. D'oh!

All I did this time was connect a 33k resistor between ALDL and RX (as specified by GM), and a standard IN914a diode between ALDL and TX with the stripe facing TX (as specified by spfautsch et al), then added delay(2); right before transmitting. The rest of the code remained identical. I connected my laptop to the ALDL port, started idle scanning, then turned the key. I expected to have to do some sleuthing using that idle log, but instead the dashboard jumped to life. The idle scan confirmed that the CCM/PCM polls were now functioning perfectly.

I can't believe a stupid 2ms delay was in my way this whole time. Of course, now I have to think about how best to utilize this newfound knowledge. Obviously the end goal is to be able to make a CCM happy even when the ECM/PCM the car came with is no longer present. How best to do that, though, I'm gonna have to give a good ol' fashioned think. On top of that, now that I know it was the delay at fault, I'm going to experiment with even better ways to connect to the car, such as attempting to control the serial data registers directly via interrupts so I can toss the resistor and diode entirely. For now, drinks all around.

IMG_2115.jpgIMG_2116.jpg

EDIT: It also points out that another difference between the '90 definition and the '95 reality is in how coolant temp is calculated. The $41 definition says it should be counts*0.75=DegC. But the 94-95 PCM ALDL datastream definition points out that for our cars it's (counts*0.75)-40=DegC. Not sure why they did that, but that lines up perfectly with reality (CD is 205, 205*0.75-40=113.75C=236.75F). I'll have to account for those differences too.

[In-Tech]

Yay, congrats

[spfautsch]

... I wasn't accounting for the analog traits of this circuit.

Yes, a shared serial "network" functions a lot like a RC network. There's a certain amount of time after the transmitter "releases" the line before the signal level rises back to a logic 1.

Glad you got it working finally! I'm enjoying a Maker's Mark on a chunk of ice to celebrate.

Obviously the end goal is to be able to make a CCM happy even when the ECM/PCM the car came with is no longer present. How best to do that, though, I'm gonna have to give a good ol' fashioned think.

If there's anything I can do to help just say the word.

such as attempting to control the serial data registers directly via interrupts so I can toss the resistor and diode entirely.

So you want to bitbang 8192 baud serial but you aren't wanting to use timers? I salute your ambition.

I was able to get a basic state machine working on my logger project in my down cycles today.

10 59 00 49 02 00 4C
40 57 FF FF 6B
10 59 00 49 02 00 4C
40 57 FF FF 6B
41 67 02 F5 00 49 49 01 00 DD 55 79 E3 00 3D FF FF 00 FF FF 07
F0 56 F1 C9
21948[F1 56 08 B1]
F1 56 08 B1
21960[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 65 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22059[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6A
22156[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F4 19 00 6E F5 66 65 65 66 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22254[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F4 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22351[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F4 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22450[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6A
22547[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 65 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22645[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6A
22743[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6D F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
F1 56 00 B9
10 59 00 49 02 00 4C

Lots of decisions to make but happy to see the experiment working. Should I buy a RTC so filenames can be based on the date, should I add wifi so it will upload the logs to my edge gateway box, etc.?

[steveo]

Lots of decisions to make but happy to see the experiment working. Should I buy a RTC so filenames can be based on the date, should I add wifi so it will upload the logs to my edge gateway box, etc.?

faced with the same decisions on my first black box datalogger project, i figured i was better off just getting a raspberry pi. i like the low level stuff, but having usb/ethernet/hdmi, and being able to attach gigabytes of flash memory to it with proper filesystems for a few dollars seemed like a no brainer, not to mention being able to SSH into the thing from my living room, and having threads and a scheduler to code with sped things up a lot when i wanted it to do more stuff.

[steveo]

we're all wins here, i got my eeprom block write to work (it does erase a byte if it differs, even if they only set bits low, that's the next step, but the code fits in one ALDL message which is just great)

0.000: flashhack Version 1.2
1.168: COMM::Sent message: F1580370CA7A
1.184: COMM::Recieved reply: F15703FEB7
1.184: CCM Software unlock: NO
1.260: COMM::Sent message: F15803644B05
1.276: COMM::Recieved reply: F157032293
1.277: CCM Hardware unlock: YES
1.277: Entering programming mode on CCM
1.354: COMM::Sent message: F15605B4
1.368: COMM::Recieved reply: F15705AA09
1.368: DEBUG::Executing prepared program CCM_WRITE_NEW on CCM
1.449: COMM::Sent message: F1B906624018CEF49DC601CEFFB0AD0039CE61E6F661E35A2BEBF761E33AA600FE61E43A8D0220E9C60337335A372706A100270220023339C6168D0A81FF2704C6028D0220E5F7103BA700CA01F7103B3CCE0D060926FD38C655F7103AC6AAF7103A7F103B39D4
1.582: COMM::Recieved reply: F15706AA08
1.584: DEBUG::Executed CCM_WRITE_NEW on CCM
1.584: DEBUG::PROGRAMMINGB600[5A]
1.650: COMM::Sent message: F1B80661E07E624C5AB600012BFF8DFFFFFFFF00000000000000000000012BFF8DFFFFFFFF00000000000000000000012BFF8DFFFFFFFF00000000000000000000000000000000000000000000000000000000000000000000000000000000000000050000B3
1.786: COMM::Recieved reply: F15706AA08
1.788: DEBUG::PROGRAMMINGB65A[5A]
1.854: COMM::Sent message: F1B80661E07E624C5AB65A000000000000000000000000000000000000000131FFD6FFFFFFFFFFFFFFFFFFFFFFFFFFFF4A9F44DC02D637482D5B34C70467361E1791494631011DA1482E405E391835AF1213040B0000400101010101010101010101010101ED
1.989: COMM::Recieved reply: F15706AA08
1.991: DEBUG::PROGRAMMINGB6B4[5A]
2.057: COMM::Sent message: F1B80661E07E624C5AB6B40101010101010101010101010101010101FF3A020000FE400010000000800020000801804020100804028000080402010000000020000800FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4A
2.192: COMM::Recieved reply: F15706AA08
2.194: DEBUG::PROGRAMMINGB70E[5A]
2.260: COMM::Sent message: F1B80661E07E624C5AB70EFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1F
2.588: COMM::Recieved reply: F15706AA08
2.591: DEBUG::PROGRAMMINGB768[5A]
2.667: COMM::Sent message: F1B80661E07E624C5AB768FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC5
2.802: COMM::Recieved reply: F15706AA08
2.805: DEBUG::PROGRAMMINGB7C2[3E]
2.875: COMM::Sent message: F19C0661E07E624C3EB7C2FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF314731595932325038533531313838373767
2.975: COMM::Recieved reply: F15706AA08
2.977: EEPROM write complete.
2.997: Resetting CCM...

routine:

COMMAND RUN THE PROGRAM:
7E $program_routine_address [BLK_SIZE] [OFFSET_16] [DATA...]

        ; ALDL_REPLY(START)

18 CE F4 9D ; LDY 0xF49D
C6 01       ; LDAB 0x01
ce ff b0    ; LDX loc_FFB0
ad 00       ; JSR,x+00
39          ; RTS

        ; ALDL_REPLY(END)

        ; PROGRAM_BLOCK(START)

        ; INPUT MUST GO AT 61E3 OR MUST REALIGN ALL 61E VALUES.
        ; INPUT: [BLK_SIZE] [OFFSET_16] [DATA....]

CE 61E6 ; LDX address of data
F6 61E3 ; LDAB block size
5A      ; DECB block size--
2B EB   ; BMI if b<0 goto ALDL_REPLY (operation finsihed)
F7 61E3 ; STAB block size
3A      ; ABX - add blk size to address of data
A6 00   ; LDAA,x - A = data at address of data
FE 61E4 ; LDX write offset
3A      ; ABX - add blk size to write offset
8D 02   ; BSR PROGRAM_BYTE
20 E9   ; BRA PROGRAM_BLOCK (loop)

        ; PROGRAM_BLOCK(END)

        ; SUBROUTINE PROGRAM_BYTE(START) - A=VALUE X=ADDRESS

        ; CONFIGURE:
C6 03   ; LDAB 03
37      ; PSHB - push max retry count onto stack

        ; RETRY LIMIT:
33      ; PULB  - pull retry counter
5A      ; DEC B (B--)  - decrement counter
37      ; PSHB  - push retry counter
27 06   ; BEQ COMPLETE

        ; VERIFY:
A1 00   ; CMPA,X - compare target value with existing value
27 02   ; BEQ COMPLETE - if value is already correct.
20 02   ; BRA ERASE - if value not yet programmed

        ; COMPLETE:
33      ; PULB - remove retry counter from stack
39      ; RTS

        ; ERASE:
C6 16   ; LDAB 0x16 - program mode ELAT/BYTE/ERASE
8D 0A   ; BSR EEPROM_PROG  - call program subroutine

        ; SKIP 0xFF:
81 FF   ; CMPA 0xFF   - see if A = 0xFF
27 04   ; BEQ VERIFY  - skip programming if FF

        ; PROGRAM:
C6 02   ; LDAB 0x02 - program mode ELAT
8D 02   ; BSR EEPROM_PROG - call program subroutine

20 E5   ; BRA VERIFY - loop back to verify

        ; PROGRAM_BYTE(END)
        
        ; SUBROUTINE EEPROM_PROG(START) - ACCUMULATOR B = PROGRAMMING MODE.

        ; LATCH AND SET BYTE
F7 103B ; STAB 0x103B  - set eeprom control register from B
A7 00   ; STAA,x  - store A (value) at X (location) (write byte)

        ; SET EPGM (PROGRAM VOLTAGE)
CA 01   ; ORA 0x01 - set EPGM (bit 1) in B
F7 103B ; STAB 0x103B  - set eeprom control register from B

        ; DELAY
3C      ; PSHX - save X register
CE 0D06 ; LDX 0xD06 - loop total exec time approx 10ms @ 2mhz clock (6 cycles in loop)
09      ; DEX  - x--
26 FD   ; BNE REL-3 IF > 0
38      ; PULX  - restore X register

        ; RESET COP (for every 10ms delay)
C6 55   ; LDAB 0x55 ; ARM COP.
F7 103A ; STAB 0x103A (COPRST)
C6 AA   ; LDAB 0xAA ; RESET COP
F7 103A ; STAB 0x103A (COPRST)

        ; COMPLETE
7F 103B ; CLR eeprom control register
39      ; RTS return

        ; EEPROM_PROG (END)

[steveo]

works.... i think! (the output is correct at least) total overkill for the CCM but definitely will be good with EE and friends.

increased block size to 122 bytes too and seems to work well.

i think the EEPROM writes as well as the flash in EE now. would like to generate a failure code if the verify fails, but it's probably better to just checksum the whole thing afterwards as i'm trying to keep it to minimal ram use, it's 104 bytes right now complete.

        ; DIFF:
        ; SEE IF ANY BITS ARE ACTUALLY GOING TO BE SET HIGH.
        ; IF NOT, WE DO NOT HAVE TO ERASE (AVOID 10MS DELAY)
36      ; PSHA
43      ; COMA - NOT A
A4 00   ; ANDA - AND A WITH MEMORY AT X
32      ; PULA
26 04   ; BNE SKIP FF (SKIP ERASE)

[NomakeWan]

we're all wins here, i got my eeprom block write to work (it does erase a byte if it differs, even if they only set bits low, that's the next step, but the code fits in one ALDL message which is just great)

Phenomenal work!! That you're still able to iterate and get the flash routines more and more efficient is amazing. It's why I just chuckle when people try to talk up Hypertech and TunerCats and say Flashhack isn't worth it. They were perfectly acceptable (well, not Hypertech) two decades ago, but there've been huge strides since their heyday. Way to go!

faced with the same decisions on my first black box datalogger project, i figured i was better off just getting a raspberry pi. i like the low level stuff, but having usb/ethernet/hdmi, and being able to attach gigabytes of flash memory to it with proper filesystems for a few dollars seemed like a no brainer, not to mention being able to SSH into the thing from my living room, and having threads and a scheduler to code with sped things up a lot when i wanted it to do more stuff.

This!! Especially with the Pi Zero 2 W. I'm actually gonna try to pick one up at my local Micro Center tomorrow, they seem to be a phenomenal piece of kit. $15 for a Pi with a 64-bit 1GHz quad-core and N wireless? Yes please!!

So you want to bitbang 8192 baud serial but you aren't wanting to use timers? I salute your ambition.

Bwahaha, thanks, but nah. I'm not trying to reinvent the wheel as far as the actual serial receive/transmit part goes. I'm simply going to try addressing the hardware serial registers directly to disable the transmit interrupts and set the port low when receiving and then disable receive interrupts and return the transmit port to normal when it's transmit time. In theory it should work just as well as the diode solution. I did test it before, but it could very well have been affected by the delay issue, so I don't know if it actually worked as intended or not. I'll find out tomorrow.

[spfautsch]

... when I do that, I do not see the transmission. None of it. Not a single byte from the Mega shows up in EEHack's idle scan. So it's not that the CCM isn't reading the whole message and thus the checksum isn't matching...it's that the message does not appear on the line at all.

So you most likely have an issue with your circuit. Try the diode and resistor arrangement and see what happens while running an idle scan. Doesn't need to be a zener - any diode will do the trick just make sure the cathode (stripe) is pointing towards the arduino TX pin.

Nice work steveo. Is there anything I can test that you haven't already?

COMM::Sent message: F1580370CA7A
COMM::Recieved reply: F15703FEB7
CCM Software unlock: NO
COMM::Sent message: F15803644B05
COMM::Recieved reply: F157032293
CCM Hardware unlock: YES

Very elegant, checking if there will be a problem before requesting an unlock.

[spfautsch]

Here's an updated .xdf - fixed the odometer conversion formula in the description. I copied it directly from the datastream document and didn't bother to check if it was correct. It was not...

[steveo]

Very elegant, checking if there will be a problem before requesting an unlock.

thanks,these modules would be way less fun to work with if we weren't able to read their memory. before we figured the code for the challenge/response for EE when i was writing eehack, kur4o found where the challenge/response was stored, and i just stole the correct value from RAM.

i doubt i'll need much more testing, i plan to abuse the CCM to test/finish my more advanced eeprom write routine then i'll probably be bored of the thing.

right now it has a really bright annoying security light and i can't find my box of resistors

i'm thinking this is pretty close to what i want to write the eeprom, haven't tested/debugged/verified it yet but you get the idea

CE 61 E9 F6 61 E6 5A C1 FF 27 0C F7 61 E6 3A A6 00 FE 61 E7 3A 8D 0C 18 CE F4 9D C6 01 CE FF B0 AD 00 39 C6 03 37 33 A1 00 27 04 5A 37 26 01 39 C6 16 8D 0A 81 FF 27 04 C6 02 8D 02 20 E8 F7 10 3B A7 00 CA 01 F7 10 3B 3C CE 0D 06 09 26 FD 38 86 55 F7 10 3A 86 55 F7 10 3A 7F 10 3B 39

        ; PROGRAM BLOCK(START)

        ; INPUT MUST GO AT 61E6 OR MUST REALIGN ALL 61E VALUES.
        ; INPUT: [BLK_SIZE] [OFFSET_16] [DATA....]

CE 61E9 ; LDX X = 61E6+3 (START OF DATA)
F6 61E6 ; LDAB BLK_SIZE
5A      ; DECB - decrease blk size - we are using it as a counter now.
C1 FF   ; CMPB 0xFF
27 0C   ; BEQ ALDL_REPLY (if B=0xFF then counter has wrapped and we are done.)
F7 61E6 ; store decreased blk size
3A      ; ABX - add blk size to x
A6 00   ; LDAA,x - A=data to write
FE 61E7 ; LDX write offset
3A      ; ABX - add current blk size to offset location - X=write address
8D 0C   ; BSR PROGRAM

        ; PROGRAM BLOCK(END)

        ; ALDL_REPLY(START)

18 CE F4 9D ; LDY 0xF49D
C6 01       ; LDAB 0x01
ce ff b0    ; LDX loc_FFB0
ad 00       ; JSR,x+00
39          ; RTS

        ; ALDL_REPLY(END)

        ; PROGRAM_BYTE(START) - A=VALUE X=ADDRESS

        ; CONFIGURE:
C6 03   ; LDAB 0x0B - number of retry attempts + 1.
37      ; PSHB - store retry counter on stack

        ; VERIFY:
33      ; PULB  - pull retry counter
A1 00   ; CMPA,X - compare target value with existing value
27 04   ; BEQ COMPLETE - if value is already correct.
5A      ; DEC B (B--)  - decrement counter
37      ; PSHB  - push retry counter back onto stack
26 01   ; BNE - if B!=0 (retry count not exceeded) goto ERASE
        ; FIXME: might be a good idea to create a failure reply if the verify loop fails.
        ; COMPLETE:
39      ; RTS

        ; ERASE:
C6 16   ; LDAB 0x16 - program mode ELAT/BYTE/ERASE
8D 0A   ; BSR EEPROM_PROG  - call program subroutine

        ; SKIP 0xFF:
81 FF   ; CMPA 0xFF   - see if A = 0xFF
27 04   ; BEQ VERIFY  - jump to verify if equal

        ; PROGRAM:
C6 02   ; LDAB 0x02 - program mode ELAT
8D 02   ; BSR EEPROM_PROG - call program subroutine

20 E8   ; BRA VERIFY - loop back to verify (-24 bytes)

        ; PROGRAM_BYTE(END)
        
        ; EEPROM_PROG(START) - ACCUMULATOR B = PROGRAMMING MODE.

        ; LATCH AND SET BYTE
F7 103B ; STAB 0x103B  - set eeprom control register from B
A7 00   ; STAA,x  - store A (value) at X (location) (write byte)

        ; SET EPGM (PROGRAM VOLTAGE)
CA 01   ; ORA 0x01 - set EPGM (bit 1) in B
F7 103B ; STAB 0x103B  - set eeprom control register from B

        ; DELAY
3C      ; PSHX - save X register
CE 0D06 ; LDX 0xD06 - loop total exec time approx 10ms @ 2mhz clock (6 cycles in loop)
09      ; DEX  - x--
26 FD   ; BNE REL-3 IF > 0
38      ; PULX  - restore X register

        ; RESET COP (for every 10ms delay)
86 55   ; LDAB 0x55 ; ARM COP.
F7 103A ; STAB 0x103A (COPRST)
86 55   ; LDAB 0xAA ; RESET COP
F7 103A ; STAB 0x103A (COPRST)

        ; COMPLETE
7F 103B ; CLR eeprom control register
39      ; RTS return

        ; EEPROM_PROG (END)

[steveo]

so it turns out i had programmed spfautsch-orig-ccm-178385mi-2.bin for testing and for some reason B6A2 (which is what the XDF says is the VATS byte) is 0

any idea what happened?

i wonder what the best way to recover would be. maybe i'll try no resistor at all.

[spfautsch]

You've changed the VATS code and then dumped the eeprom without changing the VATS resistor so mode 2 or 3 reads of that region return 0x00 per NomakeWan's documentation. You now need a 11.8k resistor (code 15) to make VATS happy. You should be able to override all the read / compare checks and just blindly erase the VATS code byte(s) and reprogram them back to 0x0B (4.75k / code 11) without the correct resistor though. The module will unlock for mode 6 regardless, but mode 2 / 3 reads are giving you zeros because VATS didn't pass.

Good find, this would surely have come up with someone programming an unknown VATS code unit on a test bench.

Edit: I think working around this might not be terribly complex. I'm just thinking in microcontroller mode at the moment (see next comment).

I'd go further with my help but I'm about 2 hours away from a generic arduino logger proof-of-concept that I hope will help NomakeWan immensely. Already have a "fast forward to first valid message" routine. New thread upcoming on that one.

This is what I have on that:

0 
10 59 00 00 00 00 97 
n7 
40 57 00 00 69 
n12 
10 59 00 00 00 00 97 
n19 
40 57 00 00 69 
n24 
10 59 00 00 00 00 97 
n31 
40 57 00 00 69 
n36 
10 59 00 00 00 00 97 
n43 
40 57 00 00 69 
n48 
10 59 00 00 00 00 97 
n55 
40 57 00 00 69 
n60 
10 59 00 00 00 00 97 
n67 
40 57 00 00 69 
n72 
10 59 00 00 00 00 97 
n79 
40 57 00 00 69 
n84 
10 59 00 00 00 00 97 
n91 
40 57 00 00 69 
n96 
10 59 00 00 00 00 97 
n103 
40 57 00 00 69 
n108 
10 59 00 00 00 00 97 
n115 
40 57 00 00 69 
n120 
10 59 00 00 00 00 97 
n127 
40 57 00 00 69 
n-124 
0 
10 59 00 00 00 00 97

This is with the micro finding the first valid message via checksum validation. The only issue I have to fix is that my input buffer is a 255 byte ringbuffer and the message pump isn't correctly handling the wraparound from 255 to 0 (yet).

[steveo]

but i haven't dumped the eeprom - i programmed that byte to 0 because 0 was in the bin i was writing from, im not getting thar from a mode 2 or 3 ram dump

if that byte is actually 15 i have no idea how it would have ended up that way

i hope you're right about being able to enter mode 5/6 with the wrong vats resistor