Lexus GS450H VCU V3 STM32 Software Development

[bobbyj_408]

Makes sense!

Great, so it looks like we can narrow this down using those three sets of requirements (of course this is only my opinion, Damien is the decision maker as far as I'm concerned): 1) availability on JLCPCB, 2) the communication specs that mdrobank mentioned, and 3) nucleo support for ease of prototyping.

A very very quick look at MCUs, and I got:
STM32F446RE - easy to use, but, as mentioned, not available on JLCPCB
STM32F207ZG - available on JLCPCB, has nucleo support, and has the needed communication channels.

[Jack Bauer]

Sorry If I wasn't clear on this. The hardware design is done and boards currently under manufacture at JLCPCB. STM32F105 dev boards are readily and cheaply available from Aliexpress and I have undertaken to supply 3 full kits to those working on the development.

[bobbyj_408]

Sorry If I wasn't clear on this. The hardware design is done and boards currently under manufacture at JLCPCB. STM32F105 dev boards are readily and cheaply available from Aliexpress and I have undertaken to supply 3 full kits to those working on the development.

Sorry if I derailed the conversation there. Looking forward to what comes out of this.

[Jack Bauer]

No apology needed. I'm pleased to see so many people participating:)

[james@N52E01]

I’m not a coder, but can at least load updates to the boards via STLink, plus I have multiple Olimex boards to reflash should updates be needed to the ESP8266 code as well. If option 1 is used, I could coordinate hardware testing with access to 2 GS450H setups and 2 Leaf setups (one gen 1 and one gen 2).

If option 2 then I would be happy to step up and coordinate the funding campaign.

Although a beginner, I have been working in collaboration with several forum members for over a year now and we’ve always had good results and feed all of our work back to the community

[clanger9]

I'm in the same position as James. I'm not a coder, but will definitely be able to contribute in future once I'm up to speed with the necessary skills. Option #1 is preferred for me, but if we have to drop to option #2 then I will happily chip in with some funding...

[Dilbert]

Yes good to see so many people interested. I've started working on doing a quick demo using the F103 board i have here on my desk. I will use cubemx, to allow me quickly configure the processor.

The first thing I want to do is make sure we can send the sync clock signal continuously @ 500KHz, i have a plan for this. The next thing i want to do is see if i can do something to disable the TX pin, but still allow the sync clock to be produced. Then I can look at sending and receiving data with the correct timing.

[james@N52E01]

May be too late but could this be used as an opportunity to unify the hardware designs for the 450H and Leaf VCU’s?

[Jack Bauer]

Many thanks for this guys. Last thing I want is option 3. If I could do this myself or afford to fund it I would. Not too late at all re Leaf / 450H. I already allowed for that:) Just needs software.

Dilbert, Shall I put you down for a free kit?

[Dilbert]

Many thanks for this guys. Last thing I want is option 3. If I could do this myself or afford to fund it I would. Not too late at all re Leaf / 450H. I already allowed for that:) Just needs software.

Dilbert, Shall I put you down for a free kit?

Yes you might as well. I spent a bit of time afternoon with the F103 board and seeing if I can output a consistent stream of sync serial data using interrupts. I just want to prove that the STM32 USART can do what we need in Sync Mode, before getting too far along the path.

One of the concepts i'm trying is firing an interrupt for every byte which is transmitted, so at 500Kbits / second, it would be 50K ints / second. As the timing on these should be fixed, every 20uS we could use this as the time base for the transfer and do things like to toggle the sync signal line to the inverter etc..

[Dilbert]

The first gotcha appears to be this in the datasheet:-
The CK pin is the output of the USART transmitter clock. No clock pulses are sent to the CK pin during the start bit and stop bit.

The toyota protocol does get clocked during the start and stop bits, so the STM32 will stop the TX clock during these and i'm setting this on the scope.

[mdrobnak]

So that sounds like without additional hardware the STM32 is a no-go?

[Dilbert]

I wouldn't give up on it yet, but yes will need some thinking outside the box.

[mdrobnak]

Is the datastream used a standard style, or something developed in-house?

[Dilbert]

It's standard enough 8-n-1 with a synchronous clock. Different vendors implement the sync clock differently, doesn't seem like there's too many options on the stm.

[mdrobnak]

Hmm. So is this RS-422 or SPI?

[mdrobnak]

https://visualgdb.com/tutorials/arm/stm32/spi/ If SPI, does that help?

[Dilbert]

Not SPI as it has start and stop bits, so the spi interface won't really work.

[xp677]

The first gotcha appears to be this in the datasheet:-
The CK pin is the output of the USART transmitter clock. No clock pulses are sent to the CK pin during the start bit and stop bit.

The toyota protocol does get clocked during the start and stop bits, so the STM32 will stop the TX clock during these and i'm setting this on the scope.

Yes, Toyota clock is continuous. The MTH is clocked out as well by the master, what does the STM do with the clock when not transmitting? Does it just transmit a constant clock?

MTHJ is triggered through the REQ pin, so can be triggered at any time, it doesn't have to align with a transmission. As far as I know, there isn't a requirement for the complete transactions to occur within Toyotas 4ms window, you can likely have separate periods for Rx and Tx.

The lack of clock during start and stop bits is an issue, as the inverter will look for 10 clock pulses per byte. There may be a way round this by having the STM output 8 bits with no start or stop bit, and then bit bang those in between. But this would prevent you from taking advantage of the serial buffer, and at this point you might as well bit bang everything.

In my early days of this development, I bit banged the clock and the HTM data. It wasn't pretty, but on the scope it looked the same as the Toyota stream.

Looking at this, it's not looking promising.

https://community.st.com/s/question/0D5 ... sart-clock

Looks like it does the same thing with SPI?

[Dilbert]

Yep the stm32 sync uart stops the clock outside of the normal data transfer window. We could run it in 9 bit mode, but we would still be a bit short.

I have considered using an Stm32 hardware timer to create a pseudo transfer clock alligned with each byte, which might work.

My current plan is to try use the spi, except pre process the tx data array and add the start and stop bits. This will be a quick operation and the array will grow by 20%. The reverse operation would be required on the rx data, but we could scan the rx array for the valid start and stop bits, so we'd know we have sync'd correctly with the stream. I'm currently coding this up. There are many advantages to this, if we put FF into the tx buffer we can clock back the mth data. The icing on the cake is if I can get this to work we could fire it out/in using dma so no real overhead. Also spi will allow different clock configs.

Your information is useful about tx and rx not needing to be alligned, I guess we will see what happens if the clock does stop between transfers. Again with spi I can just dma out lots of FF 's thus would keep the clock running

[Dilbert]

This is the kinda thing I'm looking at, which should enable the SPI to clock it out. First line is the input data(FF,FF,FF,FF) second line is how we need to send over the SPI:-

11111111 11111111 1111111 11111111 10000000 0000000
01111111 11011111 1111011 11111110 11111111 1000000

I've written up some code which i will test tomorrow. I'm sure i will probably have an LSB/MSB issue, but this should be easy enough to correct, also the SPI bus you can configure as LSB/MSB. From memory, the standard UART is LSB first, so i'll aim for this with my test data.

Also when i was doing some work on the Auris Hybrid, I made up a little decoder on an arduino Leonardo, so I should be able to connect that to my board and recover the bytes being sent (in theory)

[Dilbert]

Very good news, it looks like SPI can be used to send sync serial data!

I'm sending out the following values, via SPI (with start and stop bits stuffed) 1,2,4,8,16,32,64,128 hence the 8 bytes are being sent as 10 on SPI

On my leonardo, which previously was able to decode my auris hybrid data, i'm getting the following in 2 2 4 8 16 32 64 128.

I haven't modified the code in the leonardo, so this is very encouraging news, clearly, there's some issue with the first byte but I should be able to figure out what's happening there!

I haven't looked at the STM32F105 processor too much yet, so the hardware that comes in might need a small mod, 3 fly wires to bring the SPI port over. It also means we can use any STM32 (or other processor) for the Toyota serial protocol if we use this trick.

[Dilbert]

It looks like that issue with the "2" being received first is just on the first byte, every other packet is coming in fine. This is encouraging, i might do a "loop" back test on my unit here and see if i can correctly decode my own data and if the start/stop bits are in the correct locations.

[steveknox]

Brilliant work, Dilbert. Fair play.

[Jack Bauer]

Excellent Dilbert. No problem bodging a few wires and once up and running I can do a mod for the next run.