reflash P59 tac module

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
RADustin
Posts: 162
Joined: Fri Oct 17, 2014 9:44 am

Re: reflash P59 tac module

Post by RADustin »

kur4o wrote:I found some random schematics.

There is 2 lines marked as aldl. Not sure if they are separate or tied internally in modules, to reduce the risk of loosing tac control.

Pcm 1mb blue,green pin14 pin 15 blue connector
tac pin12 pin 13 connector tan c1

Can you check if pins are tied internally in modules, if they are tied it is one channel communication and it doesn`t matter where you will intercept.
If they are not tied it could be dual channel communication.

edit:512kb pcm uses same pinout
confirmed on version 20.26 the logger works the same. its almost like the scan tool is getting hung up, like those few bytes come in only while I work the pedal arm back and forth, and just those few bytes. The log I'm taking is much longer time wise. log attached. It's just random blips of info and if I let the setup sit a minute and then disconnect and try to reconnect the scan tool has a red X on it and I need to power down and back up to keep working.
TAC Log 0_20_26.rtf
(566 Bytes) Downloaded 56 times

as far as the circuit/wiring works- yes only one bus wire is needed. They are internally shorted together on both the TAC and PCM. I removed one wire and am running it on a single wire right now to prove they are just redundant wires and not redundant buses. ...must be a safety critical thing the bean counters agreed to.
RADustin
Posts: 162
Joined: Fri Oct 17, 2014 9:44 am

Re: reflash P59 tac module

Post by RADustin »

I finally found my notes from previous testing. Here they are below(I need to replicate them to verify)-

I had to jog my memory, scary how much you can forget. I was able to log the bus with a simple FTDI chip and a serial terminal. Not sure the data is perfect but it's close.
UART TAC LOG 1.txt
(31.92 KiB) Downloaded 57 times
UART TAC LOG 3, start up and floor 3 times.txt
(30.18 KiB) Downloaded 52 times
UART TAC LOG 4, start up and idle, pcm only.txt
(9.29 KiB) Downloaded 49 times
From what I can tell, the PCM goes, a space is held, the TAC talks, a space is held, ... and it keeps revolving. The PCM is 4 data bytes and the TAC is 7. All messages end in a checksum.
known handshakes.txt
(2.42 KiB) Downloaded 54 times
the check sum is the sum of the prior bits, 1s comp, then plus 1(2s comp???). It does not wrap, ever. So notated out, don't mind my elementary notes lol-

10000000 (80)
+ 00001010 (OA)
________________________
10001010 (8A)


10001010 (8A)
+ 00100000 (20)
________________________
10101010 (AA)


10101010 (AA)
+ 10110010 (B2)
________________________
101011100 (15C)

shift back to 8 bit, (9th or MSB is dropped, 0x100 gone)

01011100 (5C)

take 1s comp

10100011 (A3)

add one to ensure when added to message bytes, it blows out of 8 bit(to 9 bit) leaving all zeros.

10100011 (A3)
+ 1 (01)
________________________
10100100 (A4)


so this is as far as I got years ago(2016). I'll work to replicate these results and see if we can take things further.
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: reflash P59 tac module

Post by kur4o »

The earlier logs don`t seem valid. length don`t match at all.
To log with ftdi get this program

http://ecmhack.com/eehack-2/download-eehack/

select device in settings and goto raw->scan idle, It won`t parse messages very well but all data will be logged.

You can also test logging tac only and pcm only. Usually one will be master and will request data while other will be passive and will only respond to master.


I suspect the device you have freaks out for some reason with aldl, do you have some other aldl module to test with, maybe chinese people forget to add some components.

It may be the firmware too. Which version of mdi manager you are running.
RADustin
Posts: 162
Joined: Fri Oct 17, 2014 9:44 am

Re: reflash P59 tac module

Post by RADustin »

kur4o wrote:The earlier logs don`t seem valid. length don`t match at all.
To log with ftdi get this program

http://ecmhack.com/eehack-2/download-eehack/

select device in settings and goto raw->scan idle, It won`t parse messages very well but all data will be logged.

You can also test logging tac only and pcm only. Usually one will be master and will request data while other will be passive and will only respond to master.


I suspect the device you have freaks out for some reason with aldl, do you have some other aldl module to test with, maybe chinese people forget to add some components.

It may be the firmware too. Which version of mdi manager you are running.
I think I've done PCM only and that's how I figured out what is what. I'll mess more with it later today or tomorrow. I suspect this isn't a normal bus structure since it's just point to point. It's definitely master/slave. The TAC is dead quiet until the PCM sends it info...and with that in mind, it's tricky to fire things up on the bench. If you fire the TAC before the PCM it will error out...it's real finicky. I just have everything set to turn on at the same time and it works. I remember the bus initialization giving me a ton of grief in the past when I was using a 2560 Arduino with multiple serial ports to act as the man in the middle.

later logs I have seem good as the checksums check out. also seem to match the data I have coming across the oscope.

MDI details-
MDI details.png
MDI details.png (11.96 KiB) Viewed 1347 times
yeah no clue if the MDI device is not good. It's just the standard issue china version, hasn't ever given problems before but also haven't tried ALDL. I may be able to borrow a legit version, I'll have to ask. Be better if there is another cable I use though. I don't have any other ALDL stuff to mess with unless I pull a PCM out the junkyard- seems a bit overkill.

maybe I'll just write my own logging program in python. I just need to figure out how to parse the messages and separate as PCM and TAC.
RADustin
Posts: 162
Joined: Fri Oct 17, 2014 9:44 am

Re: reflash P59 tac module

Post by RADustin »

I can easily pull data with the FTDI chip and RX tied to the bus, along with ground. Just did these, used rs232 Termite terminal.

Anyways, this is what I see. Again the 4 and 7 structure.

Raw data and I hand parsed some of it. Compare with oscope video..
Termitelog_PCM&Tac1.txt
(14.84 KiB) Downloaded 49 times
Termitelog_PCM&Tac1_parsed.txt
(14.41 KiB) Downloaded 57 times
Termitelog_PCM_Only.txt
(11.37 KiB) Downloaded 48 times
Termitelog_PCM_Only_parsed.txt
(11.15 KiB) Downloaded 51 times
the next thing might be to write a serial terminal program to try and automate the parsing. I'm not the greatest at that but I can probably struggle my way through. This is just to figure out the data stream though, doesn't necessarily get me any closer to a RAM dump...
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: reflash P59 tac module

Post by antus »

if your looking at aldl also look at our delco ose flash tool. that works with a standard serial interface and can log bus chatter, and allow you to send free form frames too and see what happens.

https://pcmhacking.net/forums/viewt ... p?f=3&t=82
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
RADustin
Posts: 162
Joined: Fri Oct 17, 2014 9:44 am

Re: reflash P59 tac module

Post by RADustin »

antus wrote:if your looking at aldl also look at our delco ose flash tool. that works with a standard serial interface and can log bus chatter, and allow you to send free form frames too and see what happens.

https://pcmhacking.net/forums/viewt ... p?f=3&t=82
Unfortunately it registers a few checksum errors and then quits. I think the MDI is doing the same thing.

The nonstandard messages mess with everything pre written for ALDL it appears.
RADustin
Posts: 162
Joined: Fri Oct 17, 2014 9:44 am

Re: reflash P59 tac module

Post by RADustin »

antus wrote:if your looking at aldl also look at our delco ose flash tool. that works with a standard serial interface and can log bus chatter, and allow you to send free form frames too and see what happens.

https://pcmhacking.net/forums/viewt ... p?f=3&t=82
on a generic scan tool, do you know how it separates messages? is it based on bus in-activity time? so when it sees say a period of a few mS of no traffic then it knows a new message is about to be sent? just trying to think of how to auto parse the bus data. Once I collect the messages I can assign them to either PCM or TAC based on length. and I can verify the data through the checksum byte.
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: reflash P59 tac module

Post by kur4o »

Logging and parsing idle traffic is much harder than you think. The only tool that did well is mdi.

You can hook ftdi device and open it in serial port monitor program on 8192 baud. It will read all data in continuous message and than we can parse them manually. ELtima serial port monitor is tested and works well.

You can try downgrading mdi manager to older version. Newer gm programs don`t work well with aldl, some even crash when you try to connect.
Tested with v 8.3.103.117

You can be sure the messages follows standard configuration, at least what I saw logged by mdi.
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: reflash P59 tac module

Post by antus »

I am not sure about US cars, but in Australia the BCM was the ALDL bus master and sends out a heartbeat every so often. Thats 3 bytes long and every module in the car waits for the heart beat then I believe it has timing hard coded so that all modules in the car transmit one after the other. Then there is a short gap at the end, which is just long enough for a tool to detect 50ms silence, then send a silence chatter to take over the bus. This is for the ecm, bcm, abs, dash etc on the standard bus. Then for SRS, thats on its own bus, and a command is sent to the BCM to bridge the two ALDL busses to make it available for a short time. Being we are talking TAC module here, I would suspect its quite possible that its on its own bus, too. if it really is ALDL it should have ALDL checksums though, I cant see that something important like TAC would have no error detection. I raw dump of all serial traffic would be good, then check the frames by hand to see if the tools can be trusted, or what else is going on.

looking at the raw logs above, I dont think thats ALDL. ALDL is Device ID, Length ($55+length), mode, submode, payload, checksum and none of those look like they fit that format.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Post Reply