CSL '0401' Program Binary Disassembly Notes

[bmwfnatic]

Am I missing something?

You will see, I won't spoil anything.

[karter16]

It was only a matter of time before someone decided to commercially package the various developments the community has made over the past few years. and to be fair to them it's a pretty decent amount of work to bring that all together in the way that they have.

I think he won’t be that happy when he sees what karter16 has made, bye sales 😀

🙃

They explained it in a bit more detail in the video. Doesn’t seem as bad as I thought as it’s sort of a hack way into running a wideband. As I understood it, they’re not doing any ADC conversion on the board, just taking wideband info via CAN (hope that’s fast enough) and interrupting the narrow band O2 sensor response in the middle. Also sounds like they haven’t written/tested/released this yet so we’ll see.

This by itself doesn’t really get you all the good stuff a wideband factory DME does, it seems like they’re after lean cruise to save fuel. But it could certainly be an improvement and better cruising fuel economy isn’t a bad thing.

edit: no doubt they’ve developed this after following karter16’s work at least in some capacity

Yeah I'm not sure about the Wideband approach either and using CAN for this. Firstly the approach is super hardware-heavy with that board as heinzboehmer noted, and secondly means CAN is now in-the-loop of critical engine functions (which it isn't otherwise for the MSS54 at least). I presume they're using a 10ms CAN frame, and the narrow-bands are read every 10ms so technically it is fast enough I think, but yeah...

I don't really see what this approach gets them over the approach MpowerE36 https://nam3forum.com/forums/forum/e...s50#post368639 is taking on the MSS50 which seems more elegant to me.

Side Note: I chuckled over their statement that the narrowbands don't provide for closed loop above 2000rpm.

Paid a bit more attention on today's watch and their argument about the extra EEPROM capacity in the HP not actually being necessary is interesting. IIRC, the bigger chips have faster read/write speeds too.

There's a hard bound for rate monotonic scheduling (guessing that Siemens used this approach) right around 70% utilization, where you can no longer guarantee that you'll service all running tasks in time. No big deal if your smart toaster's screen skips a frame, but a pretty big deal if your car's engine isn't actively managed for some number of revs.

I wonder if they were getting close to the limit of CPU utilization with the added CSL routines (+ all the SMG ones) and managed to squeeze out enough performance with the faster chips.

They throw around a 70% figure and say things like "utilization" and "memory", but I think they're misusing the terms and actually mean to refer to the amount of required space the FW takes up in the EEPROMs. The number itself is prob just a coincidence.

Yup I think you're right. The OSKAR OS task scheduler does use roughly rate monotonic scheduling (with a couple of minor variations for specific tasks that don't run in the main operating mode). Essentially the 1ms task is run directly from the timer ISR, the angle (Crank Segment) task is next highest and then it cascades down in roughly task frequency order.

I'm pretty sure the main reason BMW went to the HP is that they needed more parameter (tune) space. 0401 only *just* leaks into the second half of the program ROM that the HP added, but consumes the majority of the doubled parameter space. It's definitely possible that it was a CPU utilisation issue as well, but I don't really have a good way to evidence / prove that, without making a cut down version of 0401 and trying to run it on a standard MSS54.



Couple of other observations:

- I looked about 18 months ago at doing similar to what they are doing with the data logging DS2 pages (e.g. re-order or change them to get more useful data out that means you don't have to read all the pages at once). I decided against this as doing this would break every other data logging tool out there (given the pages of data the DME sends out won't match BMW's definition of the payload). I'm pretty sure you're going to be locked into using their own logging tool, at the expense of everything else. I *think* this change will also impact some data reading features of INPA, ISTA, etc. as well.

- I'm a bit surprised that they're looking to do their replacement HFM over CAN as well - the stock HFM sensor is sampled from the AD every 1ms, the fastest they can do over CAN is 10ms. Possibly they're offloading some sort of smoothing onto a companion board or something, but again I don't really see the point of doing it that way. I appreciate that CAN is a "more modern" solution, but modern isn't necessarily better when you're working with hardware that wasn't designed for it to be used in that way, and there's a perfectly good ADC sitting there that can sample at 1ms resolution.


They’ve obviously put a lot of work into bringing this all together and good on them, and sounds like they have more plans to build out that eco-system. I guess really what you’re paying for is the support and a system that all works together, so in that context $1500 is probably a reasonable deal for people who "just want something that works"(TM).

[heinzboehmer]

Paid a bit more attention on today's watch and their argument about the extra EEPROM capacity in the HP not actually being necessary is interesting. IIRC, the bigger chips have faster read/write speeds too.

There's a hard bound for rate monotonic scheduling (guessing that Siemens used this approach) right around 70% utilization, where you can no longer guarantee that you'll service all running tasks in time. No big deal if your smart toaster's screen skips a frame, but a pretty big deal if your car's engine isn't actively managed for some number of revs.

I wonder if they were getting close to the limit of CPU utilization with the added CSL routines (+ all the SMG ones) and managed to squeeze out enough performance with the faster chips.

They throw around a 70% figure and say things like "utilization" and "memory", but I think they're misusing the terms and actually mean to refer to the amount of required space the FW takes up in the EEPROMs. The number itself is prob just a coincidence.

[heinzboehmer]

edit: no doubt they’ve developed this after following karter16’s work at least in some capacity

If nothing else, the models that have likely been used to help the development have 1000% been trained on karter16's work.

[Bry5on]

They explained it in a bit more detail in the video. Doesn’t seem as bad as I thought as it’s sort of a hack way into running a wideband. As I understood it, they’re not doing any ADC conversion on the board, just taking wideband info via CAN (hope that’s fast enough) and interrupting the narrow band O2 sensor response in the middle. Also sounds like they haven’t written/tested/released this yet so we’ll see.

This by itself doesn’t really get you all the good stuff a wideband factory DME does, it seems like they’re after lean cruise to save fuel. But it could certainly be an improvement and better cruising fuel economy isn’t a bad thing.

edit: no doubt they’ve developed this after following karter16’s work at least in some capacity

[Slideways]

I think he won’t be that happy when he sees what karter16 has made, bye sales 😀

Am I missing something?

Oh man that would be very cool. As Bryson says that would be a massive rewrite. It wouldn't just be about the actual code changes, but also the amount of research and investigation to understand, to extreme detail, how the MSS54 currently ingests the narrowband, plus how something like the MSS70 uses a wide-band and then figuring out how to bring them together. There's also all the hardware considerations (e.g. are there appropriate ADCs available on the MSS54, etc.). For the Civ fans it would be deity level difficulty. Not to say it couldn't be done, but it's certainly beyond my ability (although to be fair I think I said that about the CAN logging changes as well at some point, so maybe future-me will surprise myself ).

[bmwfnatic]

Potential wideband sensor integration for MSS52 and MSS54/HP

I think he won’t be that happy when he sees what karter16 has made, bye sales 😀

[heinzboehmer]

Potential wideband sensor integration for MSS52 and MSS54/HP

Very cool.

ESP32 for the (still in development) wideband board is an interesting choice. Wonder how that will hold up to engine bay temps/vibrations/etc.:

[Slideways]

Potential wideband sensor integration for MSS52 and MSS54/HP

[Niklas]

Hi all,




I'm running an E46 M3 with an M54B30 + MS43 swap, keeping the original

SMG II. A Teensy-based gateway emulates the MSS54 side of the private

SMG CAN bus (0x310-0x314) for the SMG II TCU.




Thanks to Martyn's bench log (post #20) I got a long way. In return,

here is what I found by testing against the TCU's own diagnostics

(Tool32 SMG2 status_fahrzeugtester_lesen, ERRVAR ALIVE/SI DME10-15):




- 0x311: alive counter in byte2 high nibble, checksum in byte7

- 0x312: alive counter in byte0 low nibble, checksum in byte1

- 0x313: no counter, checksum only

- 0x314: alive counter in byte1 high nibble, checksum in byte5

- The checksum is "constant minus a sum of selected data bytes minus

the counter". Which bytes are included differs per message.

- 0x311 byte1: bit6 = brake light switch, bit7 = brake light test

switch, bits 0-1 = pedal high bits.




Happy to share full details with anyone interested.




All ALIVE/SI flags are now 0, and faults 129, 151, 153, 154 and 155

are gone. One fault remains active as soon as the engine runs:




128 "Fehlerhafte CAN Botschaft / CAN Busfehler"

CAN-Botschaft-Fehler = 0, CAN-Empfangs-Sende-Fehler = 32519 (0x7F07)




The gear display blinks as long as this fault is active. Things I've

already ruled out: bus termination (60 ohm), extra traffic on the bus,

0x315, 0x720, and the hardwired RPM signal (matches CAN).




My guess: the TCU expects the MSS54 to respond to its own requests in

0x410-0x412 (torque/idle intervention), and my gateway doesn't

answer them yet.




Could anyone with a working SMG car log the PRIVATE SMG CAN bus

(between the MSS54 and the SMG II TCU, not the chassis CAN) with the

engine running? Even 30 seconds would be enough: idle in N, select 1st,

a short pull-away and a couple of shifts. A raw log of 0x310-0x314 and

0x410-0x412 would answer the remaining questions.




If anyone knows how the MSS54 acknowledges the 0x410-0x412 requests,

that would help a lot too.




Thanks!

That is virtually impossible, as SMG (MSS54) and SSG (MS43) are completely different. With SMG, the DME handles the clutch position control; this function does not exist at all in the MS43 and would have to be retrofitted—which is completely pointless.

[Camar81]

Hi all,




I'm running an E46 M3 with an M54B30 + MS43 swap, keeping the original

SMG II. A Teensy-based gateway emulates the MSS54 side of the private

SMG CAN bus (0x310-0x314) for the SMG II TCU.




Thanks to Martyn's bench log (post #20) I got a long way. In return,

here is what I found by testing against the TCU's own diagnostics

(Tool32 SMG2 status_fahrzeugtester_lesen, ERRVAR ALIVE/SI DME10-15):




- 0x311: alive counter in byte2 high nibble, checksum in byte7

- 0x312: alive counter in byte0 low nibble, checksum in byte1

- 0x313: no counter, checksum only

- 0x314: alive counter in byte1 high nibble, checksum in byte5

- The checksum is "constant minus a sum of selected data bytes minus

the counter". Which bytes are included differs per message.

- 0x311 byte1: bit6 = brake light switch, bit7 = brake light test

switch, bits 0-1 = pedal high bits.




Happy to share full details with anyone interested.




All ALIVE/SI flags are now 0, and faults 129, 151, 153, 154 and 155

are gone. One fault remains active as soon as the engine runs:




128 "Fehlerhafte CAN Botschaft / CAN Busfehler"

CAN-Botschaft-Fehler = 0, CAN-Empfangs-Sende-Fehler = 32519 (0x7F07)




The gear display blinks as long as this fault is active. Things I've

already ruled out: bus termination (60 ohm), extra traffic on the bus,

0x315, 0x720, and the hardwired RPM signal (matches CAN).




My guess: the TCU expects the MSS54 to respond to its own requests in

0x410-0x412 (torque/idle intervention), and my gateway doesn't

answer them yet.




Could anyone with a working SMG car log the PRIVATE SMG CAN bus

(between the MSS54 and the SMG II TCU, not the chassis CAN) with the

engine running? Even 30 seconds would be enough: idle in N, select 1st,

a short pull-away and a couple of shifts. A raw log of 0x310-0x314 and

0x410-0x412 would answer the remaining questions.




If anyone knows how the MSS54 acknowledges the 0x410-0x412 requests,

that would help a lot too.




Thanks!

[ppm008]

You are right.
The bug was also fixed for MSS54 nonHP in 322_1701, but never for CSL

[karter16]

Karter16
You are amazing
This bug was fixed in 323_1801 (M3 MY 04 first M3 MSS54HP)
But thats only a very small bug in SMG clutch learning behaviour

Interesting! so BMW fixed for the standard M3 when they moved to the MSS54HP, but never bothered publishing a fix for the CSL specifically right? As you say it seems to be a pretty small bug, would be a bit of an edge case I think to cause any issue.

[ppm008]

Karter16
You are amazing
This bug was fixed in 323_1801 (M3 MY 04 first M3 MSS54HP)
But thats only a very small bug in SMG clutch learning behaviour

[karter16]

Found a bug in the SMG background task:



The error check conditional checks LA1_ED twice. The second test should be LA2_ED....