openinverter forum

Posted: **Sun Oct 06, 2024 3:28 pm**

Okay now, before I'll have time to actually look at the hardware (the issue might very well be exactly what uhi22 described, because I have issues with wakeup also - I've so far never gotten the board to sleep), here's another question/request:

Is there a reason why EvseCurrent never gets reset to 0 after the charging session has obviously ended? This is causing issues for me - for example my user interface is showing this value and you can imagine this is very confusing.

Posted: **Sun Oct 06, 2024 5:13 pm**

Because we forgot

This should fix it but haven't tested https://github.com/uhi22/ccs32clara/pull/39

Posted: **Sun Oct 06, 2024 6:12 pm**

johu wrote: ↑Sun Oct 06, 2024 5:13 pmBecause we forgot

Your fix just for DC? Does the AC current values drop to zero too? It would be good on detecting a "disconnected" plug to rest all possible EVSE values to 0.

Posted: **Mon Oct 07, 2024 8:27 am**

tom91 wrote: ↑Sun Oct 06, 2024 6:12 pm Your fix just for DC? Does the AC current values drop to zero too?

AC values are not session based but continuously updated. E.g. EvseAcCurrentLimit will drop to 0 instantly when PWM goes below 8% or above 97%

uhi22 wrote: ↑Fri Oct 04, 2024 4:15 pm The PP resistance measurement is disturbed via the path R64 (1k to 12V), D21, PP_WAKE, JP3, PP. As long as the controller sets KEEP_POWER_ON=1, everything is fine, because Q3 pulls the anode of D21 to ground. But if the controller releases the KEEP_POWER_ON, the voltage on the PP rises, and the controller interprets this as increased resistance.

Is it still possible that KEEP_POWER_ON drops out when it shouldn't? In Code it looks like as long as CP is valid it should stay on

Posted: **Mon Oct 07, 2024 12:36 pm**

Just wanted to add in here that I now have FOCCCI working successfully with multiple CCS1 stations (North American CCS).

I have successfully used an EVGo station (built by Delta), a newer Electrify America station, and an ABB station. Hoping to test with ChargePoint and maybe Shell next weekend, and then whatever CircleK is using later this fall.

Posted: **Mon Oct 07, 2024 4:13 pm**

Wow, better than expected. I was expecting to get a lot of logs with failed sessions. Just for the case this happens later, could you take an serial-to-USB adaptor with you, connected to Focccis serial pins, to record a log file?

Posted: **Tue Oct 08, 2024 11:57 am**

uhi22 wrote: ↑Mon Oct 07, 2024 4:13 pm Just for the case this happens later, could you take an serial-to-USB adaptor with you, connected to Focccis serial pins, to record a log file?

I will try. My laptop is currently giving me a hard time with the serial terminal, but I'll give it a shot.

Posted: **Tue Oct 08, 2024 5:56 pm**

johu wrote: ↑Mon Oct 07, 2024 8:27 am Is it still possible that KEEP_POWER_ON drops out when it shouldn't? In Code it looks like as long as CP is valid it should stay on

It does look to me like CP is at 5% always when the charging process is at checkpoint 710 (=CurrentDemand). This is the Previa's logs (Omega's logs show a similar result):

Code: Select all

$ grep 'checkpoint          : 710' *.params.txt -A100 | grep ControlPilotDuty | sort -n | uniq -c
    110 oic_2024-06-27_193906.params.txt-ControlPilotDuty    : 5.28125 [%]
     20 oic_2024-06-27_193906.params.txt-ControlPilotDuty    : 5.375 [%]
      1 oic_2024-06-29_085419.params.txt-ControlPilotDuty    : 5.375 [%]
     10 oic_2024-06-29_085422.params.txt-ControlPilotDuty    : 5.375 [%]
     18 oic_2024-06-29_090001.params.txt-ControlPilotDuty    : 5.375 [%]
    226 oic_2024-10-02_174333.params.txt-ControlPilotDuty    : 5.28125 [%]
    512 oic_2024-10-02_175217.params.txt-ControlPilotDuty    : 5.28125 [%]
      1 oic_2024-10-02_175217.params.txt-ControlPilotDuty    : 5.375 [%]

Posted: **Wed Oct 09, 2024 7:04 am**

My impression is, that the conditions to decide to switch the keep_power_on are not robust in all use cases.

For instance, if there is just plugged-in, but the EVSE does not provide PWM yet, AND the CanActive is not yet fulfilled, and the plug is shortly removed (ppValid==0) we turn-off the keep_power_on "for ever". If at the same time, the wakeup line makes us to keep running, we always will get wrong PP measurements.

Posted: **Wed Oct 09, 2024 7:44 am**

Oh true, quite an oversight.

So it only makes sense to turn off keep_power_on when all the external wakeup sources are off. In that case Foccci actually powers down. I don't see a case where we would need to Set() keep_power_on again

Posted: **Wed Oct 09, 2024 8:19 am**

Well, while we keep running (for whatever reason), we could at least turn the keep_power_on for a moment, take a valid pp resistance reading and turn off again. And discard the known wrong pp readings.

Posted: **Wed Oct 09, 2024 3:32 pm**

That's starting to sound like a pretty solid plan for fixing all my problems before I've even managed to touch the car let alone do anything useful.

Posted: **Thu Oct 10, 2024 2:59 pm**

Quick question, when flashing the STM32 is it possible to use the same method with the ST-link utility as what's outlined in the Tesla charger flashing instructions? I'm not seeing CAN comms to my board and just trying to rule out an issue with how I flashed it. My linux machine didn't want to talk to the st-link so I just used the windows utility. I do have the 'alive' light flashing and I do have to put 12v to the wakeup pin to get the lights on, so hopefully that means it's been flashed correctly.

From the teslacharger wiki:

Click "Target --> Connect" from top menu. You want to see the screen get filled with a data dump of symbols. In the upper right of the screen you can see it identified the device.

In the main viewing window are multiple tabs, click the "Binary File" tab to select it.

This will ask to open a file, you choose: "stm32_loader.hex" from openinverter.org, download ahead of time. This will change what shows up in the viewing window.

Click "Target --> Program and Verify" from the top menu. This pops up a window, and you can probably just click "Start" on that window. This programs the STM32 chip with the stm32_loader.hex file.

The STM32 on your v5 gen2 Tesla charger Board can now load other files.

You can close the stm32_loader.hex tab, and go back to the "Binary File" tab, which will ask to open another file.

You choose: "Charger_Gen2_v5.hex"

Same as last time, click "Target --> Program and Verify" from the top menu. And click Start.

The STM32 on your v5 gen2 Tesla charger Board now also has the software to run.

You are now done with the ST-Link USB dongle, it's no longer needed.

Posted: **Thu Oct 10, 2024 4:05 pm**

I do not know this tool, but if the LEDs are working it seems to be ok. I'm using a git shell (mingw) under windows 10, with this:
$ ST-LINK_CLI -P stm32_canloader.hex -P CI_35.hex -V
where CI_35.hex was copied from the continuous integration here: https://github.com/uhi22/ccs32clara/actions

Posted: **Fri Oct 18, 2024 1:05 pm**

I am experiencing some strange behavior with my focci 5.1 and wifi interface, after playing around with the can mapping and having every message configured properly but one, I can't add messages anymore.

So i got everything powered up, 12v permanent to focci and bms, wakeup of focci when i plug my T2 portable station, I have access to the wifi interface I can modify parameters, start the charge by manually changing the AcObcState from 0 to 1 and to 2. but i can't map any can message anymore. I don't think i have that many mapped.

Posted: **Fri Oct 18, 2024 2:01 pm**

Argh, yes something goes sideways when playing with mappings for a while. Need to implement the clear mapping command over SDO. Now you can only resolve it with an ST Link by deleting the last flash page (loosing parameters and mappings)

Posted: **Fri Oct 18, 2024 4:04 pm**

Oh, interesting. What causes it? Too many things mapped?

Posted: **Mon Oct 21, 2024 6:08 am**

johu wrote: ↑Fri Oct 18, 2024 2:01 pm Argh, yes something goes sideways when playing with mappings for a while. Need to implement the clear mapping command over SDO. Now you can only resolve it with an ST Link by deleting the last flash page (loosing parameters and mappings)

Do i need to reflash the wifi board or the Focci itself ? Maybe there is a guide somewhere that I can follow ?

Posted: **Mon Oct 21, 2024 6:31 am**

I do not know the details about the why it fails, but the mappings are at the end of the flash memory in Foccci. So to clean up everything, a "mass erase" of the STM32 on the Foccci board should help. How to do this? Using an STlink programmer, which is connected to the Foccci board via the 3-pin connector SWCLK, GND, SWDIO. And then using the STLink command line utility, with the argument "-ME" for "mass erase":

Posted: **Mon Oct 21, 2024 8:16 am**

celeron55 wrote: ↑Wed Oct 09, 2024 3:32 pm That's starting to sound like a pretty solid plan for fixing all my problems before I've even managed to touch the car let alone do anything useful.

The actual fix took a little bit longer, but ready for test now: https://github.com/uhi22/ccs32clara/issues/40
Basically now Clara ignores the PP readings which are known to be invalid, and cyclically (each 2 seconds) turns the keep_power_on active for a moment, to get a valid reading of the PP resistance. On the desk this works, attached an osci plot to the issue.

Posted: **Mon Oct 21, 2024 6:07 pm**

Zieg wrote: ↑Fri Oct 18, 2024 4:04 pm Oh, interesting. What causes it? Too many things mapped?

I've dug into this a bit as it was frustrating to see so many people hit this problem. It's caused by a memory leak/corruption of an internal data structure when CAN parameter mappings are removed. Unfortunately the corruption is saved to Flash and there is no way to fix it using the CAN interface.

I've raised a bug against the core libopeninv library (https://github.com/jsphuebner/libopeninv/issues/24) to cover the problem. This affects all OI projects.

It should be possible to clear the fault with a serial console attached to your Foccci. Issuing "can c" then "save" will wipe the CAN map and allow new entries to be added again.

Once you have the system running just add map entries carefully. Removing faulty entries works but you can only have 50 parameter mapping entries past or present in the lifetime of the system.

Hopefully there is enough information/replication steps that johu can now address the bug.

Posted: **Mon Oct 21, 2024 6:15 pm**

davefiddes wrote: ↑Mon Oct 21, 2024 6:07 pm Issuing "can c" then "save"

Unfortunately not, Foccci doesn't listen to terminal commands

Posted: **Tue Oct 22, 2024 8:13 am**

uhi22 wrote: ↑Mon Oct 21, 2024 6:31 am I do not know the details about the why it fails, but the mappings are at the end of the flash memory in Foccci. So to clean up everything, a "mass erase" of the STM32 on the Foccci board should help. How to do this? Using an STlink programmer, which is connected to the Foccci board via the 3-pin connector SWCLK, GND, SWDIO. And then using the STLink command line utility, with the argument "-ME" for "mass erase":
image.png

Done with full chip erase via the gui stlink utility, but now i have to put an uncorupted bin/hex back in the stm32. I'm using windows and i'm not that computer savvy, last release of clara is v0.22 so quite old.

Could someone provide here or on the git a compiled version ?

Posted: **Tue Oct 22, 2024 8:24 am**

Bootloader: https://github.com/jsphuebner/stm32-CAN ... r/releases
Firmware: https://github.com/uhi22/ccs32clara/act ... 1435784191

Posted: **Tue Oct 22, 2024 10:46 am**

johu wrote: ↑Mon Oct 21, 2024 6:15 pm Unfortunately not, Foccci doesn't listen to terminal commands

Apologies for any confusion caused. I did check the clara code before commenting and the serial commands all appear to be there. If it's not intended to work perhaps there is a good chunk of flash space that could be saved.

openinverter forum

QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread

Re: QCA7000 Foccci+Clara User thread