Rich mans ChaDeMo charger (3-phase)

[johu]

It must be in run mode to read these

[Kelju]

As I wrote. Goes to run mode and there are no errors, but still no current reading.

[Kelju]

Is it possible that something goes wrong in my compiling?
Can somebody attach here a precompiled bin?

[johu]

As I wrote. Goes to run mode and there are no errors, but still no current reading.

Oh, missed that.

Binary attached. In run mode there are no further conditions for displaying "idc". So it's not il1 or il2 but idc, mapped to Pin A5

EDIT: removed bin as it was defunct

[Kelju]

Binary attached.

Flashed in that FW and now my Web interface is showing strange things:
When I apply voltage to IN_START -> din_emcystop goes "on" in the spot values.
When I apply voltage to IN_EMCYSTOP -> din_ocur goes "on" in the spot values.
soc is showing the LV supply voltage.
I have 10V supplied as the battery voltage, but udc=0V in the spot values and 10V is shown in uout (changes according to udcgain).
Seems that everything is somehow shifted in the spot values view.
When applying voltage to IN_START, the spot values indicates "RUN" mode, but right away there comes an error message "communication broblem between ESP and STM". Inverter messages in the dash show "STOP - OVERCURRENT".

I even soldered an extra 22uF ceramic capacitor on the ESP 3V3 supply to filter out conducted interference from the PWM. Did not help.
I also placed a metal shield between the ESP and STM to rule out radiated interference. Did not help.

This all happened with only the mainboard. I do not yet have the PWM output connected to any IGBT gate driver and no switching action on any power stage.

[Kelju]

So, as the precompiled FW was acting strange, I reverted to playing around with the one that I compiled myself.
I was suspecting the IIR filter function and took it out from the current value.
Sure enough, I started seeing values in RUN mode. Then I noticed that for some reason, I had a negative value in the idcflt parameter.
Included the IIR filter back in to the code and changed the idcflt to a positive value... WORKS!

Really do not understand what is causing the strange behavior of the precompiled FW, but at least I am able to continue on my experiments now.

[Kelju]

Moving on from obsticle to another. Now the inputs seem to work, but I get no PWM output.
I have active low setting, so in off-mode the PWM1-TOP is high. When the system goes to run-mode, PWM1-TOP goes low and stays there.
It even stays there if I artificially generate a current sensor value higher than the idcspnt. There is no PWM in any other PWM output pin either.
Dashboard indicates no errors.

I also made a special mod to the code so that I can directly set TIM_OC1 value with a parameter on the spot values, but still no PWM.
pwm_timer_isr is working as the current value is being updated, but seems like the PWM output is for some reason not enabled...

[Kelju]

Not sure if this is in anyway related, but when I cloned the repository, the magical "make get -deps" command resulted in some errors, so I just copied all the internals of the related libopencm3 and libopeninv folders from a working Zombie project. At least the compiling started working like that...
Now I am starting to wonder if I am missing something crucial and decided to try with a fresh clone of the stm32-charger repo.
As I write "make get -deps", I get this kind of an error messages:

Code: Select all

Submodule 'libopencm3' (https://github.com/jsphuebner/libopencm3.git) registered for path 'libopencm3'
Submodule 'libopeninv' (https://github.com/jsphuebner/libopeninv.git) registered for path 'libopeninv'
Cloning into '/home/kelju/Documents/Orig_stm32-charger/stm32-charger/libopencm3'...
Cloning into '/home/kelju/Documents/Orig_stm32-charger/stm32-charger/libopeninv'...
Submodule path 'libopencm3': checked out 'b70da8dfc0635192753c9929d715ee6f57f23772'
Submodule path 'libopeninv': checked out 'b9751207b4853c244b107c895d5da83919862ae7'
  MAKE libopencm3
make[1]: Entering directory '/home/kelju/Documents/Orig_stm32-charger/stm32-charger/libopencm3'
  GENHDR  include/libopencm3/stm32/f0/irq.json
/usr/bin/env: ‘python’: No such file or directory
make[1]: *** [Makefile:59: include/libopencm3/stm32/f0/irq.json.genhdr] Error 127
make[1]: Leaving directory '/home/kelju/Documents/Orig_stm32-charger/stm32-charger/libopencm3'
make: *** [Makefile:123: get-deps] Error 2

[johu]

/usr/bin/env: ‘python’: No such file or directory

Read and understand
You don't have python installed

Not sure why you're not seeing PWM. You've already modified the code anyway, you can achieve a fixed PWM by setting pwmmin and pwmmax to the same value.

[Kelju]

Python 3.10.12 is installed as confirmed by "python3 -V"

[johu]

Yes but it is explicitly looking for the "python" command not "python3". So that you have to fix my copying/linking

[Kelju]

Okay, I'll look into that to get that issue sorted.
In the meantime I read the STM32 reference manual section on the timers and specifically the PWM settings.
The idea was to understand the meaning of the code in the hwinit.cpp.
I started experimenting with replacing some of the settings and finally got PWM output.
Then I started testing that what is the issue with the existing code as I do not get PWM.
turns out that it was a single line of code that needed to be commented out...

Code: Select all

//   timer_set_break_polarity_high(PWM_TIMER);

If I have that line included, the PWM output goes low (active low) immediately as RUN mode is entered.
When I have that line commented out, everything works. I was able to buck a steady 2A current regulated output from a 50V input to the converter.
The purpose of that single line of code is to have a defined output state in an emergency shut down, right? Seems like an important feature...

[johu]

The purpose of that single line of code is to have a defined output state in an emergency shut down, right? Seems like an important feature...

Yes for example the current window comparator is connected to that input to immediately shut down when ocurlim is exceeded. With the Prius IPM you might as well leave it commented out as it protects itself flawlessly