The ZombieVerter VCU Project

[Jack Bauer]

Gahhh! confusion:) so say your throttle runs from 100 to 1000 over its range. Now you want to ensure that on release you always go under potmin. So I'd set potmin to 110 in this example. We then want to ensure we hit full throttle before the end of mechanical range. So potmax at 990 in this example. This is how openinverter has always worked unless I have seriously screwed up the last 6 years (quite possible!).

[Jack Bauer]

[johu]

The Zombie is the other way, it wants min and max to be inside the mechanical range. Which is fine if you know that, I’ll make a note of it in the wiki.
But just suggesting it might be an improvement to do it the other way, and then you have fault detection.

There is fault detection, but only when throttle goes more then 200 digits (160 mV) out of range.

[Alibro]

Great update Mr Bauer. It looks amazing.

[Jack Bauer]

VCU now running on 32 bit floating point math thanks to Johannes. All the torque controls are now butter smooth :

[Alibro]

This just keeps getting better.
Keep up the great work.

[Jack Bauer]

[Jack Bauer]

[Jack Bauer]

[EV_Builder]

CAN Bus timing.

Since i needed another clock frequency i started the lovely journey of changing the CanBus timing.
What i found was this table:

Code: Select all

//CAN TABLE FOR 72MHZ//36MHZ CAN HW BUS  SPEED
// static const CANSPEED canSpeed[Can::BaudLast] =
// {
//    { CAN_BTR_TS1_9TQ, CAN_BTR_TS2_6TQ, 9 }, //250kbps
//    { CAN_BTR_TS1_[b]4[/b]TQ, CAN_BTR_TS2_[b]3[/b]TQ,[b] 9 [/b]}, //500kbps
//    { CAN_BTR_TS1_5TQ, CAN_BTR_TS2_3TQ, 5 }, //800kbps
//    { CAN_BTR_TS1_6TQ, CAN_BTR_TS2_5TQ, 3 }, //1000kbps
// };

Now in order to have the new data in. I needed a tool so i found one at: http://www.bittiming.can-wiki.info/
If i fill in 60% i indeed find this, i focust on 500K for now:

Question: Why are we using 60%? and not a bit higher?

[Bassmobile]

Hello. Bought two of these boards from the EVBMW webshop. They are equipped with the GD32F107 plc. Trying to determine if the GigaDevices version of this hardware is now considered abandonware? Looking at the wiki ZombieVerter_VCU it says

NOTE. Early boards fitted with the GD chip require different firmware to the ST board.

The wiki does not provide any more information about this.
Looking at the related GigaDevices firmware GD_Zombie branch it hasn't seen updates for 10 months and is 151 commits behind master.

Is this GD version of the ZombieVerter VCU going to receive updates?

[chuuux]

Is this GD version of the ZombieVerter VCU going to receive updates?

viewtopic.php?p=33758#p33758

[johu]

When I have the time I can try my hand at auto detection. That way no separate branch would be needed.

[Bassmobile]

Is this GD version of the ZombieVerter VCU going to receive updates?

viewtopic.php?p=33758#p33758

Thanks for that. I had searched the forum for "GigaDevices, & GD32F107" before asking, but those searches didn't turn up that post.

As was requested in that post. I've updated the WIKI to reflect this information, with link to that post.
I've also created an issue #21 on the GitHub repository.

When I have the time I can try my hand at auto detection. That way no separate branch would be needed.

@Johu, please see the aforementioned github issue #21 and if you can find time, post an update there please. Or at minumum.. point me in the direction of the previously mentioned items that you identified that need attention and I will transpose the information on the repository issue tracker.

[johu]

One change I had figured out was that adc_start_conversion_regular(ADC1) will hang because it waits for a flag that never goes high. The ADC conversion works fine without it. To my surprise that change does not show in the GD_Zombie branch (anain.cpp in libopeninv). I think something was different with CAN also but I didn't work on that.

So I doubt the GD_Zombie branch will run on a GD

[Bassmobile]

So I doubt the GD_Zombie branch will run on a GD

Ooff.. Well that is both frustrating, and reassuring. suppose i shall stop bashing my head whilst trying to get it to run as-is on my GD Zombie boards.

The ADC conversion works fine without it.

Just for the sake of context, and in case anyone else is trying to follow along.. he's talking about these few bits of code

That's a starting point.. i guess?

[Uppertown]

Following with extreme interest - I'd just about given up in dispare as I was totally out of my depth.

[Jack Bauer]

I'll double post this here and on the support thread just in case. The reason the modification to anain is not present on the GD branch of the repo is that I was (and am) unable to push a modification to libopeninv. Not sure why but probably just my own lack of understanding of Git. Anyway, here are binaries compiled from the current GD branch and tested on my GD board here this morning. Working perfectly. Please rename to stm32vcu before uploading and if someone could update the wiki with this info it would be greatly appreciated by not just me but by those who may encounter this question in the future when I am no longer around.

[Jack Bauer]

Further to my post this morning I proceeded to modify the current master branch from the repo as follows :

anain.cpp line 68 comment out :
// adc_start_conversion_regular(ADC1);// Comment out for GD MCU

stm32_can.cpp lines 305,306 and 308 modify as follows :

gpio_set_mode(GPIO_BANK_CAN2_RE_RX, GPIO_MODE_INPUT, GPIO_CNF_INPUT_PULL_UPDOWN, GPIO_CAN2_RE_RX);
gpio_set(GPIO_BANK_CAN2_RE_RX, GPIO_CAN2_RE_RX);
// Configure CAN pin: TX.-
gpio_set_mode(GPIO_BANK_CAN2_RE_TX, GPIO_MODE_OUTPUT_50_MHZ, GPIO_CNF_OUTPUT_ALTFN_PUSHPULL, GPIO_CAN2_RE_TX);

Compiled as normal and runs on the bench on my GD board. Binaries attached. I'm not sure if all the peripherals are working but will run on my test bench LEAF setup later today or tomorrow if time allows. This post will be copied into the support thread to ensure visibility and I would hope that this would now motivate someone to update Wiki and Github (Not you Johannes).

Ensure you rename the binaries to stm32_vcu.xxx to ensure no wifi issues.

[Bassmobile]

Just pulled a fresh clone the repository and made sure that specify to gitto recursively clone submodules!

On the command line that looks like this;

Code: Select all

git clone --recurse-submodules git@github.com:damienmaguire/Stm32-vcu.git

That pulls in copies of libopeninv, etc...

Just testing a rebase of GD_zombie branch over the head of the master branch. The diff shows minimal conflicts, a few commented out lines and a few custom bits of config code.

This seems like the best route;

When I have the time I can try my hand at auto detection. That way no separate branch would be needed.

Does anyone have an experience with doing auto-detection? I web searched for examples but didn't find anything really promising.

[johu]

Does anyone have an experience with doing auto-detection? I web searched for examples but didn't find anything really promising.

Well, for example checking that flag that never shows on GD would be one way of auto-detecting.

[Uppertown]

[/quote]
Well, for example checking that flag that never shows on GD would be one way of auto-detecting.
[/quote]


How reliable is that though? remember my VCU would sometimes start working if left long enough, I'm very much guessing but maybe it was random noise that just happened to look like the flag?????

[blasaab]

Hi im trying to build my own board for a Leaf and order pcb from JLCPCB but is there a Component list for this?
I have search but only found for leaf_inv_controller

[PaulHeystee]

Yeah, I was looking for the BOM also, ideally the excel sheet needed for JLCPCB.

[EV_Builder]

Well, for example checking that flag that never shows on GD would be one way of auto-detecting.
[/quote]

How reliable is that though? remember my VCU would sometimes start working if left long enough, I'm very much guessing but maybe it was random noise that just happened to look like the flag?????
[/quote]

I think we can ask the chip for some serial#?
Or revision?

Would be good to do that test only once and save it as a parameter.
If detection fails we overwrite the setting and job done.

Personally i like more compile time changes and building with make 2 versions of the hex/bin.
But i guess its a taste thing... the reason is that compile time variations means no IF statements in the code when we have a variation point.
(higher performance).
Also for the developer it makes it clearer (syntax highlighting) on which variation he is working.