Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flashing 2 Port STM32 ARM Based CAN Bridge Using Linux #38

Open
riceke opened this issue Jul 1, 2024 · 6 comments
Open

Flashing 2 Port STM32 ARM Based CAN Bridge Using Linux #38

riceke opened this issue Jul 1, 2024 · 6 comments

Comments

@riceke
Copy link

riceke commented Jul 1, 2024

Hello Dala!

First, I just wanted to thank you for all the fantastic work you have been doing with the CAN bridge software! It made it possible for me to upgrade my 2012 LEAF with a 40kWh battery instead of having to retire it and buy a new car.

I know that this is not really an issue per se (as you clearly state that Windows is needed for flashing), but I do not use Windows (the person that helped me with the upgrade does though) and I wanted to try and see if I can flash a new version of the firmware using STLINK and/or STM32CubeProgrammer under Linux.

I have the ST Link V2 USB device connected to the JTAG interface on the STM32F105/F107 based 18 in 1 CAN filter board and I have been able to flash the contents of the 'canbridge.srec' file onto the board and also verified the flash contents against the file.

But, when I replace the same type board, currently in my LEAF, with my newly flashed board it does not work (a lot of CAN bus errors and so forth). Putting back the Windows programmed board makes everything work again.

I am investigating, to start with, that the CPU on my board really executes the code in flash (i.e. starting at 0x08000000) and that it is not instead just executing an initial bootloader (may need setting of some option bytes), but I am also wondering if there is something additional missing that is done by the "magic" 'BridgeFlasher.exe'.

Is there any source available for the 'BridgeFlasher.exe'? I have seen some screen dumps where it says that it successfully patched the 'canbridge.srec' file before flashing it. Exactly what needs patching in the 'canbridge.srec' file and why?

Any other ideas that could point me in a working direction?

Thank you very much for your attention and have a nice day!

@dalathegreat
Copy link
Owner

Hi @riceke , I switched to linux also a few weeks back, so we will have to get this working :)

Originally when development started, we were still on closed source, and a bit worried about the source code leaking. The original toolchain did some magic with the bits as a copyright protection method. This was not developed by me, it was one of my kind Patreons who set the entire thing up. I will ask them if we could reverse the need for this somehow, I am not so familiar with the STM32 platform to do it myself 😅

I will let you know shortly!

@riceke
Copy link
Author

riceke commented Jul 2, 2024

Hello Dala!

Thank you for your prompt reply!

I figured out that the unused pin (or hole) on the JTAG connector is actually the STM32 BOOT0 pin and wiring it to GND makes the CPU boot from flash (at least while I am debugging via the JTAG interface), so I am one step closer, I think.

I will try to test in my LEAF as soon as possible and let you know if it makes any difference.

Thanks!

@dalathegreat
Copy link
Owner

@riceke
Try dropping in this main file and try compiling it, Glen posted it. No testing done yet, but should do the trick!
main.zip

@riceke
Copy link
Author

riceke commented Jul 7, 2024

Hello Dala!

I don't have a STM32 toolchain up and running on my linux system yet, so I am not yet able to build from source.

But I did realize that the call to the 'strncmp()' function in 'main.c' (this function call has been removed from the 'main()' function in the 'main.zip' file) was a check comparing the UUID of the CPU against a 12 byte string in the 'au8_lock' character array, so I guessed that the patching of the 'canbridge.srec' file was to locate and replace the 12 bytes of that array with the UUID bytes of the CPU on the board that you would be flashing.

So, I located the UUID bytes of my board (at address 0x1FFFF7E8) and created a 12 byte 'srec' file and used it to patch 'canbridge.srec', using the 'srec_cat' command from the 'SRecord' package (srecord.sourceforge.net).

I then flashed my board with the patched file and put it in my LEAF and, voila, it was all working!

When I have some more time I will try to set up the STM32 toolchain in order to be able to compile and build from source and I will let you know how that goes.

Thanks a lot for all the help!

@ilataniuk
Copy link

Hi folks, there aren't any "magic" here. For correct flashing by STM32CudeProgrammer on MacOS,Linux etc...
just comment this line:

@riceke
Copy link
Author

riceke commented Jul 14, 2024

Hello @ilataniuk!

Yes, I realized that there was no actual "magic" (hence the double-quotes ;-)), but making the change to the 'main()' function requires me to then be able to build from source, which I am not yet able to do (will try to get an STM32 toolchain up on my Gentoo system when I have some time).

So, I instead patched the already built 'srec' file in order to quickly get something up and running.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants