Tesla Charger alternative firmware

[mdrobnak]

So, inquiring minds want to know. Where was issue in drop?

Basically the STM32 has a 3 message CAN send FIFO. So if your code is like
can_send();
can_send();
can_send();
can_send();

Then the last message will be dropped. To get around this you have to implement a software FIFO that stores the excess messages until the hardware FIFO is free again and then sends them out. That's exactly what the CAN module in libopeninv does and that is why building your software on top of stm32-template is super king

Ouch. I had some similar problems moving to the new bxcan Rust crate. If you wait for the return for the transmit, it works fine. With a single ID, 8 bytes, 500k, I was able to pump out 4000 messages/sec with an 8MHz clock. That seems close to the theoretical limit. A simple FIFO works well too, but what I tried last night(FIFO + Interrupt driven TX) worked very poorly to say the least, so I abandoned that.

-Matt

[johu]

I see, well waiting is hardly an option in a scheduled environment because it can starve the other "threads". So in fact I also use interrupt driven TX as soon as the hardware FIFOs are full:

Code: Select all

   if (can_transmit(canDev, canId, false, false, len, (uint8_t*)data) < 0 && sendCnt < SENDBUFFER_LEN)
   {
      /* enqueue in send buffer if all TX mailboxes are full */
      sendBuffer[sendCnt].id = canId;
      ///etc....
      sendCnt++;
   }

and then in the ISR (edit: just noticed I actually implemented a stack, not a FIFO - but shouldn't matter)

Code: Select all

   while (sendCnt > 0 && can_transmit(...) >= 0)
      sendCnt--;

   if (sendCnt == 0)
   {
      can_disable_irq(canDev, CAN_IER_TMEIE);
   }

So even though there is a while loop in the ISR I expect it to just send one message per interrupt because the interrupt already fires when one place in the FIFO is free, as far as I know.

The result: say you send a burst of 3 CAN messages every 1ms. Then the interrupt will never be called because they all fit in the FIFO and it takes like 600us to send your 3 messages.
If you send a burst of 10 CAN messages every 10ms then the interrupt will be called 7 times every 10ms or 700 times per second. Which compared to the PWM interrupt which used to be called up to 17600 times per second doesn't seem like much. So I'm struggling to understand why it didn't work for you.

[mdrobnak]

Slightly different method - add to queue, add pending interrupt. Interrupt handler then sends from queue. Not my design.
Yeah, unclear why it didn't work the way I wanted. But I wrote a wrapper that would make it easier to swap to something else later if needed.

Ok back to the main thread here.

Thanks for the info.

-Matt

[jon volk]

My flashing and testing has been delayed until later in the week. I got wrapped up in the new Volt BMS code and getting it squared away for my purposes.

[johu]

Ok. One US test would be good because there was something about the input voltage being sent to the charger that I kept as a constant of 224V.

[Bryson]

I’ll get going tonight in the US! Thank you

[Jack Bauer]

May I suggest changing the bypass cap on the wifi module from 0.1uF to 10uf as you may experience adc read problems otherwise. This is implemented on the new rev boards on order.

[johu]

Can you remember the relevance of the following:

Code: Select all

uint16_t ACvoltIN = 240; // AC input voltage 240VAC for EU/UK and 110VAC for US
.....
if (bChargerEnabled)
{
   CanTxData[1] = 0xBB;
   CanTxData[4] = 0xFE; //FE dont clear faults. FF do clear faults.
}
else
{
   CanTxData[1] = (uint8_t)(((uint16_t)(ACvoltIN / 1.2))&0xFF);
   CanTxData[4] = 0x64;
}

I have hard coded it to 0xBB (which translates to 224V) right now and apparently it works on 230V outlets. But will it work in 120V like this?

[Bryson]

May I suggest changing the bypass cap on the wifi module from 0.1uF to 10uf as you may experience adc read problems otherwise. This is implemented on the new rev boards on order.

Thanks. Do you know the component size/family off hand? I’m still in the office and won’t be able to check or measure until tonight. Might be useful for others to know off hand in this thread as well.

[johu]

0603 but 0805 also fits

[Bryson]

Thanks, I was able to replace the C3 cap with a 10uF that we had in the office. I believe these are 0805 as the 0603 barely fit on the footprint and was smaller than what I removed, for what it's worth.

I was able to flash the software, but I'm no longer able to communicate with the USB serial link after flashing - has this been deprecated in the new firmware?

My ESP8266 WiFi has never worked properly and I believe that makes this firmware not useable for me until I can resolve that. WiFi at 192.168.4.1 has always shown '900' for all 'gauges' for me. I did have a hell of a time flashing the software to the ESP8266 on my mac, so perhaps I made a mistake there.

edit: I realized I had another ESP8266 sitting around - I programmed that one and we're off to the races. I'm able to edit parameters via the Management Console Very slick. The charger works great, and the 5 minute timer works exactly as advertised Thank you!

Here's me charging on a US single phase 240V circuit (I cycled the charger button to initiate the second charge start in the first image):

[johu]

Nice, thanks for testing! Will send you a pin in a minute.
Yes the USB terminal has not been implemented, I'd keep it that way unless it stops the show for anybody.

Can you do a 120V test?

[Jack Bauer]

Sorry guys I was off to bed early last night. I'll write a few lines today on component mods. Just one cap and one resistor. All boards being shipped out now already have this done.

[Bryson]

Nice, thanks for testing! Will send you a pin in a minute.
Yes the USB terminal has not been implemented, I'd keep it that way unless it stops the show for anybody.

Can you do a 120V test?

Thanks again. I don’t have a 120V EVSE handy but can probably whip up a cable and run it in manual mode. I’m a bit hesitant as the grounds don’t seem to be very good in my old home, so it may take me a little time to test before plugging in.

[johu]

Ok, don't blow yourself up! Lets see what Jon Volk does

[jon volk]

Im about to pull the car in the garage to get the cover off the charger. I can give it a go without changing the cap to save time and then pull the board if Im getting bad inputs on the ADC. It appears the openevse will accept the 120v input as well so it should be a quick reconfigure at the breaker box.

[jon volk]

No luck today. Updated the wifi module and have the interface showing. Updated the bootloader and charger file but no parameters coming through on the interface. Need to dig in further tomorrow.

EDIT: I’m a dumbass and didn’t tag the reset button. Will configure and test power after the kids are fed,

[jon volk]

120v EVSE charging works. Correctly IDd evse set 12a limit.

[johu]

One bug found iaclim was limited to 16A, which limits total current on a single phase outlet to... well 16A. Even if it could provide 32A or more.

Fixed.

[jon volk]

Excellent. Now I have to go do some burnouts to drag the pack voltage below charge threshold again. Tough life.

[Bryson]

Thanks, that explains the constant 4kW I was seeing. This firmware can be loaded OTA right? Is there a link to the process, or is it dummy proof?

[jon volk]

Yea it’s OTA. Just click choose file in the uart update and select the .bin, click upload.

[jon volk]

Full power charging works as expected as does the CAN transmit messages as evidenced by my water pump and dcdc turning on with the charger enabled value of 5.

Good stuff.

[johu]

Cool, CHAdeMO water pump then

I guess I'll just publish then.

[Bryson]

Mine is still charging at a steady 4kW = 16A on my 40A EVSE after the firmware upgrade. I am at 92% SOC so it may be coincidental that the taper current is the same and that’s what I’m seeing. I’ll have to drive a bunch to discharge it and try again.