Trouble contributing to Stm32-vcu

[DerekSavage]

I have written some code on an Arduino to control can signals to my dash, and I thought I would try contributing to Stm32-vcu.
I forked the project, and after an hour or two I downloaded and compiled the codebase and did a UART Update to the zombieverter.

My goal for the night was to get some new code displayed on the web interface, so while playing around I changed the name of 'Leaf_Gen1' to 'Leaf_Genn1' and saw the dropdown menu also had my change. Satisfied, I reverted that change and went to bed.

It's been a few days now, and no matter what I do I can not get rid of this extra letter, or do anything, really.

image.png (7.08 KiB) Viewed 5437 times

I have tried:
- deleting the project directory and recloning it
- clearing the gcc cache
- cleaning build artifacts
- compiling the project from another computer (windows)
- compiling the project on a virtual machine (ubuntu)
- deleting my github repository and reforking
- compiling the code directly from damien's Stm32-vcu project
- Mixing and matching from above

The weird part is, if I go to https://github.com/damienmaguire/stm32-vcu/releases and download version 2.00A and upload that bin file, the leaf inverter goes back to 'Leaf_Gen1'. But (seemingly) if I take that code and compile it myself, 'Leaf_Genn1'.

My head has been spinning on this. Any advise would be greatly appreciated.

[Pete9008]

That does seem very odd, sounds like you have rules out the PC build environment as being responsible.

Bit of a long shot but have you tried a full stm32 chip erase between each code update (note - this will mean reloading the bootloader as well). This shouldn't have any effect as the units string is always stored as part of the program rather than with the parameters in flash but might be worth a try.

Another long shot - worth doing a full erase and reprogram of the ESP too (both program and file system) just in case it's a problem with the stm32 program image that is stored in its file system (it's temporarily stored there between being uploaded to the web interface and being sent to the stm32 during UART programming). Edit - thinking about it this seems a little more likely but does depend on the exact file names you used for the bin files when uploading, are you using exactly the same name each time or a different one for your build?

Edit - I'd also try programming both versions using an stlink if you have one. The more I think about it the more suspicious I am of the UART upload and an ESP filesystem issue, the stlink would bypass all of that.

[DerekSavage]

I think tomorrow I will try with the stlink as I do have one lying around somewhere..

Although, now that you mention it I had always been uploading Stm32_vcu.bin when I compiled myself, but when I used damien's version, I already had one downloaded so it was uploading as 'Stm32_vcu(1).bin'. I will see if changing the name helps at all because it's easier.

[DerekSavage]

Well looks like it's having some other issues at the moment. I can upload the .bin but it does not give me a loading bar. My thought is maybe the battery voltage is too low? It's in the car and the battery may need to be charged. I will take it out of the car and put it on the bench for the stlink anyways so we can see if that's true.

[DerekSavage]

I put it on the bench and it would let me upload again. I tried several times, but the .bin would only give me the loading bar if it was named stm32_vcu.bin.I also cloned Damien's repository and compiled it and the letter persists. But I again tried downloading from stm32_vcu/releases and the letter is gone.

I was looking for my stlink for awhile today, but no luck. May need to order a new one.

Does anyone happen to know where the ESP32 firmware is?

[Pete9008]

Is it definitely an esp32, thought the VCU used the esp8266?

Edit - BTW I believe there is also a python updater that allows UART programming directly from the PC using a USB to ttl serial lead. Bypasses the esp completely so could also be worth a try?

[DerekSavage]

You're right, it is an ESP8266.

As for the python updater, is there any documentation on how to do that? I can figure out the wiring but is the updater something I can do in terminal?

[DerekSavage]

I connected the STLink and uploaded a file and the extra n was gone. I can't remember which one I uploaded whether it was from releases or not as I have so many of them they are all kind of mixed up. I went to my desktop and uploaded a file via UART that had previously been giving the extra n to see if it would stop. The letter remained. I went back to the stlink to upload the same file to see if there would be a difference, and now the activity light isn't on anymore and regardless of what files I feed it, I can't get it back on. I feel pretty defeated, any effort spent seems to be a step backward.

[royhen99]

Try reloading the bootloader via stlink. If the bootloader is corrupted the main application will not run.

[AdrianB]

I feel pretty defeated, any effort spent seems to be a step backward.

Yes, I think many of us have felt like that at times. It can seem overwhelming but if you take it step by step and test each step as you go you’ll get there. After reloading the bootloader as royhen99 says take a few minutes to tidy up all the files so you know what’s what - or, as I did, delete the mess I’d made and download fresh ones. Good luck.

[Pete9008]

Agree with ArdianB, I've been doing this kind of stuff for years and still found the OI stuff a fairly steep learning curve.

When using stlink you can either use a .hex or the .bin file. If you use the .bin you have to manually specify the load address, otherwise it could be programmed into the wrong area of memory (very easy to over write the bootloader this way). Best to use the .hex file with stlink as that contains the load address so the code always goes into the right place in the chip's memory.

If you haven't already found it the bootloader is here https://github.com/jsphuebner/tumanako- ... bootloader. This repository also contains the python script (updater.py), I've not used it but it looks like it just needs two arguments, the port and filename, so to run in terminal it should just be 'python3 updater.py -f <filename.bin> -d <port>' (note the bootloader needs the .bin file but already knows the right address to write it to)

Using stlink to program the bootloader .hex file and then the main code .hex file should get the activity led flashing again. You can then load the different main program .hex files with stlink to see if the letter appears and disappears as expected. If it does then move on to the ESP.

There seems to be two repositories for the ESP8266 code, one in Damien's github https://github.com/damienmaguire/ESP8266-WiFi-Interface and one in Johannes' https://github.com/jsphuebner/esp8266-web-interface. Not too sure what the difference is or which is best for the VCU? I've successfully used Johannes' with the OI inverter board so would suggest that one. You can program the ESP using either the Arduino or PlatformIO, IDEs use whichever one you are more familiar with.

With the ESP there is a known problem (there is a thread about it somewhere) where each upload file is copied to the ESP flash memory and then transfers it over the UART. The problem appears because the file isn't deleted from the file system when the UART transfer completes. If multiple filenames are used then the files slowly fill the file system until there is no space left at which point operation becomes iffy. Once you have fully erased and reloaded the ESP code the trick seems to be to always use the exact same filename for every upload so that the last file is overwritten. With that approach you can upload multiple times without problems. Really need to update the ESP code so that it deletes the file each time but as far as I know it has never made it to the top of the list.

[royhen99]

https://github.com/jsphuebner/esp8266-web-interface is best place for ESP8266 code, Damien's appears to be specific to the GS450_VCU and only displays some battery parameters. One thing to note if updating the ESP code is that zombieverter ( and sine_vcu ) use 2 stop bits on the 115200 speed serial bus. The code in the repository only has one stop bit so needs modifying. This caught me out when fisrt programming wifi modules.