CAN Bus Filter Problem | Posts 16+

I've lost track of things .

I understood that you want to communicate with a CAN bus (using the MCP2515) using an ESP32 and the Arduino IDE? Okay.

First, we need more information about the setup: specifically, how is the MCP2515 connected to the ESP32, and is the CAN bus wired correctly and properly terminated?

Then we can start testing the basic sending and receiving functions. If that works stably, I'll proceed with implementing filters, error counters, etc.

From simple to complex.

Okay, so here I am again. My mistake with the readings was simply that I always immediately replaced the 8 MHz oscilloscope with one that I thought (since I had bought it that way) was a 20 MHz oscilloscope. You were way off; it was a 12 MHz oscilloscope.

I displayed the values for water level, oil level, RPM, speed, battery voltage, and oil level in millimeters on a 4" TFT ili9488 screen, along with a bar graph for RPM. The time comes from a Neo 8M GPS module, and I'm very happy with it so far, although it was only a preliminary step for the actual project. It's about a TCU (Transmission Control Unit) from Magnetti Marelli, model CFC201F.

This ECU supposedly only sends one CAN message. Tomorrow, I will connect it to the CAN controller and find out; today, I first located the CAN lines and connections for terminals 30/31 of the ECU in the wiring diagram.

Here are my questions:

Here's the translation:

"Regarding PIDs: From what I've been able to gather so far, PIDs seem to be like "requests" that you need to send, and in response, you receive an answer from the ECU (Engine Control Unit). What I don't understand is: How are these PIDs structured? If I block all the messages I know while sniffing/filtering, will I then see a new 0x... message?" Can it be a single message, or can there be multiple bot messages at the same time?

My second question:

Regarding sequences: When I initiate the learning function for adapting the TCU (transmission control unit) gear ratios using the diagnostic tool (I already have the Y-OBD cable), who controls the actuators (valves and also the two-position sensors)? Is this a test procedure, or is this routine implemented in the control unit's software and only triggered by the tester?

There's no way to read the TCU data except with expensive testers; sometimes, you might get the PIS value displayed sporadically - what's the reason for this? It must be because the bus speed is too fast, right? Is it correct to say that you can only determine the correct bus speed using an oscilloscope?

Third question, taken from a much more distant source:

If I read the software from the TCU, can the firmware be decompiled and the code extracted?

Here's another question: How can one write to memory cells in the firmware? Does that go through the PIDs?

Thank you very much for your efforts.

I'll post a photo of my work here tomorrow.

"I'm now using an ESP32 S3 (which is really powerful). I've connected a transceiver, the MCP2551, to two digital GPIO pins, and I'm reading the bus using the ESP32's internal CAN driver. It has 32 mailboxes (filters) instead of the 6 with priority offered by the MCP2515." I'm using the TWAI driver of the ESP32 for that.

I've learned a lot, but unfortunately, not here, but rather on ferrarichat.com and nefariousmotorsports.com.

CAN / ISO9141 / Handshake / Read EEPROM and clone FOBs, disable immobilizer, etc.

I'm currently learning how to remove the eDPF (extended Data Packet Filter) and Lambda functions from the MSTG (Multi-Service Transport Gateway). After that: how to implement additional features in a machine-to-text generation system.

But, knowledge is not free.


It was interesting for me to learn when an engine over-revs. This happens when the piston speed is higher than the mechanical closing speed of the valves. In extreme cases, people use stiffer valve springs, which, of course, brings a number of negative aspects regarding the durability of the cylinder head, valves, and valve seats (due to increased mechanical stress). But all of that leans towards tuning, and in my opinion, it doesn't belong in this forum either.