From Denso A2L:
Scm_AccPWM_Pts  "Acc. pedal PWM position"
Sfi_LnrAFCmp_bank1      "Linear A/F compensation"

But again. If you can dissasembly something with existing A2L then other similar binaries (including polestar) can be analyzed by analogy.

PS thanks for response generation algorithm for Denso.

It's much simpler than that.

And


It is contained in the DSA files

Where can I find DSA files?

I've added some more none polestar stuff.

S60 RD 3.0 T6 Ori and Stage 2+ and Map pack

I use a "home made" hardware solution to read write directly by odb2.  its essentially an MCU and a can transceiver.   Once you have logged an ECM reload with Vida you literally have everything you need to know about how  to interact with the ECM.  Of course these odb2 methods use the pin code where as bench readers like auto tuner, kess and  the like dont need the pin, but removing the ECM is a massive PITA.

Gotcha! That is what I figured. Any ideas if these bench readers would have all the maps properly defined or would there be any limitations? I have an auto tuner kit so I could test it out if it is worth the work of removing that ECU...

Thanks for the information

I was asking because there is a guy claiming to say that it can do everything. He is doing his S60s with a tuner from europe and while he is in the states. I found that a bit weird cause otherwise every one would be doing this.

Again, thanks for the reply

For writing your own SBLs, you can use this as a reference https://github.com/fenugrec/npkern

I do not know how the maps and main ECU code are organized, if they are separate again or not, however if they are, what I found that helps is stitching together all of it in a single idb in IDA,Ghidra. This helps immensely in data referencing.
If something like DHA did exist for P3 it would have been the best outcome. Having 100+ memory addresses already named helped a lot.

It may not be relevant, but I am attaching my most up-to-date P2 Denso idb.

Additionally I have a question. I have identified a few maps which I believe are related to the fueling. After many many hours I have determined that these values are Lambda values with a factor of 0.000030518. However I naively expected a single map to affect the final lambda value, in reality, to a single map value, there were many additions, multiplications, substractions. Of course these values were then added to various other values, which themselves were computed similarly, to get a Final Target Lambda. How the Lambda gets computed to injection time is still unknown to me.
However I began to question something and that is if the car operates in open loop which is during acceleration, which means at that point, the car must use separate maps for this. If I was looking to things related to Lambda and thus the oxygen sensors feedback, this means I was looking at closed loop maps, and not open loop maps?
Maybe this is about as much can be done statically without logging real-time data.