Energy Controller including CCS interface

[jrichl]

Mine is 10m


Ok, now do

Code: Select all

echo 0 > /sys/class/pwm/pwmchip0/export

That should spawn /sys/class/pwm/pwm-0:0

if not you need to troubleshoot whichever error message the above command produces

unfortunately all pwm devices seem to be blocked

debian@BeagleBone:~/myprogs$ echo 0 > /sys/class/pwm/pwmchip0/export
-bash: echo: write error: Device or resource busy
debian@BeagleBone:~/myprogs$ echo 0 > /sys/class/pwm/pwmchip1/export
-bash: echo: write error: Device or resource busy
debian@BeagleBone:~/myprogs$ echo 0 > /sys/class/pwm/pwmchip2/export
-bash: echo: write error: Device or resource busy
debian@BeagleBone:~/myprogs$ echo 0 > /sys/class/pwm/pwmchip3/export
-bash: echo: write error: Device or resource busy
debian@BeagleBone:~/myprogs$ echo 0 > /sys/class/pwm/pwmchip5/export
-bash: echo: write error: Device or resource busy
debian@BeagleBone:~/myprogs$ echo 0 > /sys/class/pwm/pwmchip7/export
-bash: echo: write error: Device or resource busy
debian@BeagleBone:~/myprogs$ echo 1000000 > /sys/class/pwm/pwm-0:0/period
-bash: /sys/class/pwm/pwm-0:0/period: No such file or directory
debian@BeagleBone:~/myprogs$ cd /sys/class/pwm
debian@BeagleBone:/sys/class/pwm$ ls
pwmchip0 pwmchip1 pwmchip2 pwmchip3 pwmchip5 pwmchip7
debian@BeagleBone:/sys/class/pwm$


the autostart for evsenogui and also cppwm is deactivated, and in the process list I don't see anything what will block the pwm devices

[johu]

These low level things are terribly inconsistent between distros. Which image are you using?
I always used these: https://www.beagleboard.org/distros (find one for BeagleBone Black)

I think I'm running this one: https://www.beagleboard.org/distros/am3 ... ot-flasher

goes on SD card and flashes itself to emmc

[uhi22]

Not sure, but would use "sudo" for each command make a difference?

With the image I use (am335x-eMMC-flasher-debian-11.8-minimal-armhf-2023-10-07-2gb.img.xz), my script https://github.com/uhi22/DiDeBoCCS/blob ... e/cppwm.py works fine.

[johu]

No with echo this doesn't work.

Code: Select all

echo 0 | sudo tee /sys/class/pwm/pwmchip0/export

would do the trick. Somehow doubt this is it though...

[jrichl]

These low level things are terribly inconsistent between distros. Which image are you using?
I always used these: https://www.beagleboard.org/distros (find one for BeagleBone Black)

I think I'm running this one: https://www.beagleboard.org/distros/am3 ... ot-flasher

goes on SD card and flashes itself to emmc

I use the same as Uwe mentioned in his description for the DiDeBoCCS.

Doing the command as sudo doesn't change anything

debian@BeagleBone:~$ sudo echo 0 > /sys/class/pwm/pwmchip0/export
echo: write error: Device or resource busy

Also the the new file (/etc/connman/main.conf) for no management interference doesn't change something. I think I will try as next step a shorter cable.

Asking Gemini from google regarding the problem he thinks it could be the necessary change for the duty cycle to 95% in the cppwm.py

[uhi22]

Ahh, wait. Just looked on my beaglebone. sudo journalctl -f -n350
This shows (filtered for lines containing "pwm"):

Code: Select all

Line  51: Feb 21 17:02:12 BeagleBone systemd[1]: Started CP PWM Control Script.
	Line  94: Feb 21 17:02:14 BeagleBone python3[628]: Current mode for P9_42 is:     pwm
	Line 213: Feb 21 17:02:36 BeagleBone systemd-udevd[506]: pwmchip1: /etc/udev/rules.d/81-pwm-noroot.rules:12 Failed to write ATTR{/sys/devices/platform/ocp/48000000.interconnect/48000000.interconnect:segment@300000/48302000.target-module/48302000.epwmss/48302100.pwm/pwm/pwmchip1/export}, ignoring: Device or resource busy
	Line 214: Feb 21 17:02:36 BeagleBone systemd-udevd[515]: pwmchip5: /etc/udev/rules.d/81-pwm-noroot.rules:12 Failed to write ATTR{/sys/devices/platform/ocp/48000000.interconnect/48000000.interconnect:segment@300000/48302000.target-module/48302000.epwmss/48302200.pwm/pwm/pwmchip5/export}, ignoring: Device or resource busy
	Line 215: Feb 21 17:02:36 BeagleBone systemd-udevd[515]: pwmchip5: /etc/udev/rules.d/81-pwm-noroot.rules:13 Failed to write ATTR{/sys/devices/platform/ocp/48000000.interconnect/48000000.interconnect:segment@300000/48302000.target-module/48302000.epwmss/48302200.pwm/pwm/pwmchip5/export}, ignoring: Device or resource busy
	Line 216: Feb 21 17:02:36 BeagleBone systemd-udevd[504]: pwmchip0: /etc/udev/rules.d/81-pwm-noroot.rules:12 Failed to write ATTR{/sys/devices/platform/ocp/48000000.interconnect/48000000.interconnect:segment@300000/48300000.target-module/48300000.epwmss/48300100.pwm/pwm/pwmchip0/export}, ignoring: Device or resource busy
	Line 217: Feb 21 17:02:36 BeagleBone systemd-udevd[513]: pwmchip3: /etc/udev/rules.d/81-pwm-noroot.rules:12 Failed to write ATTR{/sys/devices/platform/ocp/48000000.interconnect/48000000.interconnect:segment@300000/48300000.target-module/48300000.epwmss/48300200.pwm/pwm/pwmchip3/export}, ignoring: Device or resource busy
	Line 218: Feb 21 17:02:36 BeagleBone systemd-udevd[513]: pwmchip3: /etc/udev/rules.d/81-pwm-noroot.rules:13 Failed to write ATTR{/sys/devices/platform/ocp/48000000.interconnect/48000000.interconnect:segment@300000/48300000.target-module/48300000.epwmss/48300200.pwm/pwm/pwmchip3/export}, ignoring: Device or resource busy
	Line 219: Feb 21 17:02:36 BeagleBone systemd-udevd[505]: pwmchip2: /etc/udev/rules.d/81-pwm-noroot.rules:12 Failed to write ATTR{/sys/devices/platform/ocp/48000000.interconnect/48000000.interconnect:segment@300000/48304000.target-module/48304000.epwmss/48304100.pwm/pwm/pwmchip2/export}, ignoring: Device or resource busy
	Line 220: Feb 21 17:02:36 BeagleBone systemd-udevd[508]: pwmchip7: /etc/udev/rules.d/81-pwm-noroot.rules:12 Failed to write ATTR{/sys/devices/platform/ocp/48000000.interconnect/48000000.interconnect:segment@300000/48304000.target-module/48304000.epwmss/48304200.pwm/pwm/pwmchip7/export}, ignoring: Device or resource busy
	Line 221: Feb 21 17:02:36 BeagleBone systemd-udevd[508]: pwmchip7: /etc/udev/rules.d/81-pwm-noroot.rules:13 Failed to write ATTR{/sys/devices/platform/ocp/4800000

Conclusion: The error messages are "normal". The cppwm.py runs anyhow, 22 seconds before the errors are raising. Not clear where the errors come from.

[jrichl]

I can't believe, the i3 light is blue. evseNoGui is reporting the following.

[addressManager] will give local MAC BA:F0:F2:E5:43:A4
udplog started with ownMac BA:F0:F2:E5:43:A4
logging to UDP Syslog is disabled
sniffer created at eth1
[addressManager] pev has MAC F0:7F:0C:15:D5:73
[240, 127, 12, 21, 213, 115]
[addressManager] pev has IP fe80:0000:0000:0000:f27ffe15:d573
V2GTP (10bytes) = 01 FE 90 00 00 00 00 02 10 00
Ok, this was a valid SDP request. We are the SECC. Sending SDP response.
SDP payload (20bytes) = FE 80 00 00 00 00 00 00 B8 F0 F2 FF FE E5 43 A4 3B 0E 10 00
V2Gframe (28bytes) = 01 FE 90 01 00 00 00 14 FE 80 00 00 00 00 00 00 B8 F0 F2 FF FE E5 43 A4 3B 0E 10 00

And all what I have changed is the duty cycle back to the original value in the cppwm.py

[uhi22]

Wow, I would be interested in the pcap.

[jrichl]

Wow, I would be interested in the pcap.

I'm very excited, here is the pcap. Inside the car, the display things it would be charged

[uhi22]

Congratulations, this looks very good.

I have some remarks:
1. Which model year is the i3? It is interesting, it announces only the good old DIN70121 from year 2012. BMW seems to have no urgent update plans
2. You are using an older version of openV2Gx, which still reports "Not ready" during the cable check. Seems not to disturb the i3, but nevertheless I recommend to pull the latest revision and make again.
3. Funny thing: The i3 requests 415V in the first precharge request, and 390V later.
4. The log shows that we are more than 5 minutes in the current demand loop, then the log ends. Would be interesting to know how long the i3 is tolerating this situation.

[jrichl]

Congratulations, this looks very good.

I have some remarks:
1. Which model year is the i3? It is interesting, it announces only the good old DIN70121 from year 2012. BMW seems to have no urgent update plans

-> it is one of the last ones out of 2022

2. You are using an older version of openV2Gx, which still reports "Not ready" during the cable check. Seems not to disturb the i3, but nevertheless I recommend to pull the latest revision and make again.

-> ok, i will do tomorrow

3. Funny thing: The i3 requests 415V in the first precharge request, and 390V later.

4. The log shows that we are more than 5 minutes in the current demand loop, then the log ends. Would be interesting to know how long the i3 is tolerating this situation.

-> I didn't try how long it goes, I stopped the tcpdump in fear of a to big dumpfile on the beaglebone, but i think it has tolerated that situation much longer, because the i3 was still blinking blue after 10-15 minutes when I wanted to pull of the ccs plug. It was not possible, I had to stop the plc Communication, the ccs plug was still locked. Maybe I'll try this tomorrow again, if it is helpful.

Edit: I started a new session bevor breakfast, and after one hour the i3 is still in charging mode, the pcap File is around 13MB, the DC Connectors in the car are closed and I can measure a voltage around 380V. I think at next I should try it with your lightbulbs, I think you put them in series - right?

[uhi22]

Yes, two in series, to tolerate the 400V. In the meanwhile I ordered 10A/1000VDC PV fuses, and will install them directly in the CCS connector, one in each DC line. Because in case one bulb dies (which happens from time to time), there would be an arc in this bulb, and the other bulb would get much more voltage, and may also die. Then we have two arcs burning, and the next will be melting cables. Not something which I like to have.

[jrichl]

Yes, two in series, to tolerate the 400V. In the meanwhile I ordered 10A/1000VDC PV fuses, and will install them directly in the CCS connector, one in each DC line. Because in case one bulb dies (which happens from time to time), there would be an arc in this bulb, and the other bulb would get much more voltage, and may also die. Then we have two arcs burning, and the next will be melting cables. Not something which I like to have.

Yes, it is very risky with direkt current, I will do this the same with the DC fuses. Meanwhile i started to implement the display as you described, but something is not working. It looks like that at the moment. The STM32 I have flashed with your software from here

https://github.com/uhi22/TFT-with-CAN/t ... playbranch

I See the CAN Messages with the candump can0, but the display only shows the backlight and nothing else. The Display is from here

https://de.aliexpress.com/item/10050037 ... pt=glo2deu

It should have an ILI9341, although I have read that the cheap Chinese Modules not necessarily have one. Is there something to care about regarding the cabling. Maybe somethings is wrong with the binary which I build with the STM32cubeIDE on my MacOS System? I flashed it with an ST-Link V2. Need those Display also some software?

[uhi22]

No, the display itself does not need any software. I also use the CubeIDE, and the STLink v2 (clone) to flash. Does the flash process work? I had issues with some faked bluepill boards, which seem to have a slighly different controller. The flash process failed.
Other thing are the cheap CAN transceiver boards. Not all of them work as they should. One thing to check is the resistance between CANH and CANL while not powered, this should be in range 60 to 120 ohms (in theory each end of the line should have 120 ohm termination, but we can ignore this if it is only half a meter).
To exclude a CAN transceiver issue, you could remove the CAN transceiver and bridge CANRX and CANTX on the STM32. With this setup, the controller is happy to run and should send data to the display. If this does not help, only idea would be a wrong display type or wrong wiring.

[uhi22]

To simplify analysis, added an LED-blink feature to the display software. The green onboard-LED of the bluepill blinks slowly (~once per second) after startup, and fast (~4 per second) if a CAN message was received.

[jrichl]

No, the display itself does not need any software. I also use the CubeIDE, and the STLink v2 (clone) to flash. Does the flash process work? I had issues with some faked bluepill boards, which seem to have a slighly different controller. The flash process failed.
Other thing are the cheap CAN transceiver boards. Not all of them work as they should. One thing to check is the resistance between CANH and CANL while not powered, this should be in range 60 to 120 ohms (in theory each end of the line should have 120 ohm termination, but we can ignore this if it is only half a meter).
To exclude a CAN transceiver issue, you could remove the CAN transceiver and bridge CANRX and CANTX on the STM32. With this setup, the controller is happy to run and should send data to the display. If this does not help, only idea would be a wrong display type or wrong wiring.

I fear it is the display. Measuring the resistance between CANH and CANL show something around 115 ohms. Also the bridge of CANRX and CANTX on the STM32 doesn't light up the display (still only backlights). The flashing seems to be ok, see Logfiles attached. When I start only the STM32 the red light is permanent on, and the green light is flashing at intervals of maybe 1 sek, when the foccciCape comes up and CAN messages are flowing the green light flashes much faster, maybe 250ms - as mentioned from you.

[uhi22]

This sounds half-way good, the green light says that the software is running, and the CAN reception works fine.
I just soldered a new device (display+bluepill+cantransceiver), this works here, even if the bluepill is a fake (not recognized in the cubeIDE). I added new fotos and description of pitfalls in the github https://github.com/uhi22/TFT-with-CAN/t ... playbranch
The only remaining idea is to re-check the wiring of the display, maybe a shorted line or a bad connector / jumper cable.

[jrichl]

This sounds half-way good, the green light says that the software is running, and the CAN reception works fine.
I just soldered a new device (display+bluepill+cantransceiver), this works here, even if the bluepill is a fake (not recognized in the cubeIDE). I added new fotos and description of pitfalls in the github https://github.com/uhi22/TFT-with-CAN/t ... playbranch
The only remaining idea is to re-check the wiring of the display, maybe a shorted line or a bad connector / jumper cable.

I have measured now all the jumper cables, and all of them look good. It only could be just the display now anymore. The only optical difference that I can see between your Display and mine are the GND solderpoints on the Display, I had to connect the GND Points by cabling. Don't know if it helps but on the packaging of the display is a label that tells the following: If LCD no work, please contact with us. We have code send to you.

Don't know which code they mean but I send them an email, that my display doesn't work, we will see if I get something.

Otherwise I have to order a new display. Which one do you have?

[uhi22]

I have them from Aliexpress, similar to Amazon

Code: Select all

amazon.de/-/en/Fasizi-Module-ILI9341-Colour-Display/dp/B09Z27TYMK/ref=sr_1_35

The pinning is exactly the same as yours, but the print on the PCB is slightly different, I have the pin description on the front side, not on the back side. Also 2.8 inch, 240x320. Part number on PCB is ZJY280S0800TG01-ILI9341.
Single row, 8 pin, no touch, blue PCB.

[jrichl]

I have them from Aliexpress, similar to Amazon

Code: Select all

amazon.de/-/en/Fasizi-Module-ILI9341-Colour-Display/dp/B09Z27TYMK/ref=sr_1_35

The pinning is exactly the same as yours, but the print on the PCB is slightly different, I have the pin description on the front side, not on the back side. Also 2.8 inch, 240x320. Part number on PCB is ZJY280S0800TG01-ILI9341.
Single row, 8 pin, no touch, blue PCB.

hard to believe, but it wasn't the display. I'have changed the ESP32 and look how it works now. The software flashed on the STM32 is the same as on the old STM32 - no changes.

[uhi22]

Yeahhhh, time to celebrate Congratulations.
Always good to have a spare bluepill board for such cases. Maybe an even worse clone, or a pin was killed by ESD or something like this.

PS: But I see no CAN communication yet, hopefully the CAN reception works with the new STM32.

[jrichl]

Yeahhhh, time to celebrate Congratulations.
Always good to have a spare bluepill board for such cases. Maybe an even worse clone, or a pin was killed by ESD or something like this.

PS: But I see no CAN communication yet, hopefully the CAN reception works with the new STM32.

It is running. Thank you very much for your advice. It wouldn't have been possible without your great work and installation description. Next step will be the lightbulbs, then we will see how long the i3 is happy.

[uhi22]

FoccciCape &Co are moving to their new home

Plan is to integrate a controllable step-up for precharge and HV measurement.

[CCStoV2H]

Looks cool !

Are we etching closer to a CCS/V2H Testbox ?

I would be highly interested to test one &/or to participate in funding.

[hjdlsnbc]

Thanks for using the great BeagleBone Black for this project and not some terrible Raspberry Pi!

Is there some special reason why you are linking often some years old beaglebone images instead of the recent ones?
For example this here should be the latest classical image with latest 6.19 kernel for the beaglebone black https://files.beagle.cc/file/beagleboar ... 4gb.img.xz

Because there was a complain to have to press the boot-button every time at boot when you want SD-boot: This is the case if you have not wiped the emmc storage. Just wipe the emmc storage and then the build in bootloader in the MCU is not able to boot from emmc any more and would boot from sd-card.
If you have figured out your best software setup, then it is the best to use the build in emmc instead of a micro sd card.


In the wiki there is the question about 'bidirectional' chademo charger.
https://openinverter.org/wiki/Bidirecti ... ia_CHAdeMO

What is exactly been asked for? There are projects like
https://github.com/osexpert/ccs32clara-chademo
and
https://github.com/dalathegreat/Battery ... e#overview