2004 BMW 330 with SMG/SSG Gearbox

[Jack Bauer]

Excellent work.

[mdrobnak]

Excellent work.

Thanks!

Been working on the Arduino code a lot - at this point if the door is already opened, I can keep the system stable. Need to figure out what I'm doing wrong. But the code was cleaned up a bit (no more if count == X blocks), I'm using a simple If (this - previous) > interval style of loops, and that seems to work well - as long as you aren't doing an analogRead too often. Do it too often..and you're gonna be upset. My cycle timing was off by a factor of 2 for the longer intervals. Short intervals were fine, oddly.

Onward.

-Matt

[mdrobnak]

So it turns out that the single bolt holding in the CP ECU is really easy to remove.
So I did, and swapped the existing port / door with the eBay one. Because otherwise it's impossible to contort the assembly to fit in any way other than the correct way.

I did some tests with that and figure out this much:
* There's verification on voltages between the wall charger and the onboard charger - as it sits in "blinking blue" when it should switch to blinking green as the cable wasn't exactly connected to anything.
* It will sit in a "scheduled charge" mode just fine, so I'm going to try and reproduce that on the bench.


I also logged switching from scheduled charge to on-demand charge to see what it does. I also logged the car going to sleep (which required me to turn off bluetooth on my phone, ensure everything was closed, and turn off Teslafi), and then a wake-up about 30 minutes later.

I thought I had a cold-start solution on the bench, but when I refactored code to be less awful, not so much.

I can't wait to share a clip of my multimeter showing 120VAC on the end of the cable

-Matt

[mdrobnak]

:: sigh ::

Great news and terrible news.

Great news: playback of such sessions does what I expect, and things go about their business.
Terrible news: this works only on the ECU from the car.

I haven't tried it yet, but I think I could get my Arduino code working with the ECU from the car.

Now I need to troll the Internet for other HV / Charge port bus logs. I just looked at Damien's github for the PCS..I think HVcon_onown_poweron_off.csv is the file I'm interested in, but I'm not 100% sure.

-Matt

[mdrobnak]

So trying with the arduino code highlighted an issue. One of the 'OMG this is insane' IDs turned out to be...voltages. But, we don't need that ID.

The ID we did need...can be substituted with static values (again, multiplexed however) and that produced a blue Tesla logo.

For s___ and grins I connected the eBay ECU....and it went blue for about 0.25 seconds before going to the red logo. So it looks like the tolerances for error conditions are much tighter on the older firmware, but gives me hope to make it work! For reference, it goes through the colors so fast my Pixel 3 picks it up as a slightly shaded white lol. On a subsequent try, with stabilization off, I clearly got it to sit on blue for a second. The camera picks it up as white. Yay for bayer filters...

In any case, microscopically small progress, but forward progress again at least.

Power up is still a pain in the butt with respect to door control. To make things fun, there's also event-based CAN messages that can thrown around too....

This has been a bit more work than I anticipated to get this thing to work...

In other news I've started cleaning up the M3 harness from the horrible spaghetti monster it was, trying to do 5-10 pins a day. Should have that done in a week. Just trying to not overwhelm myself.

Haven't done the sanity checking of data on the 330 yet. Just...want to overcome this charge port challenge first.

-Matt

EDIT: LOL night mode on my phone is what did it..desaturates the blue...The video itself does show it. I'll upload a vid tomorrow with less junk around it

[mdrobnak]

Power up still an issue.

eBay ECU still not happy.

Car ECU will sit in standby for as long as I'd like it to now.

I've got control over the LED colors too, aside from white or yellow. White is only from the CP ECU when happy / latch unlocked, and yellow I have been unable to reproduce.



I have verified that I can get 120ish volts to show up at the connector, but it's not exactly easy to probe and record. There seems to be current monitoring built into the mobile connector as it eventually decides its a bad idea and shuts the relay off.

I also am sending data somewhere that says the car is locked, because the LED turns off after about 90 seconds (will reappear if you push the button on the handle, but not unlatch - as it thinks it is locked).

I need to get the mating connector now, which will eventually go on to my junction box. Then I can try wiring it up to the charger. Need to get the ratings on the contactors.

Next steps are probably further refining the existing controls, and trying to figure out what's up with the eBay CP ECU.

-Matt

[mdrobnak]

No idea what the deal is with the locked / unlocked item. Not as simple as one would like (of course).

Cleaned up the serial console / command input code greatly. It looks pretty, but doesn't do much more yet

Also found out that again it was not sending all IDs. I needed to increase the TX buffers from the default of 2 to 8! But I'm sending 26 IDs at this point....that should give you a better idea of how involved this is. I can get a white LED at times depending on timing of when I power on the ebay ecu. I can also get it to turn on the relay if the cable is plugged in when powering it on, sometimes. So it's annoyed (therefore red LED), but there's a small window in which it will listen.

Haven't looked for the mating connector yet.

Greatly cleaned up the M3 wiring harness, but that's not done yet.

-Matt

[mdrobnak]

Behold the power of ANSI color codes and positioning.

Like so:

Code: Select all

  Serial.print("Commands: ");
  Serial.write(27);
  Serial.println("[4;44H CAN Loop Status:");
  Serial.println("d / D - Open / Close door.");
  Serial.println("r / R - Start / End Rainbow / Rave mode.");
  Serial.println("c / C - Start / End Charge.");
  Serial.println("l / L - Lock / Unlock doors.");





  Serial.write(27);
  Serial.print("[15H");
  Serial.print("Activity: "); // Response on 11
  Serial.write(27);
  Serial.print("[14H");
  Serial.print("Command? "); // Response on 10[/code}
  
//  Then in the loops themselves:
// Globals
  const char COMMAND_POSITION[9]  = { 27, '[', '1', '4', ';', '1', '0', 'H', '\0' }; // 14,10
  const char ACTIVITY_POSITION[9] = { 27, '[', '1', '5', ';', '1', '1', 'H', '\0' }; // 15,11
  const char NO_ATTRIB[5] = { 27, '[', '0', 'm', '\0' };
    // CAN status
    Serial.write(27);
    Serial.print("[5;44H 10   ms: ");
    if (loop10msResult == 31) // Returns 1 for success - use bitshifting for multiple IDs - 5 in this case.
    {
      Serial.println("OK");
    }
    else
    {
      Serial.println(loop10msResult);
    }
    Serial.print(COMMAND_POSITION);
    ...

-Matt

[mdrobnak]

Moving development over to Eclipse, trying to get away from the .ino files to a normal C toolchain. There's a distribution called Sloeber which is a good intermediate - it has the right wrappers to work with .cpp/.h and .ino files. Reduced some global variables.

Bought: MISRA C 2012 PDF to try and write more safety-conscious code. I definitely need a refresher on good coding practices. Working != good, that's for sure.

* https://www.ebay.com/itm/114158760746 - End of cable connector which will eventually connect to contactors (for now just to connect AC to charger eventually)
* https://www.ebay.com/itm/2019-Tesla-Mod ... 4830121802 - Another CP ECU, lets see if this one is more cooperative.

Air quality is atrocious right now. AQI is in the 330s.

[mdrobnak]

Just got the new eBay CP ECU from a 2019 Tesla. I got the DC connector yesterday. I'll add pics later, but for now:



So, definitely need to take into account differences in firmware on these CP ECUs. 2019+ seems to be where the change was made that my code was already working for. Now I should be able to put together my trunk again for now.

Yay for progress!

-Matt

[mdrobnak]

Trying to get rid of my use of global variables. There's only a few private class variables for various states and enums that get used in multiple spots.

One thing I noticed earlier, but didn't pay enough attention, was that the LED would go out on the Charge Port at times. I thought it was because the car was "locked"...Potentially, it's that it stops transmitting:

Code: Select all

 10   ms: OK
 10   ms: OK
State: Wait CommsInit:  true Fault Line: clear
LED State: Blue Solid
Door lock state: Unlocked
Commands:  CAN Loop Status:
d / D - Open / Close door.
r / R - Start / End Rainbow / Rave mode.
c / C - Start / End Charge.
l / L - Lock / Unlock doors.
 TX High-Water-Mark: 0
 TX Maximum: 15
Activity: Command?  1000 ms: OK
 10   ms: OK
 50   ms: OK
 10   ms: OK
 10   ms: OK
 500  ms: OK
 10   ms: OK
 10   ms: OK
 250  ms: 0
 10   ms: OK
 50   ms: OK
 100  ms: 511
 10   ms: OK
 10   ms: OK
 10   ms: OK
 10   ms: OK
 10   ms: OK
 50   ms: OK
 10   ms: OK
 10   ms: OK
 10   ms: OK
 10   ms: OK
 10   ms: OK
 50   ms: OK
 100  ms: 511
 10   ms: OK
 10   ms: OK
 10   ms: 7
 10   ms: 0
 10   ms: 0
 50   ms: 0
 10   ms: 0
 10   ms: 0
 10   ms: 0
 10   ms: 0
 10   ms: 0
 50   ms: 0

For each message, Can0.write(thing) returns 1 if OK. I have code that either writes OK, or notes which message wasn't able to be sent. For instance, for the 100 ms loop in the end, the Vehicle Config (0x7FF) didn't get sent. This makes sense as it is the lowest priority via CAN ID.

As we can see though, it just gets worse from there... Everything stops.

Unfortunately the stats tell us jack sh##...

Code: Select all

 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0
 TX High-Water-Mark: 0

It's about 650 frames/sec, so it's not exactly a small load, but it is a 72 MHz processor, should be fine. Ignore the 250ms loop, that's disabled at the moment. I was getting some memory corruption seemingly. I wonder if this ring buffer is causing me issues.

Is Collin's FlexCAN library the best to use on the Teensy 3.2?

-Matt

[mdrobnak]

I thought perhaps the millis() value was overflowing, nope.
Turns out there's a piece I missed from the example that I thought wouldn't make a difference... that does make a difference.

Be sure to put static CAN_message_t - something with the allocation of memory on this hardware goes a little haywire. I had removed static from the VIN ID one, as, logically, it doesn't need to be static anymore, as it wasn't crossing function boundaries. Turns out we want static anyway.

It's been running for over two hours this morning without an issue. That was definitely the problem. Of course, as I write this...the LED went red, the CP unit restarted, but it resumed back to where it was supposed to be. Fun times.

On another note, I picked up two of these:
https://www.st.com/content/st_com/en/pr ... 767zi.html - ST Nucleo boards - 216MHz ARM Cortex M7 + DSP and a bunch of stuff.

I eventually want to try some programming with Rust on them. Built in DAC too, so maybe I can use that for my pedal voltage signal on the M3. Lots of possibilities for not too much money.

Oops, thought it had more CAN built in. Ah well. I bought two transceiver add-ons from Amazon for $10/each. Should be fun to see where I can go with them.

Edit: Putting an uptime count back in, and we're at almost 10 hours uptime no issues..I wonder if there's some capacitance thing going on with the laptop trackpad. The Teensy is currently USB powered.

[Jack Bauer]

Hope to join you on this soon. Have an eu charge port and both eu and us chargeport ecus:)

[mdrobnak]

Hope to join you on this soon. Have an eu charge port and both eu and us chargeport ecus:)

Uh-oh, now I'm in trouble! I've got 24 hours before "Jack Bauer" finds me!

I'm really torn on this work - I've dumped quite a bit of money into buying stuff for doing this testing, and ideally would like to make something out of it...
No matter what, if given a direct question I'll always do my best to put you on the right path.

-Matt

[Jack Bauer]

Ah sorry I thought this was open source. The last thing I need is another reverse engineering project so if you have a working solution I'd be happy to pay for it as I'm sure would others.

[mdrobnak]

Ah sorry I thought this was open source. The last thing I need is another reverse engineering project so if you have a working solution I'd be happy to pay for it as I'm sure would others.

Definitely need a good definition of requirements and expected outcomes then, as I'm sure you understand given your support experiences.

My thoughts so far are:
* Write code in a logical way, keeping thing as simple as possible, organized and attempt to catch unhandled scenarios.
- Not here yet. I'm probably going to attempt to rewrite this in Rust on the STM32.
* Keep the CP ECU happy.
- 75% there. No idea what upsets it when the door is closed.
* Provide signal (via CAN?) for something like SimpBMS to know when to start the charger
- State machine needs work to get the timing of everything correct, and correctly handle an attempt to remove the handle.
* Optionally provide contactor control for DC fast charge
- Default scenario would be a "simple" mode directly connected to an AC charger from the port.
* Support saving of configuration parameters
- Simple vs w/ DC charging.

I'm definitely unsure of the boundary of integration. That's the biggest unknown for me right now.

In general, I'd like to provide an integration solution for platforms I know (E46 / 996 / 997.1) at a cheaper cost than what I can do with the MoTeC stuff. The Motec stuff is great for data analysis and ease of calibration. But for most people, total overkill. So hopefully that can happen and everyone wins.

-Matt

[Jack Bauer]

Sounds good. I'd like to support you obviously and I'm totally lacking in the software dept:) What I could do is the hardware design. How would you feel about that part being opensource and people buy the firmware from you?

I have the charge port and both EU and US cp ecus so could do some hardware investigation on those and also some CAN logs if that helped. I'll start a thread in the fast charge section to avoid cluttering here.

[johu]

If you're still in CAN trouble check out the openinverter CAN module. It has very robust TX buffering

[mdrobnak]

Sounds good. I'd like to support you obviously and I'm totally lacking in the software dept:) What I could do is the hardware design. How would you feel about that part being opensource and people buy the firmware from you?

I have the charge port and both EU and US cp ecus so could do some hardware investigation on those and also some CAN logs if that helped. I'll start a thread in the fast charge section to avoid cluttering here.

Hah! Don't put yourself down you've done some pretty good stuff with the framework you're working with.
I'm good with opensource hardware, that sounds like a good plan. I've got both the Teensy 3.2 and a ST Nucleo board to work with - I see now why the STM32 was chosen for other things, it has a really nice support system.
Definitely agree on a thread in the fast charge section.

If you're still in CAN trouble check out the openinverter CAN module. It has very robust TX buffering

Looks like the static thing was the cause. If I run into other issues I'll take a look though, thanks!

-Matt

[mdrobnak]

On some non-charge port items:

Finally got all of the connectors in for the ISA shunt:

I can definitely whip up a kit of connectors for $8 + shipping for those in the US. The place Jon sent me toward not only had the kit listed at $33, there was a "minimum order" of $35, and THEN $10 shipping on top of that. I think I can send via US mail for like $4 so..$12.

I also started on determining the wiring for the Volt BMS modules, like so:

It's not entirely done yet, but it should allow me to wire up module 4 and see how that's going. I'll probably wire that up tomorrow.

Other than that, I took out both the 330 and the M3 recently, both desperately needed air in the tires.

I need to buy some more connectors of the 12 pin type as I bought 10 of each keying, and, well, I don't have enough for the 12 pin keying.
I'm also going to try and find the connectors for the charge port, mating connectors, an EEPROM...all sorts of fun stuff to play with.

I need to figure out the best way to wire up the batteries for testing.

So much to do.

-Matt

[mdrobnak]

I wired up 3, yes, three whole connections today to the first battery module. The pins for the JST ATLPB-21-2CD connectors are a pain! All of these small connectors... :-/ The molex connector used on the LG batteries were pretty easy though, so that's good.

I flashed the SimpBMS board back to SimpBMS, and ran into a few issues, which I've reached out to Tom about. (I have no idea how to change certain settings, and the Coda charger support is in the code but unfortunately not accessible due to an easy oversight.

I did some data analysis, I think I'm missing some data still to make the EU Charge Port stuff happy. Going to do a little more of that really fast, then call it a night.

Tomorrow I will wire up the other 10 cells (only doing the first connector), and see if at least voltage readings look good.
I'll wire up the ISA shunt as well.
I'll probably start on writing the ISA library tomorrow.

-Matt

[mdrobnak]

ISA shunt wired completely. Yay.
I tried to wire up the JST connectors. Turns out my crimper made things a little too wide, and that was causing issues. It got all weird and I had to start over.

SimpBMS does not like minicom. I was able to update the settings I was having issues with via the Arduino serial monitor.

I misplaced the 10 pin Molex connector for SimpBMS, so no BMS connections until then. That should arrive tomorrow. I'm also giving my fingers a rest from the crimping today.

I wanted to read some, and then try and get the RTC date change functionality working.
I read some more of the Learning Rust book, but ended up going with the slightly hacky method of handling the input. It works OK, but is decidedly not the best way. I'll post a video (with an easter egg) in the other thread. Of course, now that I have the date update working..the clock stopped.

Whatever. Need to look more closely at the functions I'm modifying. I think I shouldn't have made a change I just did for the 'set 24 hour' function.

-Matt

[mdrobnak]

Wired the SimpBMS. Tom fixed the Coda charger issue. Yay.
But, it does not see any of the slave boards.
My floor matches my feelings.

-Matt

[tom91]

Wired the SimpBMS. Tom fixed the Coda charger issue. Yay.
But, it does not see any of the slave boards.
My floor matches my feelings.

PXL_20201103_013344839.jpg

-Matt

Wait buddy, you only 1/3 way there. Power for the HV side is derrived from the HV side.....

[mdrobnak]

Wired the SimpBMS. Tom fixed the Coda charger issue. Yay.
But, it does not see any of the slave boards.
My floor matches my feelings.

PXL_20201103_013344839.jpg

-Matt

Wait buddy, you only 1/3 way there. Power for the HV side is derrived from the HV side.....

HAHA don't I feel dumb.
What's the 5V on them used for, then? Is there a most-positive pin line a most-negative pin, as well? Or just most-negative + cell 1-6/12?
I'll finish wiring up the first connector and try again.

-Matt