OBDII Protocol for 150 Prados in recent years

[GeeWhizz Senior Member Find all posts View Profile Close GeeWhizz]

I am trying to get my custom designed CAN Bus (OBDII) interface to communicate with my 2023 GXL Prado. I developed the device for my previous MY2016 and it worked reliably for several years. I unplugged it from the old 2017-delivered GX before trading the car in on a 15-month old GXL.

Recently I got around to connecting it up to the 2023 model and I can't get any data out of the vehicle's OBDII port.

I've configured the interface to the CAN standard used by Toyota: ISO 15765-4 (CAN 11/500). That is, 11-bit headers, which 0700 conforms (replacing the older 07E0 header) and a data transfer rate of 500 kilobits/second. But, no data forthcoming.

I realise that the subset of Prado owners who have a clue what I'm posting about is very small but can anyone shed some light on the lastest protocol? Eg Has the data rate been changed?

[RPP Senior Member Find all posts View Profile Close RPP]

There are 2 data rates and 2 header lengths allowed, so your CAN Bus tool might need to scan for all combinations.

According to one auto electronics site: "In modern cars, 500K and 11-bit IDs is the most common one - but external tools should verify this in a systematic way."

I find that at this point I'd be reaching for a bus analyser. Might need to lay your hands on a good CAN Bus sniffer/logger.
If u are into custom electronics and firmware then there are cheap Ardunio and Raspberry Pi based solutions around. Check UTube for DIY solutions and Github for free firmware.

[GeeWhizz Senior Member Find all posts View Profile Close GeeWhizz]

Thanks for quick response. I also have a cheap ELM327 based interface, which is supposed to automatically search for a compatible protocol. Since there are only 4 options with the ISO 15765-4 protocol, I'll manually configure the protocol settings to try each of them. The poor old "v1.5" ELM is a little crude compared to what I'm used to but there are times when I'm glad I have it.

On data rate, the options are 250 or 500 kbits/sec. Since the older Prado 150s used 500 kbits/sec, I don't think that Toyota would go for a downgrade to 250 kbits/sec. And since both the old and new packet headers fit into 11-bits (0700 and 07E0), I had (prematurely?) ruled out 29-bit headers. I'll give that a whirl too. While I don't have a CAN Bus sniffer, I do have a couple of oscilloscopes so, if trialling all four CAN protocols does not turn up a winner, I'll check the pulse timing on the CAN bus to determine what the bit rate is.

[ptommo59 Senior Member Find all posts View Profile Close ptommo59]

You were on the money with your first config ISO 15765-4 (CAN 11/500) and there was no change between your old and new Prados for base comms Protocol. The changes were switch to also supporting UDSonCAN Protocol (using Mode 22 PIDs) and changing Headers for the ECM from 07E0 to 0700 (it will still give responses to 07E0 requests for standard OBD Mode 01-09 PIDs).

This link gives a good basic overview of UDS UDS Explained - A Simple Intro (Unified Diagnostic Services) – CSS Electronics

May be check if its a hardware problem or with how your software interface initializes or configures its requests and checks for valid replies.

[GeeWhizz Senior Member Find all posts View Profile Close GeeWhizz]

ptommo59

Senior Member

Find all posts

View Profile

Close

ptommo59 Thanks for confirming that the OBD protocol and speed have not changed for the later Prados. As a process of elimination, I tried all 4 header sizes/bit rates and no joy. Next I checked the bus voltage levels at the DLC3 connector with a multimeter - I had reversed the CAN bus wires when I reassembled the DLC3 (my CAN interface box has a hard-wired connection via its own 4-pin plug/socket to the CAN wiring just behind the DLC3). After disconnecting the battery, correcting my error and reconnecting the battery, everything sprang to life. Just a little embarrassing!

The UDS document makes for great reading. I hadn't seen such a comprehensive discussion before. Thanks for the link.

My initial data capture follows. Now to test all my interface's functionality with the new header data (0700 etc).

ELM327 v1.5

>at dp
ISO 15765-4 (CAN 11/500)

>at h1
OK

>at ma
700 02 01 0C
708 03 7F 01 11
45A 5A 04 00 44 01 00 00 00 <DATA ERROR
4E0 24 00 44 01 00 00 00 00
700 03 22 1A A0
708 03 7F 22 31
45A 5A 04 00 44 01 00 00 00 <DATA ERROR
4E0 24 00 44 01 00 00 00 00
700 03 22 1F 78
708 10 0C 62 1F 78 07 04 30
45A 5A 04 00 44 01 00 00 00 <DATA ERROR
STOPPED

>

[ptommo59 Senior Member Find all posts View Profile Close ptommo59]

Had a quick skim through you data capture and thought may be worth giving you some feedback:

I believe the ECM will only respond to Service ID / Mode 22 requests on 700 so anything you are after from Mode 01 set the header to 7DF (all ECUs supporting will reply) or 7E0 (only ECM will reply)

The Current Gear request 700 03 22 1A A0 is an invalid code that will only work on a Scangauge as it has an obfuscation offset applied (which is why you got 7F back) . Use 700 03 22 16 21 as that is the correct code (To pick any Scangauge code that are obfuscated look for a C at the start of the RXF).

The EGT request 700 03 22 1F 78 should have a second frame but you interface seems to be outputting the 45A Data Error lines after each reply so not certain what is triggering that.

Any of the 700 03 22 1F XX codes will also work as 7DF or 7E0 02 01 XX as the ECM duplicates all the mode 01 parameters on 22 1F.

Here is a few extra links that I use that may be useful to you if you don't already have in your favourites:

OBD2 PID Overview [Lookup/Converter Tool, Table, CSV, DBC] – CSS Electronics

OBD-II J1979 PID Listing

Binary/Decimal/Hexadecimal Converter

UDS Protocol Tutorials ⋆ EmbeTronicX

Diagnostic Message — py-uds 1.1.0 documentation

Hope that is all useful :-)

[GeeWhizz Senior Member Find all posts View Profile Close GeeWhizz]

Thanks for the analysis of the data that I'm sending and receiving. Your insight has helped my (re)learning process considerably - I went though a long and tedious learning process when I developed my original hardware and software between 2017 and 2022.

The packets with the 45A header are unlikely to be related to my data requests. From my previous experience with my MY2016 Prado and earlier 2013 Kluger, data frames with heasers in the 4xx, 5xx and 6xx range were a Toyota proprietary data broadcast format which appeared to mainly relate to the Audio Visual system, door and door lock states and other services handled by the BCM. Being proprietary, they do not conform to general CAN standards and would regularly throw up error messages from the ELM327 chip (possibly relating to differing checksum formats). My guess at the moment is that the 45A and 4E0 headers that I am receiving are a remnant of the previous era of CAN nodes that are still in the system.

Thanks also for the document links which, once I've worked my way through them, should prove to be very useful. The only one that might be redundant is the number format converter - I have a long history of hardware and software development from the early microprocessors in the 1970s through to modern microcontrollers.

[RPP Senior Member Find all posts View Profile Close RPP]

Nice work.
If u uncover any useful discoveries please post here.

[ptommo59 Senior Member Find all posts View Profile Close ptommo59]

I just use a serial port monitor while running Techstream live data pages to do my data capture and then analyze the results looking firstly for the mode 01 codes that I knew were present in the stream and working from there. Interestingly enough the codes for quite a few were following the parameter layout/order on the Techstream pages.
A couple of things to be aware of is that UDS uses the 22 XX 00 PID to do the mapping of all supported PIDs in that XX block from 01-FF (same sort of thing as Mode 01 00/20/40/60/80/A0/C0/E0 do but in one response. So pretty easy to know what PIDs are valid then just need to workout what they relate to (luckily there are quite a few that are single parameter or like parameters grouped together).
If you try what I do you may find codes you are expecting to see are missing but the reason why is they use Service 2C DynamicallyDefineDataIdentifier
to define a batch of parameters/supported codes within a single request with a single PID number and then pull the data out from the relevent byte positions in the response to that code before processing.
Happy to try to provide any other info or assistance I can to both of you.

[ptommo59 Senior Member Find all posts View Profile Close ptommo59]

I should have mentioned that in the CSS Electronics link above, if you navigate back to main menu it has an option at the top called Guides, if you open that there is a world of info on all things vehicle comms and how they work so worth a read or download copies of any PDFs, relevant application examples and the generic OBD DBC file for reference.

Something came up on the Scangauge Fb group which made me think that may be worth an experiment as the SGs and many other gauge type systems can only read the ECM DTCs but lots of people are having issues with the VSC/ABS etc and nothing shows when they do a scan. Should be pretty easy to do a custom command like for Forced Regen to get DTCs from other ECUs so may have to have a play.

[natalie321 Lurker Find all posts View Profile Close natalie321]

I should have mentioned that in the CSS Electronics link above, if you navigate back to main menu it has an option at the top called Guides, if you open that there is a world of info on all things vehicle comms and how they work so worth a read or download copies of any PDFs, relevant application examples and the generic OBD DBC file for reference.
Retro Bowl game
Something came up on the Scangauge Fb group which made me think that may be worth an experiment as the SGs and many other gauge type systems can only read the ECM DTCs but lots of people are having issues with the VSC/ABS etc and nothing shows when they do a scan. Should be pretty easy to do a custom command like for Forced Regen to get DTCs from other ECUs so may have to have a play.

Have you tried creating custom commands to retrieve fault codes from other ECUs besides the ECM, like VSC or ABS? If so, what OBD architecture are you using or any tips for setting it up?

[ptommo59 Senior Member Find all posts View Profile Close ptommo59]

Sorry still haven't tried that yet but all ECUs depending on standard they support output DTC info in response to same mode/service request and reply in same message format so you only need to send the command/s to the correct ECU and use common decode schemes.

On Toyotas they use common ECU IDs e.g:

741 - 4X4
750 - Main Body
780 - Airbag
781 - Precrash
790 - Radar Cruise
791 - Precrash2
7A1 - Steering Assist
7A2 - Park Assist
7B0 - ABS/TRAC
7C0 - Combination Meter (dash)
7C4 - Aircon
7D0 - navigation
7E0 or 700 - Engine and Trans if controlled by ECM
7E1 - Transmission where not controlled by ECM
7E2 - Hybrid Systems

Some ECUs will allow you to access Active DTC using Mode 03, Pending DTCs using Mode 07 and Clear DTCs using Mode 04

Others that support UDS use Service 19 to access Active and Pending Codes and Service 14 to clear them.

If you search online for those Modes/Services should be a wealth of info on how to format the request and how the reply is structured.

Hope that gives you something to start with if you want to have a crack yourself.

[ptommo59 Senior Member Find all posts View Profile Close ptommo59]

GeeWhizz

Senior Member

Find all posts

View Profile

Close

GeeWhizz was doing a quick skim on the ELM327 AT commands and was wondering if based on output in your earlier message you have been allowing long messages with AT AL so you can get Multi-Frame message onto your interface or not. The ELM327 interface is defaulted to NL (Normal Length) which limits message data length to seven bytes which aligns with you only seeing Single or First Frames.
Thought was worth mentioning.

[GeeWhizz Senior Member Find all posts View Profile Close GeeWhizz]

GeeWhizz

Senior Member

Find all posts

View Profile

Close

GeeWhizz was doing a quick skim on the ELM327 AT commands and was wondering if based on output in your earlier message you have been allowing long messages with AT AL so you can get Multi-Frame message onto your interface or not. The ELM327 interface is defaulted to NL (Normal Length) which limits message data length to seven bytes which aligns with you only seeing Single or First Frames.
Thought was worth mentioning.

While I do have an ELM327 interface with "v1.5" firmware, I occasionally use it to monitor the OBDII port using a double adapter when nothing seems to add up. My working interface uses an STN1110. I started this thread back in March with I first tried my CAN interface that had previously worked perfectly on a MY2016 GX but nothing seemed to work on my 2023 GXL.

[ptommo59 Senior Member Find all posts View Profile Close ptommo59]

GeeWhizz

Senior Member

Find all posts

View Profile

Close

GeeWhizz the STN1110 processes the ELM327 command set so should still be able to use AT AL to see if you start seeing all parts of the multi-frame messages or can you already see them?

Out of interest what software are you using to run your working interface?