E92 PCM Reverse Engineering

[Gatecrasher]

The SPS log looks just like anything else. It's the disassembly I'm looking at. Nearly all of the API and return codes line up with the documentation.

Here's some documentation for it.

https://www.st.com/resource/en/user_man ... ronics.pdf

I've got an older version of the driver with sample source code, documentation, and binaries for the driver itself.

If I'm reading this right, it should be applicable to any MPC56xx chip with a C90FL flash module.

The 2017 kernel I'm looking at lines up more with the dual bank C90FL2 documentation, even though the 5674 is a single bank chip. I haven't looked around to see if there's a code download for the newer one.

You'd still need to write your own read routines, but that's relatively easy compared to the write part, no? The Freescale license seems to be "do whatever you want with this. Just don't bother us if it doesn't work."

LICENSE GRANT. Freescale grants to you, free of charge, the non-exclusive, non-transferable right (1) to use the Software, (2) to reproduce the Software, (3) to prepare derivative works of the Software, (4) to distribute the Software and derivative works thereof in source (human-readable) form and object (machine-readable) form, and (5) to
sublicense to others the right to use the distributed Software. If you violate any of the terms or restrictions of this Agreement, Freescale may immediately terminate this Agreement, and require that you stop using and delete all copies of the Software in your possession or control.

[bubba2533]

Yeah, can you share the SPS log? Or is that not something that's ok to distribute?

[Gatecrasher]

I can, but I'll need to sanitize it first.

[Gatecrasher]

I probably went overboard with this, but it should still be useful.

[bubba2533]

Thanks for that. I finally got around to take a look.

Ok, so I think I've come to the next most difficult part for me. I've been trying to reverse engineer all the FLEXCAN routines, but I'm not sure it would even be good practice to use those functions since there could be different versions of bootloaders that could change the location of the functions, which would break the kernel.

So the kernel is in need of a ISO 15765 compliant Transmit and Receive functions. I think the next big milestone would be to dump the ROM, which would at a minimum require a ISO 15765 Transmit function that would be capable of sending more bytes per transfer/request.

I've been looking at the structure of the PCM Hammer kernel as a reference, but there will still be a ton of work to create these functions.

[kur4o]

You can`t go over 12 bytes in any message on CAN.

What needs to be done is the pcm to transfer a big chunk of data as multiframe message. Getting size and splitting each message with a 20-2f counter. The tool will combine the message to a single iso15765 one, Same goes to pcm receiving one,

Iso15765 is a software layer for CAN, on hardware [BUS] layer you only have raw CAN unformatted data.

[bubba2533]

Yes, that's why I indicated there would need to be an ISO 15765 compliant transmit/receive function. Those software functions will have to handle segmenting up to transmit and combining multiple messages when received.

[Gatecrasher]

Most of that stuff is handled in the bootloader code. Hardware initialization, CAN management and all the GM protocol stuff required of a module that doesn't have an OS installed, is handled by the bootloader. The kernel that gets uploaded to RAM consists almost entirely of the actual flash erase, write, and verify routines. Hence my statement about it being a gently modified instance of the standard NXP driver.

[bubba2533]

Yeah, but for writing a kernel I don't think it would be a good idea to use the bootloader code. I think it might be more difficult to integrate with that verses creating it from scratch. Maybe I'm wrong, but that's why I'm posting it online to get feedback.

I'm no software engineer, but it seems like someone who was could very easily write an opensource read kernel for this E92 platform. I'll be giving it a shot since I think this ECU is something I'd like to dig into a little bit more, and having opensource ability to read/write would be very nice.

[antus]

we're actually looking at this with pcmhammer at the moment. we have the asm flash kernel, and we have it working on P12, but we've noticed there is hardly any code in the factory P12 flash routines and its actually calling in to the OS code. I havnt gone too deep with it, but it looks like a jump table at a standard location in the OS, which provides an API of sorts to a library of routines that can be called. Those routines are called in order to copy the OS flash routines to ram, and then it uses them. At this stage I believe it must be standardised, so the code can move in the OS, but the jump table provides a consistant interface at known locations. This was a 2007 OS, 68K CPU, VPW protocol. But we know its all an evolution. For pcmhammer we just used the same kernel we did for the rest, with tweaks to suit the platform, and did not RE the jump table/api. But in the case of E92 and depending how complex the factory routines are it may make sense to use the inbuilt ones. The trade off is less code to write but more factory process to reverse engineer to hook in to, or go the other way and write your own, which is less factory process to RE, but more flash code to RE instead. Either option is probably workable.