Lexus GS450H VCU V3 STM32 Software Development

[celeron55]

Why not use the good old stm32f103 for this also, if it's possible?

[jon volk]

Why not use the good old stm32f103 for this also, if it's possible?

I’m going to assume for 2 can busses. That’s what led me to the same micro for a current build I have en route from JLC.

[Dilbert]

Some more testing done here this morning. Using my non-optimised code it takes 2mS to pack 80 bytes of data and about 4mS to unpack, but we can speed up the CPU and optimise the code so not too worried about that. I did a loop-back test and I can decode the data fine, so what i'm seeing coming back in on the loopback is identical to what I'm getting on the Arduino lenonardo.

I'm using the 80 byte HTM setup frame for testing here, the complete transaction (pack - send - receive - unpack) is taking 10mS, which should be fine.

Given the tests above seem to look good, i'm going to connect on the physical layer, from my Leonardo logger i have 4 CAN Transceivers on some vero board so these will be jumpered over onto the STM32. If these look good on the scope I can plug the RJ45 into my GS450H harness and test the comms

[Dilbert]

I believe I'm able to correctly do one data transfer from the GS450 inverter, the MTH checksum is correct and the data length looks good too. My only problem is the "second transfer" i do is shifted by one bit and i'm not sure why. It is like there's 1 additional clock pulse or a pulse missing, so the next transfer is out of sync.

I've tried all 4 SPI settings, so will need to figure out why this is happening, none the less, it is encouraging even to get one good transfer from the unit. Once I'm able to read the data i can experiment with sending data.

[Dilbert]

Interestingly enough, if i re-init the SPI before each transfer it works fine. So either the re-init is clearing something in the SPI or the clock line is going low/high and sorting out the clock issue.

[steveknox]

I can't help out much here technically, as my expertise lays more in web development, but I can provide encouragement and thanks. I've even got an STM32 ordered to do some testing with, as I'm very keen to keep up-to-date on the gs450h developments, and to learn something new. So thanks and keep going.

On a web-development note, will the new chip require changes to the web interface code?

[Jack Bauer]

I've spent the day hacking about with Johannes's STM32CAR project :
https://github.com/jsphuebner/stm32-car

My plan here is to use this as the skeleton for the new vcu. It will reuse the openinverter wifi webinterface and have modules for running Toyota (Lexus) and Nissan Leaf inverters. Using the existing web interface will allow for things like throttle calibration, precharge voltage etc to be all done over the web.

[Dilbert]

I just tried the DMA there to/from the SPI and it does work, but I'm having slight data alignment issues, i think it is related to how/when i'm toggling the request line....

[Dilbert]

The SPI approach does work, but it is a little bit tricky. Normally a USART will idle till it sees the start bit coming in, whereas with the SPI approach we are almost telling it where to put the start bit. We could search for the start bit at the start of the array, but this seems messy and overly complex.

The re-init of the SPI works, as it seems to give an additional edge, so it looks like the inverter can set up its' first bit based on this. It is a bit strange as normally the bits seem to be set up based on the rising edge of the clock and clocked on the falling. So i'm not sure why the normal first rising edge of the clock isn't setting up the start bit for the start of the frame from the inverter.

[Dilbert]

Does anyone have information regarding how continuous the clock signal needs to be for this interface? I know the ATMEL device puts out a continuous transfer clock and Toyota does also.

[windydrew]

I'm interested in helping financially to get the gs450h controller software developed. I have a v2 board ordered that I'd like to use in the meantime.

[Jack Bauer]

No idea on the clocking I'm afraid. All I could do is test it out. Working away on adapting STM32-CAR to be the wrapper for both GS450h and nissan leaf versions. Binaries and hardware will be the same and it will just be a menu option on the web interface to choose which you are using. This is bringing in a lot of the niceities from openinverter like throttle cal, derate, graphing etc. Leaf can messaging is now working on the bench as of today.

[Dilbert]

No idea on the clocking I'm afraid. All I could do is test it out. Working away on adapting STM32-CAR to be the wrapper for both GS450h and nissan leaf versions. Binaries and hardware will be the same and it will just be a menu option on the web interface to choose which you are using. This is bringing in a lot of the niceities from openinverter like throttle cal, derate, graphing etc. Leaf can messaging is now working on the bench as of today.

That would be really nice, I haven't looked at STM32-CAR yet too much. Ok you could select which manufacture/model your conversion is going into and it would configure/enable suitable CAN messages for that vehicle. The on the controller side you can select which inverter will be powering the vehicle.

What i was considering is (it might already exist) if we could take DBC files and somehow generate a CAN configuration (possibly stored in JSON) which would then be used to configure the messages used by the controller. As we might not want to use/map every message in the DBC file. So we could have DBC files for lots of different vehicles and these could be downloaded from here, processed and the CAN config pushed up to the VCU or any of the inverter boards (prius gen 2, 3 etc...)

[Dilbert]

I'm interested in helping financially to get the gs450h controller software developed. I have a v2 board ordered that I'd like to use in the meantime.

There actually isn't too much in the firmware once we can figure out the coms part. If we integrate with the STM32-CAR project that should handle throttle, direction etc... but yea i'll send on the bank details

[Jack Bauer]

Yep I think it will expand nicely. Just a stupid thought here but have we just tried it with the stm32 usart?

[Dilbert]

Yep I think it will expand nicely. Just a stupid thought here but have we just tried it with the stm32 usart?

Good question, i have code written for it and tried it on the scope before I had the inverter here beside me. I parked the idea when i couldn't see a clock signal during the start/stop bits. But i haven't fully given up on the idea of using the standard USART.

I was actually giving this some thought last night and there's a couple of things worth investigating:-

1) Standard Sync UART configuration (unlikely to work due to no clocking of start/stop bits).
2) Sync UART configuration, but generate a transfer clock by some other means (pulse generation with timer) or even a second USART running at twice the baud and broadcast out 0x5555
3) Sync UART in 9 bit mode, could we make use of the extra bit, which woudl be clocked
4) Sync UART and generate a fully independent clock (problems with syncing with the TX clock)
5) Async UART, generate the clock independently


I think we can get the transmit to work with a few of the above methods, i'm more worried about getting the receive to work reliably.

[Dilbert]

The other challenge with using the STM32 USART in SYNC mode (if I understand it correctly), is that the clocking in of the RX data is dependent on TX'ing at exactly the correct time in the correct window. As the RX in the receiver is driven by the TX clock, this is quite different to the ATMEL Sync USART.

[xp677]

Does anyone have information regarding how continuous the clock signal needs to be for this interface? I know the ATMEL device puts out a continuous transfer clock and Toyota does also.

From experience, you need to clock the data in and out of the inverter's MCU, but for the period in-between, you may be fine. The inverter needs initialising on start-up, I don't know if it would fall back to it's init state if the clock were to drop out, from my testing I've not seen that happen.

Starting and stopping the clock may be acceptable. My experience is with the Atmel chips, not STM32, so I can't be of much help.

[Jack Bauer]

Another probably silly idea. Loop the tx and rx into gpio inputs and use an interrupt to fire the clock? Probably take too long though ..

[Dilbert]

Another probably silly idea. Loop the tx and rx into gpio inputs and use an interrupt to fire the clock? Probably take too long though ..

That's an interesting idea, so maybe use the start bit (low) from the tx line into some sort of timer. I'll put it on the list if things to try.

We need a rising clock edge for the inverter rx to setup the data and and it's held till the next rising edge of the clock.

Next thing I will try is I'm going to try generate a pseudo clock and see if it can keep in phase with the sync tx clock.

[Dilbert]

Does anyone have information regarding how continuous the clock signal needs to be for this interface? I know the ATMEL device puts out a continuous transfer clock and Toyota does also.

From experience, you need to clock the data in and out of the inverter's MCU, but for the period in-between, you may be fine. The inverter needs initialising on start-up, I don't know if it would fall back to it's init state if the clock were to drop out, from my testing I've not seen that happen.

Starting and stopping the clock may be acceptable. My experience is with the Atmel chips, not STM32, so I can't be of much help.

Yea it seems like atmel used exactly the same design for usart on the smaller mega processors, I was able to use the little leonardo for the communication also.

[Jack Bauer]

Arrgghh silly ST. Will have a stern word with them:)

On the wrapper front (am now calling this the ZombieVerter and will start a fresh thread on the topic) have Leaf CAN module working on the bench. Will test in the E46 touring hopefully next week. Throttle, contactor control and ISA shunt also working on the bench. Must say I'm finding libopencm3 very intuitive.

[Dilbert]

OK So done some testing with the USART running in async mode and a pseudo clock and it appears to work fine, which is great news. I can get back the mth_data and verify the checksums. I'm not sure if my pseudo clock needs to be in step with the rx clock for the USART, but overall it seems happy enough. I'm running a longer term test and counting errors now.

So this is good news really. Rule 1 don't over complicate things!

[Jack Bauer]

Excellent news:)

[Dilbert]

We've no idea how this will handle switching noise etc, but the Async USART should be quite good with its 16x over sampling etc....

The only other issue i can see is that the TX will fall out of sync with the pseudo clock, they appear to be locked together, from what i can tell at the start of the frame, but i can't see if there's drift near the end of the frame (possibly isn't as i would probably see it).

Based on this i'm going to port over the existing v3 firmware onto my system here and see if i can spin up the motor. The way i have the Tx/Rx done at the moment it's pretty much all interrupt driven anyway.