Zombiverter not switching to charge mode with Leaf PDM

[Rustybkts]

Which PDM have you got? What year? Was it natively with a type2 socket or did you put type2 on it yourself?

My PDM is a Gen 2 from a 2015 Leaf. It started with a Type 1 but I changed it to a Type 2. A 2.7k resistor is in the socket but has been tried without as well.

[Kelju]

I have found an intermediate solution to my issue of not charging.
This is how my Ms10Task in the stm32VCU.cpp looks like:

Code: Select all

    if (Param::GetInt(Param::opmode) == MOD_RUN) //!!!THROTTLE CODE HERE//
    {
        torquePercent = utils::ProcessThrottle(ABS(previousSpeed)); //run the throttle reading and checks and then generate Potnom


        //When requesting regen we need to be careful. If the car is not rolling
        //in the same direction as the selected gear, we will actually accelerate!
        //Exclude openinverter here because that has its own regen logic

        if (torquePercent < 0 && Param::GetInt(Param::Inverter) != InvModes::OpenI)
        {
            if(Param::GetInt(Param::reversemotor) == 0)
            {
                rollingDirection = previousSpeed >= 0 ? 1 : -1;
            }
            else
            {
                rollingDirection = previousSpeed >= 0 ? -1 : 1;
            }
            //When rolling backward while in forward gear, apply POSITIVE torque to slow down backward motion
            //Vice versa when in reverse gear and rolling forward.
            if (rollingDirection != requestedDirection)
            {
                torquePercent = -torquePercent;
            }
        }

        torquePercent *= requestedDirection; //torque requests invert when reverse direction is selected

        selectedInverter->Task10Ms();
    }
    else
    {
        torquePercent = 0;
        utils::displayThrottle();//just displays pot and pot2 when not in run mode to allow throttle cal
        if(Param::GetInt(Param::din_forward) == 0)
        {
        selectedInverter->Task10Ms();
        }
    }

If I want to charge, I will have "Forward==0" and the "selectedInverter->Task10Ms();" will be executed out side of RUN mode.
If I want to drive, I need "Forward==1", which is anyway quite natural.
There is one drawback though, the charging only works from a fresh hardware reset, meaning that I need to remove the permanent 12V supply momentarily before charging as the PDU apparently needs to be in sleep, when the plug is inserted.

I am not suggesting that this would be the final solution (we obviously need a more solid solution for the "general public"), but maybe these findings help in finding the solution.

[Kelju]

Here is a datalog of a successful charging event after a hardware reset with the above described code modifications:

20250109_V200A_MAINmod_charging.zip

(463.21 KiB) Downloaded 318 times

[tom91]

This is still on my list to look into. Hope to have time tomorrow or in the weekend.

Will be a little invasive to get work. So will take a bit of testing on my end first on the bench simulating CAN wake ups.

[Kelju]

I think you are on the right track on this issue.
I forgot to mention in my earlier post, but the problem seems to only be the startup of the PDM into charging mode. Once the EVSE relay is closed and charging power is flowing, the PDM does not need the inverter 10ms task. I confirmed this by applying the forward switch while charging.

[tom91]

I think you are on the right track on this issue.

Spent the time today to pull and pick the code apart resulting a new Leaf specific CAN frame generator .cpp. Also now includes waking up on pdm 0x679 and trying to have everything shut down when going into OFF mode.

https://github.com/Tom-evnut/Stm32-vcu/ ... te-01-2025

I made only one tweak in the STM32_VCU rest should be easy to just copy across.

The code has been bench tested, there are arbitrary time outs, so when the PDM sends 0x679 it has 100 x 100ms to get the Zombie into Charge mode.
When the Zombie goes into off mode it also currently waits 100 x 100ms before telling the CAN devices to sleep.

Please test this on your build and provide me some logs and feedback.

[Kelju]

Thanks for taking the time to investigate this issue, Tom.
I cloned your latest FW and made my changes to cope with my setup, then went ahead and tested.
Driving works, then I went to off-mode and wait several minutes to make sure all units are sleeping.
Then plugged in the charging. Pre-charge works and system goes to charge mode, but EVSE relay does not click and there is no charging power.

Then I made another test with a fresh start after hardware reset, but still no charge power. Here is a datalog of the failed charging attemp.
First I apply permanent 12V, then in a few seconds, I plug in the charger, wait for the EVSE to apply power (never does), then disconnect the charger and wait for a while in off-mode until switching off the datalogging.

20250111_TomsTestFW_charging_attempt.zip

(554.07 KiB) Downloaded 311 times

[tom91]

Driving works, then I went to off-mode and wait several minutes to make sure all units are sleeping.
Then plugged in the charging. Pre-charge works and system goes to charge mode, but EVSE relay does not click and there is no charging power.

Can you make a log of this too? I want to see what the pdm gets up to in this case also.

Will review your log

[Kelju]

Okay, I will do that.
How long should I wait after switching off from RUN mode, before I plug in the charger?

[tom91]

Thanks for taking the time to investigate this issue, Tom.
I cloned your latest FW and made my changes to cope with my setup, then went ahead and tested.
20250111_TomsTestFW_charging_attempt.zip

You made some breaking changes.

I can see 0x50B happnening and not the 10ms messages, so you made mistakes.

Same here I see the BMS messages not insync with the 0x50B which is not possible with the code.

To see if CAN has stopped there is now a spotvalue "CanAct"

[Kelju]

Okay. I'll make a new test, but this time without my changes.

[Kelju]

Now I just cloned and directly compiled your V2.21A without any changes.
The first log is...
- Going into RUN-mode and spinning the motor (works fine)
- Going into OFF-mode and waiting a few seconds (>10 sec)
- Plugging in the charger and waiting a few seconds (System goes into charging mode, but EVSE relay not applied and no charging power)
- Plugging out the charger, system goes to OFF-mode
- Waiting a few seconds after stopping the logging
Second log is...
- Trying to initiate charging after HW reset, but no difference in behavior, still no charging power applied.

20250111_OrigTomsTestFW_charging_attempt.zip

(1.51 MiB) Downloaded 306 times

[tom91]

Thank you for the quick log, will review this. I feel we are getting close.

[tom91]

Now I just cloned and directly compiled your V2.21A without any changes.
The first log is...
- Going into RUN-mode and spinning the motor (works fine)
- Going into OFF-mode and waiting a few seconds (>10 sec)

Can you look at the CAN log and CanAct param to see it go to sleep. I have not seen a long with a start up.

You can change the lines

Code: Select all

SleepCount = 100;//10s shut down counter reset

to 10 instead of 100 should speed this up.

https://github.com/Tom-evnut/Stm32-vcu/ ... eafMng.cpp

Are you sure you have fully replaced the Leafinv.cpp and nissanpdm.cpp? The CAN messages still look messed up.

[Kelju]

I am really a Github n00b and for that reason I made a mistake in the cloning.
I was compiling the default branch, hence missing the whole LeafMng...
Now I cloned with the -b extension and double checked that I have all the newly added files.

Not sure if I still have time to test today, but just wanted to let you know, that at least there is a clear error on my part.
Taking this into account, this new code might very well work. Sorry for the misunderstanding.

[tom91]

Not sure if I still have time to test today, but just wanted to let you know, that at least there is a clear error on my part.

No worries, we are all here to learn. I am more then happy to help people learn. You are being very careful in your testing and providing feedback so thank you for doing that.

[Kelju]

I was too curious to know, so I had one more go at it now, that I am actually compiling the correct version...
And sure enough - Driving and Charging both work!
Here is a datalog of the operation.
- Starting the datalog first and then applying the permanent 12V power
- Going into RUN-mode and spinning the motor (works fine)
- Going into OFF-mode and waiting a few seconds (>10 sec)
- Plugging in the charger and waiting a few seconds (System goes into charging mode, EVSE relay switches and we have charging power!)
- Plugging out the charger, system goes to OFF-mode
- Waiting a few seconds after stopping the logging

20250111_OrigTomsTestFWv222A_Driving_and_charging.zip

(834.11 KiB) Downloaded 297 times

[tom91]

And sure enough - Driving and Charging both work!

Good man, thank you for testing and logging even when working

[Kelju]

Good evening. I hate to bring bad news, but after testing a bit further, I have to say we still have issues.
Now the charging mode activates consistently and the charging power starts to flow, but only at a very low level and the power does not follow the request according to the parameter Pwrspnt.

Here is a log where...
- I start datalogging while system is in sleep
- Plug in and charging power starts flowing (only around 150mA charging current to battery, even if something like 3,5A would be expected with Pwrspnt=1500)
- I change the Pwrspnt in sequence: 500, 1000, 1500, 2000, etc. (charging current stays low the whole time)
- I change the Pwrspnt=200 and remove the plug
- Wait for the equipment to sleep and stop the datalogging

20250114_OrigTomsTestFWv222A_charging.zip

(841.06 KiB) Downloaded 329 times

And yes, the charging works and follows the Pwrspnt with my hacky intermediate FW where I use the Forward=0 switch to enable charging...
Although, I have to admit that also with that FW, the power drops intermittently to a low value for a short time in a few seconds sequence.

[tom91]

Thank you for the log and further testing. Will review this possibly not doing the allowed power properly.

[tom91]

And yes, the charging works and follows the Pwrspnt with my hacky intermediate FW where I use the Forward=0 switch to enable charging...
Although, I have to admit that also with that FW, the power drops intermittently to a low value for a short time in a few seconds sequence.

This is captured in your log? I will compare this situation to my code log and analyze.

[Kelju]

This is captured in your log? I will compare this situation to my code log and analyze.

No, it is not in the previous log of your V2.22A, but I went and took a datalog for you.

This is the datalog of the Main branch V2.20A FW with my changes to the Stm32.ccp to execute the Inverter 10ms task outside RUN mode if FORWARD=0:
- Starting with Pwrspnt=500 (battery current around 1A)
- Gradually increasing the Pwrspnt value 1000, 1500, 2000 (Battery current rises on each increase as expected, current is the 0x3C3 from CAB300)
- Finally, the current is 6.5A at Pwrspnt=2500

20250114_MainBranchFWv220A_KeljuMod_charging.zip

(807.83 KiB) Downloaded 293 times

[tom91]

This is the datalog of the Main branch V2.20A FW with my changes

Okay so there is an issue with the UDC and IDC spot value being properly translated for the BMS message 0x1DB. Do they show up as they should on your spot values with my firmware version, or did you do changes to get them from some other source?

I will bench test this tomorrow as I believe this is one of the messages where I cleaned up some of the very old and not "100%" understandable way of reading spotvalues.

[tom91]

I will bench test this tomorrow as I believe this is one of the messages where I cleaned up some of the very old and not "100%" understandable way of reading spotvalues.

Bench test confirms errors in my population of voltage and current into the BMS spoof message, will fix now.

EDIT
Update for fixing the mapping issue, will review logs to see if anything else is not behaving. But if you get a chance it be good to test with this change.

https://github.com/Tom-evnut/Stm32-vcu/ ... c0ad8cf83e

[Kelju]

Bench test confirms errors in my population of voltage and current into the BMS spoof message, will fix now.

EDIT
Update for fixing the mapping issue, will review logs to see if anything else is not behaving. But if you get a chance it be good to test with this change.

https://github.com/Tom-evnut/Stm32-vcu/ ... c0ad8cf83e

Finally had some time to test this and I am happy to let you know, that the charging power follows the request as expected.
Thank you once again Tom!