CSL '0401' Program Binary Disassembly Notes

[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.:

[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 😀

[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 ).

[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

[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.

[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.

[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).

[bmwfnatic]

Am I missing something?

You will see, I won't spoil anything.

[karter16]

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

I must say it was kinda funny when I reached the point with my research that sometimes the only thing google search was giving me in response to my query string was my own posts in this thread. Flattering, but not particularly helpful lol.

[terra]

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.

Presumably they did bump the clock speed for a reason. I suppose it could simply be that the memory fast enough for the higher clocks wasn’t available (cheaply enough) in 1999, but was by 2003

[karter16]

Presumably they did bump the clock speed for a reason. I suppose it could simply be that the memory fast enough for the higher clocks wasn’t available (cheaply enough) in 1999, but was by 2003

Yep great point - and indeed there actually IS an easy way to test this:


db_performance_control() runs in the Master and Slave background tasks. db_tbgnd, db_tbgnd_av and db_tbgnd_max give the current, average and max interval times between runs of the background task.

[heinzboehmer]

Yep great point - and indeed there actually IS an easy way to test this:


db_performance_control() runs in the Master and Slave background tasks. db_tbgnd, db_tbgnd_av and db_tbgnd_max give the current, average and max interval times between runs of the background task.

What is the background task in this context? Is it what gets scheduled when the system is idle? Or is it actually doing work?

[karter16]

What is the background task in this context? Is it what gets scheduled when the system is idle? Or is it actually doing work?

Sorry should have made that clear. It's essentially "main()" for the OS. It consists of a while(true) loop and continuously executes when no higher-priority task is running. It's actually doing work, a large number of non-time-critical functions (e.g. table lookups with slow moving inputs like tmot, etc. etc.). So in the true sense of the word it's not really actually a "task" as such in that it's not triggered by interrupt/scheduler.

[heinzboehmer]

Sorry should have made that clear. It's essentially "main()" for the OS. It consists of a while(true) loop and continuously executes when no higher-priority task is running. It's actually doing work, a large number of non-time-critical functions (e.g. table lookups with slow moving inputs like tmot, etc. etc.). So in the true sense of the word it's not really actually a "task" as such in that it's not triggered by interrupt/scheduler.

I see.

So what I'm hearing is that we can pipe `db_tbgnd` out through CAN, then run the car for some period of time and work out average CPU utilization?

[karter16]

I see.

So what I'm hearing is that we can pipe `db_tbgnd` out through CAN, then run the car for some period of time and work out average CPU utilization?

Yep that's exactly what I'm thinking. Ideally need to do it on both an HP and a non-HP, however I'd have to port the CAN logging to a non-HP version of the code :-)