Hi Tom,
it may be covered already, but is the mode 19 request have been decoded.
Currently it uses 19 [XX] FF 00
while XX is the status of dtc being requested. 02=current 10=history as far as I know. Playing with that byte I got different results but have no idea how to make a full usage of it and decode it.
HI,Originally Posted by kur4o
Hope I have this right, see if it makes sense please.
Mode $19
Request Status of Diagnostic Trouble Codes
Request is composed of header, mode, status, $FF and request_type
Standard physical header
Status as follows:
Bit 7 Warning lamp illuminated for this code
Bit 6 Warning lamp pending for this code, not illuminate but malfunction was detected
Bit 5 Warning lamp was previously illuminated for this code, malfunction not currently detected, code not yet erased
Bit 4 Stored trouble code
Bit 3 Manufacturer specific status
Bit2 Manufacturer specific status
Bit 1 Current code - present at time of request
Bit 0 Maturing/intermittent code
Group: FF is all
Request type: FF=count, 00= status of each dtc
Reply comes in multiple frames on my bench where most terminals are open at the moment
Header: Mode: DTC: Status for this DTC
Note: Some interfaces (like ELM327) use a command response format. This will work badly in this mode. First response will be OK, others will be lost. I designed the homebrew cable to pass all traffic on the VPN (EDIT: try VPW instead) up to the computer. Other cables are probably capable but some modes are restricted to command/response type format.
I have not completely worked through Mode $19. It isn't in the SAE spec but I believe it is mostly the same as Mode $17
The command:
4C 10 F0 19 FF FF 00 83
is interesting as it replies with all the DTCs one after the other. Response to the bench was:
4C F0 10 59 01 00 25 9C
4C F0 10 59 01 01 25 D0
4C F0 10 59 01 02 25 04
4C F0 10 59 01 03 25 48
4C F0 10 59 01 07 6F A4
4C F0 10 59 01 08 25 C6
4C F0 10 59 01 12 25 B0
4C F0 10 59 01 13 25 FC
4C F0 10 59 01 17 25 D1
4C F0 10 59 01 18 25 72
4C F0 10 59 01 21 25 A5
4C F0 10 59 01 22 01 82
4C F0 10 59 01 23 01 CE
4C F0 10 59 01 31 25 11
4C F0 10 59 01 32 25 C5
4C F0 10 59 01 34 25 70
4C F0 10 59 01 35 25 3C
4C F0 10 59 01 37 25 A4
4C F0 10 59 01 38 25 07
4C F0 10 59 01 40 25 76
4C F0 10 59 01 41 25 3A
4C F0 10 59 01 51 25 8E
4C F0 10 59 01 52 25 5A
4C F0 10 59 01 54 25 EF
4C F0 10 59 01 55 25 A3
4C F0 10 59 01 57 25 3B
4C F0 10 59 01 58 25 98
4C F0 10 59 01 60 25 03
4C F0 10 59 01 61 25 4F
4C F0 10 59 01 71 25 FB
4C F0 10 59 01 72 25 2F
4C F0 10 59 01 74 25 9A
4C F0 10 59 01 75 01 25
4C F0 10 59 02 00 25 10
4C F0 10 59 03 00 25 9F
4C F0 10 59 03 23 25 3E
4C F0 10 59 03 25 25 8B
4C F0 10 59 03 32 25 C6
4C F0 10 59 03 35 25 3F
4C F0 10 59 03 36 25 EB
4C F0 10 59 03 72 25 2C
4C F0 10 59 04 00 25 15
4C F0 10 59 04 03 25 C1
4C F0 10 59 04 41 25 B3
4C F0 10 59 04 43 25 2B
4C F0 10 59 05 00 25 9A
4C F0 10 59 05 06 25 2F
4C F0 10 59 05 07 25 63
4C F0 10 59 05 30 25 5B
4C F0 10 59 05 31 25 17
4C F0 10 59 05 62 25 9D
4C F0 10 59 05 63 01 22
4C F0 10 59 06 01 01 A9
4C F0 10 59 06 02 25 8E
4C F0 10 59 11 07 7F 71
4C F0 10 59 11 11 25 7C
4C F0 10 59 11 12 25 A8
4C F0 10 59 11 14 25 1D
4C F0 10 59 11 15 25 51
4C F0 10 59 11 21 01 4E
4C F0 10 59 11 22 01 9A
4C F0 10 59 11 33 25 91
4C F0 10 59 11 53 25 0E
4C F0 10 59 11 71 25 E3
4C F0 10 59 12 22 25 E5
4C F0 10 59 13 51 25 95
4C F0 10 59 13 61 25 54
4C F0 10 59 13 71 01 13
4C F0 10 59 13 80 25 4E
4C F0 10 59 13 81 25 02
4C F0 10 59 14 41 25 AB
4C F0 10 59 15 08 25 D8
4C F0 10 59 15 09 25 94
4C F0 10 59 15 32 25 DB
4C F0 10 59 15 33 25 97
4C F0 10 59 15 39 25 55
4C F0 10 59 15 43 25 BC
4C F0 10 59 15 45 25 09
4C F0 10 59 15 46 25 DD
4C F0 10 59 16 26 25 CE
4C F0 10 59 16 41 25 A8
4C F0 10 59 16 42 25 7C
4C F0 10 59 16 43 25 30
4C F0 10 59 16 52 25 C8
4C F0 10 59 16 61 25 DD
4C F0 10 59 16 67 25 68
4C F0 10 59 00 00 00 FD
Let me know it this answers what you need. -Tom
Last edited by Tom H; 12-27-2022 at 04:56 PM.
That makes sense now. Great find.
Do you know the meaning of the byte after dtc code in response[ in you log the most repeatable is 25].
I am sure it is some encoding of the current status of the dtc.
I am little confused about the dtc clear command.
Some suggest using mode 10, In some gm logs mode 14 and mode 20 is used. Not yet sure what clears what.
Maybe it is covered already but some info for the freeze frames record and how to read them from a log will be great.
First bit...
As I understand it, the byte is decoded as
Bit 7 Warning lamp illuminated for this code
Bit 6 Warning lamp pending for this code, not illuminate but malfunction was detected
Bit 5 Warning lamp was previously illuminated for this code, malfunction not currently detected, code not yet erased
Bit 4 Stored trouble code
Bit 3 Manufacturer specific status 1
Bit 2 Manufacturer specific status 0
Bit 1 Current code - present at time of request
Bit 0 Maturing/intermittent code
It is unclear to me why GM always sets bit 0, but that is the way the code runs. In my case the result is often $25 because I have nothing connected to many of the inputs. I decode it as:
Maturing/intermittent code | Manufacturer specific status 0 | Warning lamp was previously illuminated for this code, malfunction not currently detected, code not yet erased
This is right after power up --> cold reset (tags in ram not found). I guess what is showing is that no "trips" have passed and the codes are default. Work here is not complete, interested in your finds.
2nd bit...
Mode $10 is Initiate Diagnostic Operation. This is used for running tests where performance of the PCM is degraded in some way.
Mode $20 is Return to Normal Operation. This exits diagnostic operation, re-starts comms on ALDL and so on
Mode $14 clears the DTCs
4C 10 F0 14 5C is physically addressed to the PCM and resets all the codes.
3rd bit...
Here is what I have re freeze frames:
But I can't paste it into this window so here is a segment of my notes on freeze frame
-Tom
Another great piece of detailed explanation for freeze frames.
I am trying to read some bcm via inbuilt mode 35, but there is some issue, that can`t be figured.
on first attempt it response as expected 75 than 36 with block message
[08:54:40.527] [08:54:40.527] 6C 40 F0 35 00 10 00 00 20
[08:54:41.117] [08:54:41.118] 6C F0 40 75 [54]
[08:54:41.117] [08:54:41.119] 6D F0 40 36 01 00 10 00 00 20 FB F8 FB 2B FB C3 FB C3 FB 02 00 01 00 0D 00 0D 07 DE
[08:54:43.130] [08:54:43.130] 6C FE F0 3F
however on second request it fails
08:54:43.188] [08:54:43.188] 6C 40 F0 35 00 10 00 10 44
[08:54:43.734] [08:54:43.735] 6C F0 40 75 [52]
than
[08:55:01.573] [08:55:01.573] 6C 40 F0 35 00 10 00 81 40
[08:55:02.109] [08:55:02.110] 6C F0 40 75 [50]
What that status byte in brackets will mean. 54 seems success, block message will be sent.
But than there is 52 and after some more attempts it switches to 50, than back to 52 and so on.
Could it be some timer, or some other delayed needed or some other sequence of data needs to be send between attempts.
Any info will be great.
Not sure how much I can help but here is a list of response codes. Probably you already know this, but in case you are missing some here is the list I have
Code $00 - Affirmative Response
Code $10 - General Reject
Code $11 - Mode Not Supported
Code $12 - Sub-Function Not Supported- Invalid format
Code $21 - Busy - Repeat Request
Code $22 - Conditions Not Correct or Request Sequence Error
Code $23 - Routine Not Complete
Code $31 - Request Out of Range
Code $33 - Security Access Denied
Code $34 - Security Access Allowed
Code $35 - Invalid Key
Code $36 - Exceed Number of Attempts
Code $37 - Required Time Delay Not Expired
Code $40 - Download Not Accepted
Code $41 - Improper Download Type
Code $42 - Can't Download to Specified Address
Code $43 - Can't Download Number of Bytes Requested
Code $44 - Ready for Download
Code $50 - Upload not Accepted
Code $51 - Improper Upload Type
Code $52 - Can't Upload from Specified Address
Code $53 - Can't Upload Number of Bytes Requested
Code $54 - Ready for Upload
Code $61 - Normal Exit with Results Available
Code $62 - Normal Exit without Results Available
Code $63 - Abnormal Exit with Results
Code $64 - Abnormal Exit without Results
Code $71 - Transfer Suspended
Code $72 - Transfer Aborted
Code $73 - Block Transfer Complete/Next BLock
Code $74 - Illegal Address in Block Transfer
Code $75 - Illegal Byte Count in Block Transfer
Code $76 - Illegal Block Tranfser Type
Code $77 - Block Transfer Data Checksum Error
Code $78 - Block Transfer Message Correctly Received- Response Pending
Code $79 - Incorrect Byte Count During Block Transfer
Code $7F - Negative response
Code $81 - Scheduler Full
Code $83 - Voltage Out Of Range Fault (High/Low)
Code $85 - General Programming Failure
Code $89 - Device Type Error
Code $99 - Ready For Download- DTC Stored
Code $AA - Success
Code $E3 - Device Control Limits Exceeded
When I did my upload and download software to re-program the flash I found a number of restricted areas. It makes sense you can't download to hard coded bits. Also makes sense that the ram used to support loading can't be overwritten. In the case of ESide there was a restriction on the first $80 bytes. This is where the ESide kept it's variables to support the download. You could disassemble the code and look for those restrictions or just move the load to another spot.
Regarding the response codes, I think you can be sure of
Code $50 - Upload not Accepted
Code $52 - Can't Upload from Specified Address
Code $54 - Ready for Upload
Another possibility is that the code has not restricted you from overwriting support variables. This could cause a crash/reboot sequence
Last up the PCM needs keep alive messages every few seconds. If mode $3F isn't sent it re-locks the security.
Let us know what you uncover.
-Tom
Some partial success. After bcm sends 36 01 bock message, tool needs to confirm it is received by sending 76 01 54.
However now I am getting another issue. First 5-10 responses are good, than bcm change state and gets locked. Sending error code that it is locked.
I tried dumping all kind of 3f messages but still can`t keep it unlocked. More testing on the go.
Thanks for the reply! Interesting it requires mode $76 response. I struggled with this when writing the ESide upload. In the end I made it optional because it increased the traffic/time to do the upload. I figured that if the mode $36 was corrupted (crc or ?), I would just re-request the block. In practice it seems to work reliably, never seen a re-transmission. This all is low speed in my case (10KHZ).
I don't know what the configuration you are working with is, so a couple of questions: Is the BCM connected directly to the VPW/J1850 bus OR does the PCM evaluate the message and re-send it on the ALDL??
Perhaps you could draw/write up a basic picture of the info flow?
-Tom
Here is some log I made. There is direct communication with bcm, there is 14 modules hooked on the bus. Now looking closer at the logs, the bcm might crash when I request specific address At A0, maybe some ram is affected or that space is limited or locked.
At that point bcm seems to reset. I can try highspeed log, that might also be the case.
Finally some success, it turned out that request of some specific address made the bcm crash.
Here is the full dump I managed to get.
Tom H, why don`t you try to add a driver for your custom built cable to universal patcher program. I think it won`t be very hard. there is some example in there for avt and elm. You can even convert to hex than ascii string communication to save buffer space for transmission.
Cable is still a bit of a work in progress. It's fine with the '97 topology with a single pair of communicating devices. It's fine with multiple devices IF all are query<-->response sort of operation. I have yet to implement arbitration so this can cause problems where two devices start to contend for the bus. This along with the so called high speed (41.6K speed) are things I have yet to get to. Also could modify the interface to be more in line with what has been done. On that...
Not sure how avt/elm indicate in the data stream that a CRC fault has been detected. The interface I wrote generates but does not check. Checking is done by the software that uses the link. I have a hardware checker written and tested, but discarded it because it would have needed some sort of code scheme to indicate success/failure of CRC. This would have then caused some sort of scheme where CRC OK would have been indicated with an inband code. Now this means some sort of escape sequence. I think the route I took is more secure and makes a more simple interface however at a cost of compatibility
Still working through the ESC/knock module interface. I will post soon with details.
-Tom
Regarding x4, you don`t really need it to reflash or read a module, it will just take x4 times slower to do it. But it will be perfectly fine without it. 96-97 pcm are not that big in memory [around 160kb] so extra waiting is not that big of a problem.
Usually the x4 switch is hardware based initiated from pc, and cable revert back on hardware level when a x1 frame is sensed.
The crc is always handled by cable, incoming messages are checked on hardware level and if crc don`t match the message is discarded and some error code is sent or some lost frame counter is incremented on cable. You can turn on/off with a special command the configuration for crc byte - sent from cable to pc. Usually is much easier, cable to handle the crc on its own, as is every module setup. the dlc transmitter handles the crc verification upon transmission.
The app I posted does just that, works fine
Switch to x4 can be initiated from the PC, but in the sequence to initiate download the PCM moves to 4x on it's own. The solution is to send a throw away frame such as "test device present" mode $3F. When this is sent, the pulses are too long and cause the PCM to back off to x1. From there all works as you suggest in x1 mode.
This is a difference with the cable I designed. I have disabled CRC checking on the incoming messages. That way when CRC is checked in the PC, the message is checked end to end. That is, including the rs232 <--> USB <--> software links. I do generate CRC on outgoing messages as a convenience, but that too would be better sourced from software. Main issue is so many things to look at, so little time.
In the end I will probably disable CRC completely in the cable, add contention resolution/arbitration and add 4x mode. For now it is a rough tool that helps me with my goal to understand the software. Most of my focus is currently on the TPM in particular on the low res interrupt. Some posts on this are pending.
-Tom
So you are saying that 96-97 lt1 pcm switch on its own to x4 mode, and don`t support mode a0 and mode a1
The later sequence is as follow.
6c fe f0 a0 - prepare modules to enter high speed, each module will response with AA, if support it and ready.
8c fe f0 3f
8c fe f0 3f
8c fe f0 3f
8c fe f0 3f
8c fe f0 3f
6c fe f0 a1 -x4 swicth command, no response is send
wait 500ms
setspeed:4x - switch hardware at x4mode
For crc you will find at the end that best setup is.
PC->cable, send crc with message or leave that to cable[cable crc generation will be preferred]. transmission from pc to cable can be echoed back for verification.
Cable->pc, the message should already have crc->cable can check for integrity->discard bad-<or>cable always send crc to pc->pc check it or just ignore it[test connection from cable->pc for errors].
Looks you already have the way it needs to be. Maybe use serial echo for extra piece of mind.
Usually there will be a problem when block message have incorrect checksum, here comes the gm block sum, for extra layer of protection.
Yes and no. Move to 4x is automatic when downloading. After all the setup commands, the PCM produces a response code of $44 to say "ready for download". Then clears low memory base page ($0000 through $00FF). When complete, transfers control to address $DC50 which I named "DATA LINK CONTROL GET FRAME". Then a bunch more setup and... when a mode $34 request for download is seen it first resets the stack then executes:
ldd #$1813 ; DLC COMMAND: LOAD AS CONFIGURATION BYTE
std DLC_CMD_REG ; WRITE COMMAND: DISABLE DLC INT, 4X MODE
by setting bit 0 in the configuration of the DLC, 4X mode is entered.
I designed my cable such that the bytes sent/received are all presumed as data. In a case where the entire 8bits are used for data there are no codes that remain to indicate CRC fault or whatever. In this case you would need some sort of escape sequence to transfer control info. In any case good or bad the cable is done for the moment. Later I can revise and add the missing arbitration and speed. To transfer a request to enter 4x mode to the cable, there will need to be an escape sequence in any case.
Second time you do anything is always better cause you know what the issues are.
Monitoring the code I wrote to download with my cable, I have never seen a CRC fault or a block csum error. To test the code's recovery I needed to create these faults just to see what would happen. Even testing code with this PCM is a pia.
-Tom
Posting Permissions
Reply With Quote
Bookmarks