Lexus GS450H VCU V3 STM32 Software Development

[Jack Bauer]

Recently while ordering some VCUs based on the SAM3X8E (Arduino due microcontroller) , JLCPCB informed me they do not intend to restock on this device for at least 6 to 12 months. This has forced me to order boards without the micro fitted and then fit myself in order to fullfill orders. Obviously this is labor and time intensive and not sustainable for any length of time. So, to combat this I have taken the step to begin migrating all SAM3 based VCU kits to the STM32 platform. In the case of the Lexus VCU this will be the STM32F105RB connectivity line device. As the SAM3 code is not compatible with the STM part this requires a code migration as well as hardware. The hardware is now done and prototypes ordered just leaving the software. Sadly I am not in a position to perform this task and so I am proposing the following possibile solutions to the community :

1)The Openinverter community take on the task and migrate the code. To support this I will provide (up to a maximum of 3) complete V3 kits free of charge to those doing the primary work. Such kits will only be provided if the person or persons involved have a track record in opensource software development and / or are contributing here on the forum. I will also assist in testing code in the E65. Should this option be chosen then both hardware and software will be fully opensource AND I will be in a position to reduce the cost of the kits in the future. A hard deadline MUST be agreed by all parties for this option to proceed.

2) I have sought out several quotations from freelance developers for the task. The best of which is priced at $800USD in a 10 day timeframe. The Openinverter community could chose to fund this cost in whatever manner (e.g. crowd funding) and forward the money to me. At which time I will engage the developer, manage the process, verify the code in the E65 and release noth hardware and software as opensource. Kit prices will remain the same in this case as it will require further input from me. Note I will not manage the crowdfunding and will only deal with one apointed member.

3) My least favorite option is where I fund the developer, manage the process and verify correct operation of the vcu in E65. If this is the choosen path then only PDF schematics, gerbers and binaries will be released. Sources will be available via patreon only and no kit price reductions will take place. This is similar to where the V5 Tesla Gen 2 charger board ended up going.

I'm placing a deadline for a decision on this topic at 2 weeks from today (23/12/20). Should there be no consensus by then option 3 will be the default. We have over 1000 members here folks. Lot of talented people. Let's try and prove opensource driven development can work:)
https://github.com/damienmaguire/Lexus- ... 3/HARDWARE

[Bigpie]

I'm happy to try and help out, but I'm far from an expert.

https://github.com/stm32duino/Arduino_C ... ted-boards
The Arduino stm32core doesn't list support for the STM32F105, unless I'm mistaken.

I'm guessing the software from CAN-BUS-Man-In-The-Middle would be a good starting point?

I'll have a poke around and see if it's something I might be able to pull off.

EDIT

Assuming the STM32F105 is actually supported under stm32core.

I'm thinking the steps need to be:

• choose a compatible CAN library to replace due_can. (I'm looking at eXoCan and it seems to fit the bill)

• port SimpleISA library to use the above library.

• port main code to use the above library.

Due_timer, Due_wire & Wire_EEPROM appear not to be used.

[Bigpie]

I've started having a stab at it here:

https://github.com/jamiejones85/Lexus-G ... h_STM32_v1

So far I'm using eXoCan library, there doesn't seem a lot to it, but I may be missing something obvious and wasting my time.

I'm terrible at registers so need to work out/read up what the below is doing

Code: Select all

PIOA->PIO_ABSR |= 1<<17;
PIOA->PIO_PDR |= 1<<17;
USART0->US_MR |= 1<<4 | 1<<8 | 1<<18;

I've decided to still use can_common.h for the CAN_FRAME structure defined in there and just then translate to and from as needed to send the eXoCan library.

[Gigas]

I wish I could help but coding is like magic to me and I'm just now starting to learn it- what does this mean for the current boards? I was going to place an order today for one?

[Jack Bauer]

There is no impact on V2 boards as I stated above I am ordering them without the micro fitted and then fitting it myself. This is not something I can continue for much longer.

[mdrobnak]

The biggest issues are the serial comms / CAN pieces, right?
F103 vs F105 is a difference of peripherals on-board - in this case CAN and Ethernet. I've found Arduino can be difficult to get going is my only concern. The CAN driver is definitely different between Teensy and STM32 for instance, but now having more experience with it in Rust perhaps this time around it won't be that hard. The serial data would be new to me.

Overall this doesn't look like too large of a project - what kind of timeframe would be considered to be reasonable?

-Matt

[Bigpie]

I could be very wrong, but it seems there's not a lot to it. I've updated repo above, got a bit more to do on can receive but it should be sending ok as best I can tell, if someone which the hardware and knows more then me wants to take a look.

[mdrobnak]

I'm terrible at registers so need to work out/read up what the below is doing

Code: Select all

PIOA->PIO_ABSR |= 1<<17;
PIOA->PIO_PDR |= 1<<17;
USART0->US_MR |= 1<<4 | 1<<8 | 1<<18;

You'd have to look at the original datasheet to see what setting bit 17 in the PIO ABSR/PDR registers did, and setting three bits in the USART0 US_MR register. But that's all that's doing, it's hardware specific. Is this still on the SAM3X?

-Matt

[Dilbert]

I guess the question is do we want to use the sine-firmware (scheduler / CAN buffers / parameters / throttle etc.. ) as the basis for this new V3 ECU? or port over the SAM based firmware to the new hardware.

I worked on firmware to send the synchronous serial from an STM32 about a year back, I had a small application based on cubeMx which I was using to try send some sync serial data. I got something working, but i don't think it was 100%. I would need to look at bringing it to the F105 CPU also.

I wouldn't mind working on this project from a software point of view, I also have a GS450h inverter / motor to test on.

[mdrobnak]

From my short look, the sine firmware code is a bit more complex. This code will definitely need modification if you're using it in a CAN-enabled vehicle, thus the easier the setup for modifications, the better. I think Arduino isn't a bad idea here, if it can be done. It shouldn't be too hard to get this going especially if done collaboratively.

-Matt

[Dilbert]

From my short look, the sine firmware code is a bit more complex. This code will definitely need modification if you're using it in a CAN-enabled vehicle, thus the easier the setup for modifications, the better. I think Arduino isn't a bad idea here, if it can be done. It shouldn't be too hard to get this going especially if done collaboratively.

-Matt

I think if the sine-wave / foc part of the firmware was removed, it would actually be quite straight forward. It already will have much of the vehicle logic built-in. So instead of running the sinewave generation / FOC, we need to send the syncronous serial messages.


Does anyone know of a STM32F105RBT6 development board that could be used?

[james@N52E01]

Does anyone know of a STM32F105RBT6 development board that could be used?

Would this work?

https://github.com/mackelec/STM32F105_D ... CAN_2s.png

Edit: Ignore, see post below

[Jack Bauer]

As I mentioned in the original post if we agree on community development I will provide up to 3 full kits totally free of charge to the developers. Boards expected in about 10 days. After that I would like to see code in a 2 week window. Obviously not to finished standard but progress being made. My personal preference would be libopencm3 but that's up to the coders:)

[clanger9]

Option 1 would be the best outcome for all. Unfortunately I can't do anything in that time window.

[mdrobnak]

Well, libopencm3 has enough examples that the 'hard parts' look like should be pretty easily workable from them. I can give it a shot.

-Matt

[Bigpie]

I can try give you a hand if there's anything I can help with, though I'd guess you're more than capable.

I've.been making changes to stm32-car for my ecu replacement, so have a little familiarity with libopencm3

[Dilbert]

I’ll dig out my stm32 code later in the week for the sync serial and see about getting that running again on one of my boards. I didn’t have an inverter at the time so wasn’t able to test it.

If I can get it running I’d be happy to work posting one the SAM firmware.

I had a look at some notes from the time, the way the sync serial port works on the stm32, it is not possible to receive information without transmitting, as the clock pin is driven by the Tx of data. So I counsidered being able to turn off (disable) the htm Tx can driver, so this data doesn’t leave the ecu.

[Isaac96]

Subscribing to watch this thread -- looks like we've got developers on it. I have no experience with direct STM32, so good luck to you all!

[xp677]

I've moved on from the SAM3X8E to the SAMD21 series on my more recent projects. The 3X8E is apparently nearing end of life.

The SAMD21 is stocked at JLCPCB, it's cheaper and smaller, but doesn't have onboard CAN. Porting the VCU code over should be simple, it would just need the register settings updating, pin definitions changing, and an external CAN controller adding.

Might be worth looking at if the code doesn't work on the STM32.

[MattsAwesomeStuff]

I'm probably never going to use a 450H, nor do I have the skills to contribute.

I just wanted to say thanks for everyone who considered helping, and especially those who are going to put in the work.

All I can do is encourage people to use this solution when it's done, so that a larger number of people benefit from the effort.

Fun anecdote: Last week I got into a short argument in an advice thread with someone professing how hybrid parts aren't "real" EV motors and they're "garbage no one wants", and you gotta pay $2000 for a "real" EV motor and no one's going to use junky sad hybrid parts. I think the instigator sells EV services (not overtly) and has vested interest (or vested inventory) in making this seem hard and how you have to use the components he gets people to pay for. Anyway, I threw down some numbers for both cost and performance, twice, and seem to have kind of shut him up for the time being.

[sfk]

They may not be High Performance parts compared to a Tesla LDU since they are only intended to assist the ICE drivetrain but certainly are great value for money and suitable for general utility.

[Jack Bauer]

I'll advice once hardware arrives. At that point a decision needs to be taken on what option is being adopted. Thanks everyone who has responded.

[steveknox]

As with other posters, I have no experience in STM32, so my input would be limited, but I'm glad to see there is some interest in picking this project up and keeping it open source. I have motors and inverters for testing if that's in any way useful.

[bobbyj_408]

Sounds pretty fun! I've used an STM32 in the past for a personal project, and there are loads of open libraries that can be used. A big fan of the mbed build platform, which could actually be used with the online browser compiler for free.

Taking a step back, what are the functional requirements of the micro controller? xp677 pointed out that another STM32 models could serve as a better platform to develop on. May I suggest something that has an available development board associated with it? For example, something that has an associated nucleo development board (roughly $30) so that anyone could easily help with the software.

Nucleo Boards
https://www.st.com/en/evaluation-tools/ ... oards.html

[mdrobnak]

The issue is that the board doesn't necessarily translate to what JLCPCB has available - hence why we're not using the STM32F446RE (which I have the cheap Nucleo board for) in the Tesla Charge Port Controller board, but a slightly different variant which is cheaper but does basically the same thing.

You are right that the functional requirements should be defined.

So far GPIO, CAN, and SPI, debug/wifi USART are the items that I see.

-Matt