The ZombieVerter VCU Project

Locked
User avatar
EV_Builder
Posts: 1199
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands
Has thanked: 16 times
Been thanked: 33 times
Contact:

Re: The ZombieVerter VCU Project

Post by EV_Builder »

johu wrote: Tue Aug 31, 2021 7:42 am
celeron55 wrote: Sun Aug 29, 2021 6:48 pm I would often consider it fine to use dynamic allocation when you only do it once at startup, and never free anything. This implies that when changing the configured components in the UI, the only acceptable thing to do is to save the configuration and reboot. This way you begin again with a blank heap to allocate into, and can allocate different objects.

Pointers to statically allocated instances could be more robust though and I often use them myself in more complex firmware. You can use contructors to reset static instances at any time by doing something like staticFooInstance = FooClass();, which will call the constructor of FooClass just like doing new FooClass();, but instead of doing dynamic allocation places the result into the static variable. This is obvious of course, but that's part of why it's good.
One possibility would be using placement new (https://en.cppreference.com/w/cpp/language/new). It allocates an object at a pre-allocated buffer of any type. Best to use uint32_t to have 4-byte alignment:

Code: Select all

#include <new>
static uint32_t buf[sizeof(Terminal)/sizeof(uint32_t)];

extern "C" int main(void)
{
   Terminal* test = new (buf) Terminal(USART2, termCmds);
}
Of course we wouldn't be using a specific class that we can just do sizeof() on but would need to come up with an expression that determines the maximum size of classes T1, T2, T3 at compile time.

So when changing parameter "InverterType" in the event handler just call new() on the selected inverter class (and maybe delete() on the current one? - might be easier to go destructor-less).

In the Makefile we need to switch to at least c++17. Brings up a few warnings in the existing code but nothing critical.
Maybe the biggest choices should be build compile time like with a #define. And the smaller optional stuff could be dynamic. Saying that it means going full blown c++. I wouldn't do that.

Maybe we should go full #define mode.
That means the best performance and smallest code/memory footprint. The disadvantage is that you need a new binary for each change in architecture, for me that won't be an issue anyway since every change will involve code anyway.

We could make a build server/scripting so people could click and
Download their binary.
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
User avatar
janosch
Posts: 306
Joined: Tue Jun 30, 2020 9:23 am
Location: London, UK
Has thanked: 67 times
Been thanked: 54 times
Contact:

Re: The ZombieVerter VCU Project

Post by janosch »

Stupid question: Can you run backwards and forwards at full power & RPM with the ZombieVerter? Or do you have to swap phases?

I read the manual for the resolve-ev controller which takes the same path, and they say if you want to switch forward and reverse you have to hardware swap two of the motor phases.
User avatar
Bratitude
Posts: 783
Joined: Thu Jan 02, 2020 7:35 pm
Location: Canada
Has thanked: 57 times
Been thanked: 168 times
Contact:

Re: The ZombieVerter VCU Project

Post by Bratitude »

janosch wrote: Fri Sep 10, 2021 1:16 pm Stupid question: Can you run backwards and forwards at full power & RPM with the ZombieVerter? Or do you have to swap phases?

I read the manual for the resolve-ev controller which takes the same path, and they say if you want to switch forward and reverse you have to hardware swap two of the motor phases.
That would be in the context of the inverter you are controlling.
-Leaf inverter most likely limits power in reverse, if contorting via can.
-gs450h, same situation, but may not be the case.
https://bratindustries.net/ leaf motor couplers, adapter plates, custom drive train components
User avatar
EV_Builder
Posts: 1199
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands
Has thanked: 16 times
Been thanked: 33 times
Contact:

Re: The ZombieVerter VCU Project

Post by EV_Builder »

janosch wrote: Fri Sep 10, 2021 1:16 pm Stupid question: Can you run backwards and forwards at full power & RPM with the ZombieVerter? Or do you have to swap phases?

I read the manual for the resolve-ev controller which takes the same path, and they say if you want to switch forward and reverse you have to hardware swap two of the motor phases.
It's best to change 'fireing' order so forward in the program is forward of the vehicle.
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
User avatar
janosch
Posts: 306
Joined: Tue Jun 30, 2020 9:23 am
Location: London, UK
Has thanked: 67 times
Been thanked: 54 times
Contact:

Re: The ZombieVerter VCU Project

Post by janosch »

EV_Builder wrote: Sat Sep 11, 2021 8:01 am
janosch wrote: Fri Sep 10, 2021 1:16 pm Stupid question: Can you run backwards and forwards at full power & RPM with the ZombieVerter? Or do you have to swap phases?

I read the manual for the resolve-ev controller which takes the same path, and they say if you want to switch forward and reverse you have to hardware swap two of the motor phases.
It's best to change 'fireing' order so forward in the program is forward of the vehicle.
Yes absolutely. I was talking 2nd gen Leaf inverter, which I heard limits you in reverse (not sure if torque, RPM, both or not true at all).

Update: Elsewhere in the forum this was discussed:
viewtopic.php?f=4&t=962
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: The ZombieVerter VCU Project

Post by celeron55 »

I'm trying to program and get running the Zombieverter VCU V1 board, with the GD32F107VCT6. I see others were able to get this working.

For me the code (the GD_Zombie branch, commit 94b0cc8) does build, and OpenOCD tells me the firmware uploads fine, but then the GD32F107 just... does absolutely nothing. There's no activity on the 8MHz oscillator, other than one pin being at 0V and one at 3.3V.

This is the OpenOCD command I'm currently using:

Code: Select all

/usr/bin/openocd -d2 -s /usr/share/openocd/scripts \
               -f interface/stlink-v2.cfg \
               -f target/stm32f1x.cfg \
               -c "init" -c "reset halt" \
               -c "flash write_image erase stm32_vcu.hex" \
               -c "reset" \
               -c "exit"
and it tells me it wrote the correct amount of bytes when comparing to the binary file:

Code: Select all

wrote 30720 bytes from file stm32_vcu.hex in 2.196691s (13.657 KiB/s)
Any ideas?

EDIT: Looks like I can get gdb to connect to OpenOCD and I can get to a breakpoint at the beginning of main(). Let's see...

EDIT: Here's stepping until death:

Code: Select all

Reading symbols from stm32_vcu.elf...
(gdb) target remote localhost:3333   
Remote debugging using localhost:3333
0x00000000 in ?? ()                  
(gdb) load                           
Loading section .text, size 0x669c lma 0x8001000
Loading section .init_array, size 0xc lma 0x800769c
Loading section .data, size 0xde0 lma 0x80076a8
Start address 0x08006548, load size 29832
Transfer rate: 13 KB/sec, 7458 bytes/write.
(gdb) b stm32_vcu.cpp:482            
Breakpoint 1 at 0x8001844: file src/stm32_vcu.cpp, line 482.
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) c                              
Continuing.                          
                                     
Breakpoint 1, main () at src/stm32_vcu.cpp:482
482         clock_setup();           
(gdb) s                              
484         ConfigureVariantIO();    
(gdb) s                              
0x08001848 in ConfigureVariantIO () at src/stm32_vcu.cpp:464
464         hwRev = HW_REV1;         
(gdb) s                              
484         ConfigureVariantIO();    
(gdb) s                              
0x0800184e in ConfigureVariantIO () at src/stm32_vcu.cpp:467
467         ANA_IN_CONFIGURE(ANA_IN_LIST);
(gdb) s                              
clock_setup () at src/hwinit.cpp:39  
39          RCC_CLOCK_SETUP();       
(gdb)                                
rcc_clock_setup_in_hse_8mhz_out_72mhz () at rcc.c:848
848             rcc_osc_on(RCC_HSI); 
(gdb)                                
rcc_osc_on (osc=osc@entry=RCC_HSI) at rcc.c:263
263             switch (osc) {       
(gdb)                                
277                     RCC_CR |= RCC_CR_HSION;
(gdb)                                
269                     break;       
(gdb)                                
rcc_clock_setup_in_hse_8mhz_out_72mhz () at rcc.c:849
849             rcc_wait_for_osc_ready(RCC_HSI);
(gdb)                                
rcc_wait_for_osc_ready (osc=osc@entry=RCC_HSI) at rcc.c:242
242     {                            
(gdb)                                
243             while (!rcc_is_osc_ready(osc));
(gdb)                                
rcc_is_osc_ready (osc=osc@entry=RCC_HSI) at rcc.c:222
222             switch (osc) {       
(gdb)                                
232                     return RCC_CR & RCC_CR_HSIRDY;
(gdb)                                
Warning:                             
Cannot insert breakpoint 0.          
Cannot access memory at address 0xfffffff9
                                     
0xfffffffe in ?? ()                  
(gdb)                                
Cannot find bounds of current function
(gdb)
It's clearly failing inside the clock setup, right when it tries to enable the HSI, which is the fast internal oscillator. And this is repeatable. I guess it fails at the next line, which is

Code: Select all

rcc_set_sysclk_source(RCC_CFGR_SW_SYSCLKSEL_HSICLK);
. Ehm... is the GD32 chip broken?

Or is this not supposed to work this way? libopencm3 has its own static library for the gd32 (libopencm3_gd32f1x0 instead of libopencm3_stm32f1 used here), but it's missing so many of the peripheral drivers it's unusable, so I can't really try it.
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

Have you loaded the bootloader?
I'm going to need a hacksaw
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: The ZombieVerter VCU Project

Post by celeron55 »

No, I'm not using any bootloader. Not that I really even know where to get one. I'm flashing the entire thing using an stlink v2 clone.
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: The ZombieVerter VCU Project

Post by celeron55 »

Now found a script I had used for programming the bootloader on an openinverter board before and ran it here, it was as so:

Code: Select all

openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c "program stm32_loader.bin verify reset exit 0x08000000"
It ran succesfully. Then I used a script from that openinverter project to program the firmware, which was this, of course originally it programmed stm32_foc.bin or stm32_sine.bin but I changed that:

Code: Select all

openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c "program stm32_vcu.bin verify reset exit 0x08001000"
It seemed to run succesfully also. However, still nothing happens.

EDIT: I don't have any olimex wifi boards around but I guess I'll connect a serial adapter and try to see if the bootloader is alive.

EDIT2: Eh... I now see a clear 44Hz signal at the oscillator when I power up the board (yes, tens of Hz). This can't be right?

EDIT3: It should have 3.3V on the TX line (from GD32) if it was alive, and that certainly isn't the case. Both TX and RX are 0V.
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

You need to use the hex files for initial programming. At least I do.
I'm going to need a hacksaw
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

Timed charge, charge duration timer and cabin heater options now undergoing testing.
Attachments
2021-09-17 18.43.14.jpg
I'm going to need a hacksaw
User avatar
mdrobnak
Posts: 692
Joined: Thu Mar 05, 2020 5:08 pm
Location: Colorado, United States
Has thanked: 1 time
Been thanked: 5 times

Re: The ZombieVerter VCU Project

Post by mdrobnak »

Lots of progress here!

RTC stuff is fun. Especially when you see how awful it really is, LOL.

Again, I'll join back up here soon.

-Matt
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

Ampera/Volt heater now running under VCU control. Now have to integrate with E46 ihka. Also got a vw unit which I believe is LIN controlled for further zombiefication.
Attachments
2021-09-22 13.37.11.jpg
2021-09-22 12.41.50.jpg
I'm going to need a hacksaw
Alibro
Posts: 829
Joined: Sun Feb 23, 2020 9:24 am
Location: Northern Ireland
Has thanked: 248 times
Been thanked: 144 times
Contact:

Re: The ZombieVerter VCU Project

Post by Alibro »

Jack Bauer wrote: Wed Sep 22, 2021 12:48 pm Ampera/Volt heater now running under VCU control. Now have to integrate with E46 ihka. Also got a vw unit which I believe is LIN controlled for further zombiefication.
So is that spout where you pour in the electricity to charge it? :lol:
I need a bigger hammer!
Alibro
Posts: 829
Joined: Sun Feb 23, 2020 9:24 am
Location: Northern Ireland
Has thanked: 248 times
Been thanked: 144 times
Contact:

Re: The ZombieVerter VCU Project

Post by Alibro »

Oops double post
I need a bigger hammer!
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

Thanks to Dala I now have a full GEN3 Leaf stack for zombification. It will feature in the latest conversion project now dubbed "The Trition Missile".
Attachments
2021-10-02 15.20.07.jpg
I'm going to need a hacksaw
Alibro
Posts: 829
Joined: Sun Feb 23, 2020 9:24 am
Location: Northern Ireland
Has thanked: 248 times
Been thanked: 144 times
Contact:

Re: The ZombieVerter VCU Project

Post by Alibro »

Jack Bauer wrote: Sun Oct 03, 2021 9:58 am Thanks to Dala I now have a full GEN3 Leaf stack for zombification. It will feature in the latest conversion project now dubbed "The Trition Missile".
I thought you were slowing down and taking it easy for a while. :?
I need a bigger hammer!
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

You can thank the glacial pace of house conveyancing.
I'm going to need a hacksaw
andrewjenkins34
Posts: 56
Joined: Thu Dec 17, 2020 1:48 am
Has thanked: 1 time
Been thanked: 2 times

Re: The ZombieVerter VCU Project

Post by andrewjenkins34 »

Is that the 160kw setup?
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

110kw
I'm going to need a hacksaw
kevpatts
Posts: 67
Joined: Mon Jul 19, 2021 1:55 pm
Location: Dublin, Ireland
Been thanked: 8 times

Re: The ZombieVerter VCU Project

Post by kevpatts »

Anyone have some spare digital pots (IC21 & IC22; AD5160BRJZ5-R2)? My two got broken during the soldering process and I can't seem to recover them. Farnell don't sell them and RS-online are out of stock.
Koppi
Posts: 18
Joined: Thu Sep 02, 2021 6:10 pm

Re: The ZombieVerter VCU Project

Post by Koppi »

Hello conversion friends,

I am Peter from Germany and a beginner in converting vehicles !
I will install a Leaf Gen1 in a Mercedes W123.
Both cars I already have and the Leaf components I have already removed
I have already ordered the ZombieVerter

I have a request to the specialists

Which of the Leaf components can I continue to use ?
Motor and controller is clear !

BMS ?
Charger ?
DC/DC ?



I have seen in the video that Damien has made the Gen2 run completely

Does this also work with the Gen1 ?


Thanks for your help !
Peter
P.S.Mangelsdorf
Posts: 753
Joined: Tue Sep 17, 2019 8:33 pm
Location: Raleigh, NC, USA
Has thanked: 89 times
Been thanked: 92 times

Re: The ZombieVerter VCU Project

Post by P.S.Mangelsdorf »

Koppi wrote: Wed Oct 06, 2021 8:23 am Hello conversion friends,

I am Peter from Germany and a beginner in converting vehicles !
I will install a Leaf Gen1 in a Mercedes W123.
Both cars I already have and the Leaf components I have already removed
I have already ordered the ZombieVerter

I have a request to the specialists

Which of the Leaf components can I continue to use ?
Motor and controller is clear !

BMS ?
Charger ?
DC/DC ?



I have seen in the video that Damien has made the Gen2 run completely

Does this also work with the Gen1 ?


Thanks for your help !
Peter
These questions should be asked over here:
viewforum.php?f=22
If at first you don't succeed, buy a bigger hammer.

1940 Chevrolet w/ Tesla LDU - "Shocking Chevy" - Completed 2023 Hot Rod Drag Week
Koppi
Posts: 18
Joined: Thu Sep 02, 2021 6:10 pm

Re: The ZombieVerter VCU Project

Post by Koppi »

Hi
I think this is better if it is here

it is about the zombieverter

please for a technical information

Thanks
Peter
User avatar
EV_Builder
Posts: 1199
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands
Has thanked: 16 times
Been thanked: 33 times
Contact:

Re: The ZombieVerter VCU Project

Post by EV_Builder »

celeron55 wrote: Sun Sep 12, 2021 1:40 pm Now found a script I had used for programming the bootloader on an openinverter board before and ran it here, it was as so:

Code: Select all

openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c "program stm32_loader.bin verify reset exit 0x08000000"
It ran succesfully. Then I used a script from that openinverter project to program the firmware, which was this, of course originally it programmed stm32_foc.bin or stm32_sine.bin but I changed that:

Code: Select all

openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c "program stm32_vcu.bin verify reset exit 0x08001000"
It seemed to run succesfully also. However, still nothing happens.

EDIT: I don't have any olimex wifi boards around but I guess I'll connect a serial adapter and try to see if the bootloader is alive.

EDIT2: Eh... I now see a clear 44Hz signal at the oscillator when I power up the board (yes, tens of Hz). This can't be right?

EDIT3: It should have 3.3V on the TX line (from GD32) if it was alive, and that certainly isn't the case. Both TX and RX are 0V.
There came 2 hex files. One bootloader and one program.
With the STlink utility you can upload first the bootloader and then the program.
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
Locked