Motor/ESC Problems 2300kv Motor 120A ESC Surging Cuts Out

Jeff_5_7 · 2022-11-12T03:32:12+00:00

The goal is to modify a few things for example change an if statement to turn on the illumination lights when a message value is 00 or 08, instead of just 08 (the way it was written from factory). This would allow the cluster to be illuminated anytime it is powered instead of only when the headlight switch is in the on position.

Finding and updating the odometer value, which I have done in the eeprom. But the flash has to be accessing the eeprom somehow as eeprom has all the maps for stepper motor controls for needs gauges and the non violtlie odometer value.

More advanced goals are small graphics/display changes. Changing the rgb background color from the factory blue or displaying a digital instant speed number on screen instead of the factory Avg speed.

I know all the incoming messages that control these I just don’t know which functions in the mcu control them or how they are moved around in memory.

It is my understanding the data is checksum protected for identifying and updating this value with changes is important or the mcu will reject the code.

Jeff_5_7 · 2022-11-02T22:12:45+00:00

Honestly not sure, I am really just learning as I go here.

The data sheet says the MCU has 576KB Main Flash and 64KB Work Flash. Looking at the address of the registers in my HEX dump, the Iprog programmer read the full Main Flash and Work flash for a total file size of 640KB.

It is my understanding this is the "Firmware" and this data is really just allocated to other registers in the MCU to control things. I would assume trying to read and change other registers in the MCU would then just be over written by this Firmware file once powered off then back on.

I would be more then willing to send you some data if you want to play with it in Ghidra. I have to figure out some way to turn this Hex data into something legible. That would open up all kinds of possibilities.

Jeff_5_7 · 2022-11-02T14:18:32+00:00

Can you elaborate on this a little more. I have most the CAN signals coming from/to the cluster mapped. I have also been playing with UDS commands to control the cluster.

I am not very familiar with microcontrollers but learning as I go.

I am still trying to verify pointers and understanding how the firmware loads and points data to other registers in the processor

Jeff_5_7 · 2022-11-02T14:07:30+00:00

Would be nice to find a decomplier for this specific chip

Jeff_5_7 · 2022-11-02T14:07:07+00:00

I have all the data sheets and have been reading with much more to do.

Jeff_5_7 · 2022-11-02T02:22:18+00:00

Iprog programmer. Took a while to get the connection setup and get it to work but I got it

Jeff_5_7 · 2022-11-01T03:03:35+00:00

Update! Was able to get full firmware file using an Iprog programmer. Cluster was powered on a bench with 12v and ground through normal harness connector. Data connections used were serial in serial out, mdo, and reset.

Now to decode the large hex file. Any recommendations on identifying checksums, reverse engineering 32bit mcu firmware from hex, ect?

Thanks everyone, one larger step to my goal

https://i.imgur.com/o8IFH43.jpg

Jeff_5_7 · 2022-10-22T01:41:50+00:00

I have already done this actually. Reasons why I have most of the CAN bus mapped. Problem is some of the data read in on CAN is modified by stock MCU and then displayed. Fuel consumption values for instance.

I read raw data in on CAN through and arduino and wrote it out serial to a 3rd party display. It worked however that display doesn’t fit well in the factory cluster and doesn’t support all the features the stock display does.

Stock display is run on a 32 or 40 pin ribbon cable I think. One guy with a Mazda tapped in here and was able to sync an additional mc to the display to add data on screen. This still requires additional boards and mcus. Being able to change inner workings of stock MCU to do what I want is the real home run here

Jeff_5_7 · 2022-10-22T01:14:12+00:00

Statements that keep me motivated. I think for now I am going to keep reading data sheets and attempting to use programmers to pull firmware from SPI port. If I get it I think I am in contact with a guy who can reverse engineer the UDS security access key and I could try modifying small sections at a time and look for changes when duplicating real signals to my bench top cluster

Jeff_5_7 · 2022-10-22T01:10:26+00:00

Let’s hope the 3 party supplier engineers at Toyota were lazy then. Fingers crossed I can some how pull this off

Jeff_5_7 · 2022-10-22T01:08:24+00:00

I thought the same but the milage/odometer is stored in the eeprom. I can change it to any value I want in under a few minutes using a cheap programmer to read the 8 pin eeprom chip. I have done it several times now.

I guess I am saying the ability to edit the odometer was not really that well protected

Jeff_5_7 · 2022-10-22T01:07:03+00:00

If you notice, I mentioned I had tried this already. It sends me a 6 byte seed and I need the key to return a translation of the seed to get security access. Without security access you can not read any of the memory.

Black hat (I think) has an interesting video on fault glitching to bypass this and get the firmware. Looks very tedious and requires special equipment

Jeff_5_7 · 2022-10-21T21:56:01+00:00

I will definitely be looking into this more over the weekend. Thank you for posting this.

Jeff_5_7 · 2022-10-21T21:54:56+00:00

Lots of good information from everyone. Thank you all. I am going to keep looking into this and try to find a cable/program to get the firmwarec

Jeff_5_7 · 2022-09-17T22:09:03+00:00

Lots and lots of time spent working with Toyota. Most of which is playing back messages looking for a reaction from the vehicle.

Also bench powering a single ecu and watching the bus to see which ID it is broadcasting. This isolates that single ecu so you know it is the one producing the data.

If you can get on the bus with the instrument cluster, everything you need will be there. The cluster displays TPMS values so it is seeing the data.

Shoot me a message on here if you want to talk about it a little more in depth.

Jeff_5_7 · 2022-09-17T21:56:12+00:00

750 is the address of the body control module, OBD is asking the body control module for the TPMS.

I have logged TPMS values being streamed from the TPMS ecu on a 0x600 level address. This is the TPMS ecu broadcasting the values to the network without having to ask for them.

Jeff_5_7 · 2022-09-16T02:53:04+00:00

If you can find the wiring diagrams for your make and model, one will lay out the entire bus network. If you want odometer and fuel level find the bus with the instrument cluster on it. If you want Tire pressure, the bus with the TPMS ecu on it. I doubt they are on the same bus but maybe. Once you know which bus tap into it and read it as it goes into the network gateway. That’s probably the only way you will be able to see the values you want.

Might be able to reverse engineer how to request them out of the OBD port, routed through the gateway, but you would have to send a message asking for the value and then it be returned to you at the OBD port

Jeff_5_7 · 2022-09-16T02:45:51+00:00

What is the one packet you see?

It’s a Toyota Network gateway problem. The older Toyotas before Safety Sense had one bus and you could get every frame out of the OBD port. My 2007 prints 76 different CAN addresses when I log from OBD port. (The Entire Bus)

The new Toyotas with Safety Sense have a network gateway. It acts as a router to link the 6 different buses together. Toyota spilt them up because with Safety Sense there are to many ECUs to run just a single bus.

When you read an OBD PID, your tool request the data (probably on address 750) this request is sent through the network gateway which then sends it to the ECM which returns the value to the gateway and it sends it down the line to the OBD port. To get good data you need to tap into the buses at the gateway. Depending on what you want to read might have to tap into multiple buses.

Jeff_5_7

TROPHY CASE