Stand alone OBC/PDModule EV system Can 2015

[49thdiver]

No significant progress to report however a lot has happened. Code snippets below.
I have successfully modified the Can Bridge software to transmit the 5 messages in sequence missing from the can bus dialogue in an attempt at stimulating some response from the charger. Essentially after the first 3 messages from the charger "679, 390, 393" and a 4th message/response from the VCM "50B" as a result of plugging a live j1772 plug into the charge port as documented earlier. I have inserted 5 messages recorded from a working leaf "54A,481,54B,54C and 54F".
I had initially set the trigger with the 50B message, I have also tried triggering it on 679 and 11A messages as there is a time slot after each of these that I was able to insert the messages cleanly in sequence. Inserting them immediately after 50B ends up spacing them out between other VCM generated messages (not clean).

Any suggestions or idea's of where to go next appreciated. I am still trying to acquire a complete leaf for more testing as I still suspect something is wrong with the charger I am using or the lack of a BMS to complete the communication may be the issue.

NO APOLOGIZE, programming in C is not something I am good at so there may be better ways to do what I have done, I can only say that it works as expected.

The significant code changes are as follows: (with the full code linked below) and of course the original source is from emile_nijssen-open-source-can-bridge-f3a419e03747 on GITHUB. This works on the Muxan Bridge MITM but could work on any dual MCP25625 circuit if modified.

• .......................These are the messages I am inserting...........
  struct can_response array_response[5] = {
  {0x54A,8,{0xDA,0x80,0x70,0x0e,0x00,0x00,0x00,0x54}},
  {0x481,2,{0x4B,0x00,0x00,0x00,0x00,0x00,0x00,0x00}},
  {0x54B,8,{0x10,0x08,0x80,0x00,0x04,0x00,0x00,0x00}},
  {0x54C,8,{0x59,0xFF,0x00,0x00,0x00,0xF8,0xFF,0x00}},
  {0x54F,8,{0x14,0x00,0x00,0x00,0x08,0x40,0xC0,0x14}},
  };..........................

and (sorry for the formatting)

• ...........This is the core of the code that does it
  .................//test_can_msg and send to serial always moved here to stream line debugging
  
  SID_to_str(strbuf + 2, frame.can_id); // build frame for serial ....
  canframe_to_str(strbuf + 6, frame);
  print(strbuf,23); // now send to serial
  // CAN message modification routine ////// NOTE I HAVE swapped 50B AS THE ORIGINAL TRIGGER, AND have tried 679 and 11A
  as there are time slots that the response can be squeezed in.
  
  switch(frame.can_id){
  case 0x50B: /// see above
  for (int j=0; j <5; ++j){ // build 5 messages that need to be inserted
  for (int i=0; i <array_response[j].can_response_dlc; ++i){
  frame.data= array_response[j].response_data; // actual to frame done here
  }
  
  frame.can_id = array_response[j].can_respone_id;
  frame.can_dlc = array_response[j].can_response_dlc;
  calc_crc8(&frame); /calculates the CRC using radix 0x85 and put that CRC in frame.data[7]
  
  //send command
  _delay_ms(0.7); // This helps with data overflow on Can 2 but not much??
  send_can1(frame);.............................

Full modified code here : https://www.divemaster.ca/RAV4EV/LEAF/M ... firmware.c
https://www.divemaster.ca/RAV4EV/LEAF/M ... firmware.h
https://www.divemaster.ca/RAV4EV/LEAF/M ... /mcp25xx.c

Foot note : I have one MUXAN bridge as a MITM between the OBC/PDM and the VCM doing the work and I have one arduino based MC2515 on each side of the bridge monitoring the resulting input and output. The monitoring allows me to be sure the code is doing what I want it to do. I also have a third arduino monitoring the CarCan just for fun at the moment. (which runs full time with messages when the car is in the off position). It's no wonder the battery discharges over time.

[mux]

Note that you shouldn't ever insert delay loops into interrupt-driven code! The CAN bridge has its own internal buffering routine that buffers multiple messages for sending, you shouldn't get buffer overflows in any kind of normal code. If you're encountering overflows, break up the amount of messages you're sending and send them e.g. in the TCC0_OVF interrupt.

I'm also not sure if sending these messages one-time only will be sufficient. I think you're going to need to send a bunch of these periodically. As 0x679B is a one-off insertion detection messages, it won't be a reliable trigger for sending the rest. So again, try inserting them in the timer interrupt.

[49thdiver]

Thanks Mux for the quick response. Sorry I was not clear in my posting, the switch had the wrong case test listed I have corrected that on the posting. I have deleted the delay as indeed it was introducing other problems. I have been triggering on 0x50B which as far as I can tell is a response from the VCM to the three messages from the OBC 679,390 & 393 when you plug in the charger. 0x50B is sent fairly regularly and the message sequence is inserted at every instance. On the working car that I am using to record the events, the message sequence I am inserting only happens the once on the working car. I was only trying the other trigger events to try and avoid the overflows.
Thanks for the tip on using the ISR to insert the messages. My knowledge of C and this micro controller architecture is limited so this advice is very helpful. I assume to speed things up a a bit I could replace the keyboard command checking (as I am not using it) with code to insert my messages. I could also eliminate checking the 3rd mcp25625 as I am not using it at the moment either. It seesm to me from the time stamps I am using on serial port that the messages are coming pretty fast at < 100usec. I really need to get regular access to a working car now that I have got this far with understanding and being able to monitor and trigger the message handling. I will keep plugging away in the meantime. I ordered another bridge from you it should arrive this week, I plan to put that at the VCM initially to confirm that it is the message source for the 0x50B and later when I get another car at the BMS to monitor that messaging.
Thanks again, more to follow.

[mux]

You've come far for not quite being familiar with interrupt-driven bare metal 8-bit C.

Some pointers to help in the meantime:
- There's no harm in keeping the keyboard check, it's a very fast routine when nothing's happening and most of the underlying USB stuff is interrupt-driven anyway. And the nice thing is that:
- You can use the '@' command to turn on/off CAN logging, which is beyond useful in this kind of application. Don't forget you can add other stuff as well to your liking.
- Just add the message send routines to the timer interrupt. No need to remove or replace anything there. Note that the timer triggers every 1ms, so you need to add a case that triggers every 100 cycles for a message that you'd like to send every 100ms. Then you're not dependent on other messages as triggers, and you're unloading the CAN checking routine which will improve performance of the application.

I don't generally have time to do in-depth code support, but considering this is a pretty important project for the community, feel free to e-mail me at info@muxsan.com if you need something in particular. I'll try to answer in time.

[49thdiver]

Ok so I tightened up the code. I kept the case statement testing in place and corrected one error. More significantly I dumped using KiTTY a fork of PuTTY as my serial terminal it was unable to keep up with the data transmission speed from the Bridge. I switched to using the arduino serial monitor which runs at 200000 nicely resulting in no more overflow errors. This allowed me to avoid having to dig deeper into and implementing the interrupt idea, perhaps later at the moment this seems to be working as is.

I have now added 2 more case tests to insert additional messages, this is working very nicely as can be seen by a sample of the start of the 1700 entry recording below. It shows each of the case tests inserting the additional messages at the right time more or less.
The tests are 50B, 1D4, and 1F2, you can see in the sample recording that the additional messages are being added successfully.
Also below is the struct statement of the messages I am adding.
The bridge now simulates the recording made of a working car and charger very closely, messages are repeated throughout the 1700 messages.

Tragically the charger still does nothing although the can sequence on the car side seems to be behaving differently (it pauses for about 500ms regularly) but I need to analyze this closely to figure out exactly what is happening, it is not obvious.

I continue to believe there is a problem with the charger or some other component from the accident it was in.
We were unable to get it to charge even when it was complete, in it's wrecked condition and I think this is causing the charger to not respond.
FYI, The inverter was damaged beyond repair. The battery and the BMS, work fine and they are being installed in a Toyota RAV4 EV.
Still looking for another wrecked leaf at a good price. This time we are looking for one with no front end damage.
Anyone else looking to buy a wreck beware !

Full code and recordings here : http://www.evmotorworks.ca

Sample recording of bridge output on the OBC/PD side using an OLIMEX Pic32-emz64 with code from mholt999 .
Comments added to this post are not part of the recording.
,CAN ID ,DL,D0,D1,D2,D3,D4,D5,D6,D7,T Stamp,#,But 1,But 2
rx, 0x679,1;00;00;00;00;00;00;00;00,00250.38605,00;00;00 // charger plugged in
rx, 0x390,8;04;00;00;00;00;80;3C;07,00250.43612,01;00;00
rx, 0x393,8;00;10;00;00;20;00;00;02,00250.43644,02;00;00
rx, 0x50B,7;00;00;00;C0;00;00;00;00,00250.43799,03;00;00 // case 50B test
rx, 0x54A,8;DA;80;70;0E;00;00;00;54,00250.43825,04;00;00
rx, 0x481,2;4B;00;00;00;00;00;00;00,00250.43843,05;00;00
rx, 0x54B,8;10;08;80;00;04;00;00;00,00250.43878,06;00;00
rx, 0x54C,8;59;FF;00;00;00;F8;FF;00,00250.43906,07;00;00
rx, 0x54F,8;14;00;00;00;08;40;C0;14,00250.43934,08;00;00
rx, 0x1F2,8;04;64;04;A0;00;02;02;8A,00250.44229,09;00;00 //case 1DB test
rx, 0x1DB,8;FF;E0;BC;AA;2F;00;03;B0,00250.44264,10;00;00
rx, 0x55B,6;00;00;00;00;5D;C8;00;00,00250.44286,11;00;00
rx, 0x1D4,8;6E;6E;00;00;82;06;E0;C1,00250.44329,12;00;00 //case 1B4 test
rx, 0x50A,8;04;80;00;0F;00;02;04;00,00250.44357,13;00;00
rx, 0x50C,6;00;00;00;00;5D;C8;00;00,00250.44371,14;00;00
rx, 0x5A9,8;FF;FF;FC;FF;FF;F7;FE;00,00250.44413,15;00;00
rx, 0x45E,1;00;00;00;00;00;00;00;00,00250.44423,16;00;00
rx, 0x5B9,7;07;FF;07;FF;2F;FF;80;00,00250.44454,17;00;00 //vcm output
rx, 0x11A,8;00;80;00;AA;C0;00;00;67,00250.44845,18;00;00 // ...............................

List of Inserted messages:
struct can_response array_response[12] = {
{0x54A,8,{0xDA,0x80,0x70,0x0e,0x00,0x00,0x00,0x54}}, //0 CASE: 50B
{0x481,2,{0x4B,0x00,0x00,0x00,0x00,0x00,0x00,0x00}}, //1
{0x54B,8,{0x10,0x08,0x80,0x00,0x04,0x00,0x00,0x00}}, //2
{0x54C,8,{0x59,0xFF,0x00,0x00,0x00,0xF8,0xFF,0x00}}, //3
{0x54F,8,{0x14,0x00,0x00,0x00,0x08,0x40,0xC0,0x14}}, //4
{0x50A,8,{0x04,0x80,0x00,0x0F,0x00,0x02,0x04,0x00}}, //5 CASE: 1D4
{0x50C,6,{0x00,0x00,0x00,0x00,0x5D,0xC8,0x00,0x00}}, //6
{0x5A9,8,{0xFF,0xFF,0xFC,0xFF,0xFF,0xF7,0xFE,0x00}}, //7
{0x45E,1,{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}}, //8 extra's
{0x5B9,7,{0x07,0xFF,0x07,0xFF,0x2F,0xFF,0x80,0x00}}, //9
{0x1DB,8,{0xFF,0xE0,0xBC,0xAA,0x2F,0x00,0x03,0xB0}}, //10 CASE: 1F2
{0x55B,6,{0x00,0x00,0x00,0x00,0x5D,0xC8,0x00,0x00}}, //11
};

[nlspace]

Sorry to hear that all your hard work did not pay off yet, maybe there is still hope when more is revealed.

One thought that may be incorrect, but would the BMS or LBC from the pack need to be on the CAN buss for charging to occur? Maybe i misunderstood that it was not connected on the plywood leaf?

i have monitored the BMS buss during charging on the iMieev which uses the same Nichicon chargger as used in a gen 1 Leaf. It communicates with an EV-ECU which controls the OBC and the charging session. The EV-ECU is the master that controls every thing else in the Miev. i know the gen 2 Leaf is a different chargger, etc., but could imagine the same concept of a master controller being used also, i.e. the VCM.

For example, if the pack temperature sensors are not reported to the VCM then it may not engage the OBC activation signal to begin or allow charging. On gen 1 that is a single wire discrete signal on pin 18, and maybe is the same pin 18 of your OBC wiring diagram?

[49thdiver]

Sorry to hear that all your hard work did not pay off yet, maybe there is still hope when more is revealed.

Indeed, I have just acquired another complete fully functional but wrecked leaf, more testing about to begin.

One thought that may be incorrect, but would the BMS or LBC from the pack need to be on the CAN buss for charging to occur? Maybe i misunderstood that it was not connected on the plywood leaf?

I did not have an LBC up to this point, the theory that I have been working on is that simulating LBC commands on the Can bus should facilitate that need for charging.

i have monitored the BMS buss during charging on the iMieev which uses the same Nichicon charger as used in a gen 1 Leaf. It communicates with an EV-ECU which controls the OBC and the charging session. The EV-ECU is the master that controls every thing else in the Miev. i know the gen 2 Leaf is a different charger, etc., but could imagine the same concept of a master controller being used also, i.e. the VCM.

I think you are correct here, the VCM in the leaf is main controller but again simulating those commands should facilitate charging.

For example, if the pack temperature sensors are not reported to the VCM then it may not engage the OBC activation signal to begin or allow charging. On gen 1 that is a single wire discrete signal on pin 18, and maybe is the same pin 18 of your OBC wiring diagram?

Food for thought here. The changes between Gen1 and 2 are however dramatic. On Gen 2 Pin 18 is a battery connection on the PDM/OBC however. Although the hardware is different your idea may apply. The battery temperature sensors are on the LBC and transmitted via the can bus to the VCM or PDM/OBC or both. I have just started reverse engineering the LBC (based on turbo and others work) The temperature sensors come in on connector LBC12. I have hooked up a resistor string to simulate temperatures with hopes of isolating which CAN message or data bits hold temperature info.
Some significant work ahead of me. I am hoping to confirm some assumptions about plywood Leaf version 1 having some lingering hardware failure from the accident it was in or miswiring on my part or ideas like what you have suggested. I hope to determine if the message insertion is effecting anything and to isolate what the specific messages are that come from the LBC related to charging in the next couple of weeks.
Prior to disassembling this most recent leaf we were able to disconnect many of the sub systems including ABS, Power Brake,VCM as well as other hardware including A/C,cooling, fans, QC while still maintain traction and charging.
Watch for more updates, thanks for the help