After much digging I at least found the pinout in some Mercedes shop software.

But unsurprisingly the #startergenerator didn't send any messages on its own on the #CAN bus when hooked up to 12V.
It did draw 11 mA tho, so at least the pinout seems correct and the controller appears awake.

Trying to send some #CAN messages to the #startergenerator didn't prove successful either.
I'm not well versed in CAN, but the dongle just kept trying to send the single message on repeat.
So I guess it didn't receive a CAN ACK?
Afaik, all transceivers in a bus should ACK a frame, no matter if they're addressed or not.

Not sure why it didn't work. Maybe I was on the wrong baud rate or this device behaves weirdly and only sends ACKs after getting a magic message?

#CANhacking #carhacking

Another mystery I couldn't solve yet: Which #automotive #connector is this?

After some research, it looks pretty similar to some variant of the AMP MCP series, but I could not find an exact match.

Dimensions:
Outline WxH: 21.35 x 16.5 mm
Depth: 21mm
Centerline pitch: roughly 4mm

Found the connector after much searching!
It's a TE "MCON 1.2".
But it's unavailable everywhere, of course ^^"

Was quite hard to find, because that series is normally only available in single row or something along those lines.

And most searches only brought up the AMP MCP1.5K REC HSG, which would almost fit too in most of the important dimensions, but the outline is different.

Got out the #startergenerator again today.
But (destructively) removing the back cover of the #BSG revealed even less than I had feared...

Just a big welded(!) copper distribution plate and more plastic and silicon.

Only a hint of ceramic PCB can be seen through a tiny little hole, that's it.

Going any further than that really needs some effort and would very likely lead to damage of the power electronics, so I'll probably stick to the #CAN fuzzing / information digging approach for now...

Fuck yeah! Finally got _any_ #CAN output out of the #MHEV #BSG!

I'm glad it actually was something stupid ^^
I did test it with and without 48V connected in the past, but apparently I neglected to connect the two GNDs (power and signal GND) together.
I did now and the behaviour changed completely.
It now draws 250mA instead of 11, goes into sleep (0mA) after 5s of no CAN activity and most importantly, spews out a bunch of messages after detecting any CAN activity, wohoo \o/

#CANHacking

Another minor stumbling block was that #CAN H/L were swapped, compared to what I had gathered from the official(?) wiring schematics. (But everything else was correct).
Idk why, but I triple checked it again and they're definitely the wrong way around in the documentation. Interesting :D

Now I can finally get to the fun part of actually trying to send the #BSG all the many many messages it wants to see and figuring out what values it needs, to do anything at all ^^

Update time:
At the end of December I implemented most of the messages the #startergenerator wants to see.
I knew I got it right enough because the 7 DTC codes it was previously spitting out shrank to just 1. The ones that went away were something like "communication failure power train controller", but the one remaining DTC was a bit disheartening...

"P143468: Imob_E_LOCKED - The driving authorization has not been released."

But it looks like some kind of structured data (see attached image, a normal firmware doesn't look like this, ime). Almost looks like many structs after each other, but idk. Maybe some weird #AUTOSAR thingy?
I also threw #Ghidra against the dump with some of the suspected architectures (#MCP5xxx, #PowerPC, #Tricore), but none returned any plausible looking instructions.

If anyone has an idea how the firmware of a Mercedes / Bosch ECU from ~2016 could be structured, hmu. 

So now I have a lot of loose threads to follow, but none of them seems immediately promising:
1) Build own 5-phase motor controller
2) Gain some key CAN logs to reverse engineer the #FBS4 personalization and activation procedure
3) Find a way to read the firmware dump to:
a) rev-eng FBS4
b) understand just enough of FBS4 to patch it out
4) ???

If somebody would be interested in helping me solve that firmware puzzle, I'd be very happy!

I got a bit more progress in on the #startergenerator.
Massive thanks to @SDRHoernchen for finding the exact ST SPC5 from the die marking and @blazra for the VLE hint.
(And ST for not putting the reference manual behind a NDA)

With that information I could start actually #reverseengineering the firmware in #Ghidra.

I already found some CAN handling.

The decompiler really struggles with the r2/r13 SDA/ToC registers and almost never resolves them to the actual memory address accesses though :/

In the end of June, I found out how to fix that pesky r2/r13 register problem.
I had to mark r2 and r13 as "unaffected" in a few "ppc_64*.cspec" files in the #Ghidra Processors/PowerPC/data/languages folder.

Then, most memory accesses got resolved correctly.
Probably not the best solution, but it worked.

And I could finally dive head first into the actual reverse engineering.

I spent many dozens of hours losing track of time in #Ghidra (I swear, it's worse than #Factorio)

Until I had figured out the #CAN message handling, signal parsing and where and when which #DTC codes get set.
With that knowledge I could figure out, slowly but surely, what the #startergenerator needs to run.
Even #FBS4 was pretty trivial to circumvent (a single 1 written to the right memory location via #XCP)

And after implementing the ~25 CAN messages in my STM32 code I finally got this today:

There's still a lot left to do.
I need to implement the #XCP stuff into the STM32 firmware, so it can run the #startergenerator stand-alone.
Stuff like:
- Checking the firmware version on the ECU, so it doesn't poke the wrong memory address
- Reading and parsing the status of the motor
- And actually controlling the motor properly instead of just sending it a hardcoded 1 Nm torque request :D

And then also cleaning it up enough, documenting and testing it thoroughly, so it can be published.

We also did a max RPM test of the #startergenerator using one of @patagona's rescued Pylontech batteries, because the 20A of my 1kW lab PSU weren't enough :D

I set the torque limit to 0.7 Nm (out of 55), no RPM limit and let it rip :D
It reached a peak of 43A (~2kW) at the end of the acceleration, settled at 25A (~1.2kW) and reached a peak RPM of 13400.

It was a bit scary tbh :D
(Not sure if the video accurately captured the sound it made)

(Pylontech thread: https://chaos.social/@patagona/113149877881417810 )

The general control loop is also pretty impressive, the engineers at #Bosch SEG definitely did their job well.

The lowest limit I can set is 6 RPM and it runs buttery smooth.

And it has insane amounts of torque. If you hold the pulley really tightly, it slips out of most strong hands at around 6-7 Nm (as reported via the CAN status messages).

This will be really fun once put into some small vehicle :D

(It can also recuperate really well, but can't run in reverse at all)

#startergenerator

Today, I've built a "temporary" test stand, so I can hopefully test the (thermal) performance of the #startergenerator in the coming days.

It was a welcome excuse to finally dabble in some metalworking again :D

Also, those belt tensioners really need quite some force.