openinverter forum

Thank you, much appreciated.

I've done a bit more research too and it seems that the blower control module from an IS200 might also be suitable. Similar configuration but possibly better suited to the application and readily available. Going to continue to research the options and get something ordered.

Also occurred to me that I have a few cars here that probably have a suitable module fully wired up and working and so easy to test which I should have a look at too!

Edit - think I'm going to get a Lexus 87165-22050 blower motor control module for testing. Based on the prices they go for there doesn't seem to be much demand so I'm guessing they are reliable and they look pretty easy to use (very similar to the details bexander posted). Thinking about I'll need to do something on the radiator fan too, it's just switched by a relay so will run far to fast. Can't use the Lexus module as it's not waterproof so may use the Volvo/Ford one there.

Just ordered a Hyundai HSG starter alternator (see viewtopic.php?p=29225#p29225)

I've been wondering how to go about testing my new board. It's a new design of resolver interface running on a new processor with floating point rather than fixed point math so a fair few things that could (and probably will) go wrong. I really didn't fancy doing all the debug work out in the workshop (and having to drag all the test kit out there) but I also didn't fancy dragging the (fairly oily/mucky) Outlander motor into the office. The HSG looks like it will provide a great little motor for testing.

It has a built in resolver so can be used to test the resolver interface and then used for initial inverter and control loop tests. It's nice and compact and will hopefully run quite happily off a bench power supply for initial testing. At under £100 they are ridiculously cheap for what they are!

HSG has arrived, It's been rattling around in a fairly battered box without enough packing though so hope it still works

Coolant pipes have survived and the rotor turns OK but the idler pulley no longer looks aligned and part of the idler arm has broken off. Shouldn't affect my plans for now but the idler would have been useful if I ever get round to using it for anything else.

I still haven't assembled the board. Decided that I ought to improve my home ESD setup first (i.e. have one rather than just trying to remember to touch an earth point before picking things up - not recommended ). Ordered the mat and earth straps early last week and they finally turned up today. Hopefully get the board built up and an initial power up test done on it over the next few days.

Edit - tip regarding ESD while I think about it, to date I have never killed anything due to ESD build up (but I rarely seem to build up a static charge and am careful when handling electronics - at work it was always ESD mats, wrist straps, heel grounders and antistatic lab coats). I have however killed two things at home due to cheap bench equipment. A lab power supply which put 120V ripple onto the 0V line due to no inter-winding shield on the transformer and a de-soldering tool that didn't have an earth on the tip. When using any kit near sensitive IC's it's worth making sure that everything has a good earth even if it is kit designed for the job!

I also have a HSG. Had an idea of using it for my Clio but I think it is on the weak side and I have not found a suitable gear reduction for it either. It is a very compact motor for what it is supposed to deliver power wise.

Progress (well hopefully - if it all works!): Forgot how much of a pain hand assembly is! I've left all the difficult to replace bits off for now (mainly the Toyota connectors) until I know whether it works. Couple of slight problems, one diode on backward which stopped the -5V rail from working and there are a few components that I managed to miss when ordering but it generally looks OK.

Power supplies are coming up, resolver to digital converter IC is clocking and generating the resolver drive waveforms and I can talk to both processors with the debugger. I've tried putting the code on the STM32F407 processor and it programs OK and in the debugger it single steps through main and completes all the initialisation code but when allowed to free run it ends up in the blocking_handler interrupt so I'm guessing I've messed up an interrupt configuration somewhere. Hopefully spend some time on it in the evenings, get it all tested and if it's OK get the rest of the bits ordered and look at hooking it up to the inverter and HSG.

Looks good!
I see you have gone for the all in design with a lot of capabillities. I have started my own design for a Yaris logic board but with the bare minimum capabillity. Looks silly sparse compared to yours.

I thought this was fairly stripped out compared to the first design (viewtopic.php?p=39624#p39624)!

I've moved most the VCU related stuff out to a second unit. The contactor control bits are only there temporarily to allow the car to be used before the VCU is in.

What else are you cutting out of yours? Are you using Kicad for it?

Yes, using kicad. Removed everything I don't need. Using STM32 and stock design, so no fancy stuff like yours.
No input/outputs as it's done via CAN.
Removed MG1 current sensor.
Added DC/DC voltage control via NE555 timer.

That does look fairly sparse compared to mine! I was going to say do you need any parts/footprints but it looks like you're sorted.

What are you doing for power supplies, are those the switch mode supplies along the top for the current sensors? Are you fixing the DC/DC voltage level using the 555 or do you have any adjustment?

I've used a lot of CAD systems over the years, ranging from free to top end ones, and I can't believe just how good Kicad now is!

Edit - Your power supplies look a little light compared to mine, assume you are you only powering a single set of CTs? Are you going to add any extra protection devices on the power and I/O lines?

Power supplies,
Top left, PS40 is the 5V, high frequency buck
Top right, IC30 is 26V, high frequency boost
Right of 50pin connector, u34 is -5v, switched capacitor inverter
Top right of CPU, U57 is 3,3V, LDO
Right of WIFI module connector, U37 is 3,3V, LDO

NE555 creates fixed PWM frequency of ~20Hz and 51% duty cycle for a solid 14,0V output from the DC/DC. No adjustment other then HW change.

EDIT: 51% duty results in 13,8V DC/DC output.

Started testing the board, code is on and running and have a blinking LED and comms via RS485 (so the Tx/Rx direction switching and Tx DMA are playing nice which is good).

Going to be a fairly slow job as this is commissioning both the hardware and the ported OpenInverter firmware so going to keep track here of what has been tested and what is remaining to test:
Common

• Power supplies, +3V3, +5V, -5V, +26V - OK

Resolver

• Resolver oscillator and waveform output - OK
• Resolver, full interface - OK

F405

• Processor clocks, reset lines and debug interfaces - OK
• MG2 disable circuit - OK
• program download and run - OK
• firmware: digital IO - OK
• firmware: scheduler - OK
• firmware: terminal - OK
• RS485 interface - OK
• firmware: ErrorMessages, replacing RTC with TIM5 - OK
• firmware: CAN - OK
• firmware: PWMGeneration (main loop, resolver DMA, current sampling, desat handling) - OK
• firmware: Flash operations (ISP & parameter saving)
• CAN interfaces - OK
• Low side switch outputs - OK
• Analogue inputs - OK
• Digital inputs - OK
• Current sensor inputs & LP filters - OK
• PWM outputs & drivers - OK

F103

• Processor clocks, reset lines and debug interfaces - OK
• program download and run - OK
• Analogue inputs
• PWM outputs & drivers
• DC/DC control
• CAN interface
• Low side switch outputs

Edit - Worth noting that on the F405, if setting up a timer with a long reload, make sure that a timer update event is forced to make sure the shadow registers are loaded otherwise the timer and pre-divider will stay on the old values.

Pete, what was causing the blocking_handler error? Damien has the same error with F412 demo board and is asking what your fix was.

royhen99 wrote: ↑Sun Jan 22, 2023 2:20 pm Pete, what was causing the blocking_handler error? Damien has the same error with F412 demo board and is asking what your fix was.

I hadn't correctly set which USART the terminal was using so when it tried to initialise the configuration registers it wrote to an invalid memory address which caused the processor to hit the hard fault exception. It normally means you have tried to access a region of memory that isn't accessible. There's nothing the processor can do about it so it does the safest thing which is sit in a blocking loop forever.

Edit - Easiest way to find the cause is to look at the call stack (if your debug IDE can show it, in CodeBlocks it's under Debug, Debugging windows, Call stack) which will show you which function it occurred in and then single step through that function to see where it happens.

Flash is now working Couple of bugs, first I didn't realise that the SaveParameters function is locally overloaded and second I was trying to run with a non bootloader linker script but with bootloader flash memory address for the parameter storage. Couldn't understand why the parameters saved to flash fine, loaded from flash fine but then crashed randomly (or more often whenever anything was written to the terminal). Turned out I was overwriting part of the program flash with the parameters. No wonder it wasn't happy

Quick update, so far all the bits I've commissioned seem to be working fine!

The missing bits have now arrived so it should be possible to finish populating the board.

Only bug to date is a missing pull up on the RS485 Rx line which meant that it received a bogus character when transmitting (receiver disabled so Rx line dropped low). Enabling the IO line pull up on the processor has fixed it though (a hardware pull up would be better but this will do for now). I do need to figure out a way to use the continuous streaming commands though. RS485 is unidirectional so once the streaming starts there is no way to send a command to stop it; will have to add a pause every now and then.

The main control loop is running in around 15us (that's with the standard 5.24 fixed point code). If my memory serves the F103 runs in ~35us so the F405 looks to be about twice as fast which is about what you would expect. Next is to convert all the fixed point math to floating point and see what difference it makes. Hoping to get all the MTPA/MTPV calculations back into the main loop which is looking doable.

Have now got the resolver/ADC sampling, control loop execution and PWM reload working the way I wanted - an analyser screenshot: The top trace is showing the resolver sampling point which is coincident with the start of a burst of Il1 and Il2 ADC conversions (because of the way the interrupt I'm using to drive the IO line works the analyser is only seeing every other capture, there is another happening at around 44us). This is set to be exactly mid way between PWM reload events.

The middle trace is showing the execution of PwmGeneration::Run (main control loop), it is running when this line is low. The start of this is triggered by the completion of the last ADC conversion of the Il1/Il2 burst.

The bottom trace shows one channel of the PWM output. The reload value is set to the extreme so that it is a low pulse the middle of which is the reload point. There is another reload at around 73us that isn't visible on the trace.

What can be seen is that this is giving a latency from motor position and motor current measurement to the new PWM value that is based on these being output of 25us, down from 180us on the F103 processor - happy with that

It will be a bit slower than that in reality (as the PWM frequency for that test is set a bit high), 30us is more realistic.

So the missing components arrived today and have now been fitted. One of these was the op-amps for the Il1 and Il2 motor current measurement filters.

These are there because I'm a little worried about the low inductance of the Outlander motor (0.15mH) causing excessive ripple. The idea of the filter is to allow the commutation frequency components through while blocking the PWM frequency components. It should also block switching frequency components pretty well.

First problem, I didn't put pull down resistors on the filter inputs (becoming a bit of a theme!) which meant that the op-amp bias currents pulled the outputs up to full scale when the CTs isn't connected; luckily I had included some schottky protection diodes in the circuit so the processor ADC inputs survived. Also luckily there was a suitable ground pad next to the filter input so 100k pull-downs are now bodged on.

The measured filter response looks like this: The yellow line is the max commutation frequency for the Outlander motor (running up to 10krpm) while the orange line is the PWM ripple frequency (assuming PWM running at 8kHz). While it doesn't look too bad I'm not sure it is quite right, the filter cut-off was chosen when I was planning on running 4.4kHz PWM so it's a bit low now. I have also just measured the phase delay and at 100-150us it is enough to lose all the latency gains made moving to the stm32F4.

I'm now wondering what the best compromise is. I had planned to sample the resolver/current at the mid PWM timer reload point which would minimise the measure to output latency (30us) but doing that means that the ADC is sampling at points of the PWM waveforms where IGBT switching is occurring. If the sample point and a switch event coincide there will be lots of noise on the signal. Also, depending on PWM duty cycle, the motor current could be rising or falling so adding PWM frequency noise. Hence the filters, but if the filters add another 125us latency I'm up to 155us which is not much better than the 180us starting point (but hopefully with lower noise current samples).

It's possible that a better compromise is to sample at the reload point. Now this means that it will be 60us till the measurement has an effect on the PWM duty cycles but because it is guaranteed that there will not be a switching event you can get away with a much worse, and lower phase delay filter. Say I could get the phase delay down to nearer 40us that would give a total latency of nearer 100us. It also means that you are always measuring on the same point on the PWM ripple so there should be no beating effect. So the latency isn't as low as I'd like but the current sampling should be very clean.

Not sure what the best compromise is? It's either change the cut-off from 2kHz to 4kHz and stick with mid-point sampling or change it from 2kHz to 8kHz and go with reload point sampling. Both will be pretty similar in terms of total latency at ~100us but the later should give cleaner current signals so currently erring in that direction. Comments welcome!

Edit - think I'm going to move to sampling at the PWM reload point. The filter cutoff frequency will be lifted to ~12kHz (chosen because I already have the cap values needed!) which should drop the phase delay to around 20us while still giving a bit of attenuation to PWM frequency (~9dB) and good attenuation to switching noise (which will still help with data logging via the non synchronised sampling on the other ADC). Total latency will be around 80us. Not as good as I'd like but still a worthwhile improvement.

Edit2 - Re-measured the phase delay of the filter concentrating on the area below cutoff (the actual operating region) and it is worse than I thought - 190us. Looks like the cutoff frequency will need to increase by a factor of 10 (to 20kHz) to have a low enough delay so will definitely have to move to reload point sampling. The question at that point is it worth keeping at all? Do I bypass it completely (can be done by fitting zero ohm links) and save the power consumption and reduce component count or leave it in but set to a higher freq to remove any other noise that may be present?

Are you planning on running 8,8kHz switch frequency on the Toyota inverter? To my understanding thay prefer lower frequency with 5kHz stock.
Will it be happy at 8,8kHz?

bexander wrote: ↑Thu Jan 26, 2023 5:38 am Are you planning on running 8,8kHz switch frequency on the Toyota inverter? To my understanding thay prefer lower frequency with 5kHz stock.
Will it be happy at 8,8kHz?

Good question and the answer is I don't know but I'll try and explain my reasoning for wanting to do it (partly as explaining something is the best way I know of finding the flaws in it, partly because it allows others to pick holes in it and partly because it may be interesting/useful to someone?)

The driving force for this is the low Outlander motor inductance, Lq=300uH, Ld=160uH. Now using the following simulation run which ends just at the point throttle ramping has finished and the current has just hit maximum: Now taking numbers from this gives a controller voltage of 30V, power of 3kW and a motor voltage drop (not shown) of 30V.

The controller voltage of 30V is equivalent to a PWM duty cycle of 16%, this is equal to a total on time of 36us at 4.4kHz split into two equal 18us pulses (centre aligned PWM).

During this 18us pulse there is 360-30V-330V across the motor inductance so the current rise will be (i =Vt/L) = 37A, so during each pulse the motor current will increase by 37A. This current stores energy in the inductance, the current will then ramp down over the rest of the PWM period as the energy converted to mechanical energy by the motor. At the power level of 3kW the energy stored will comfortably last the whole period. So depending where we measure current in the PWM period, and where the PWM on periods are, we could see up to a 37A error/ripple in the measured current. This seems a bit on the high side to me as the control loop will always be trying to correct it which could lead to odd beating effects or non-linearities as the PWM switching points move.

To minimise this there are a few things that can be done. The first is try to filter the ripple. Next you can move the sampling to a point on the PWM waveform where it will always give an average current result. Lastly you can increase the PWM frequency. My first approach was to do the filtering but my measurements on the loop filter I added show it isn't going to work without adding too much measurement delay. So now I'm going to move the sampling point to the PWM reload point (which should give average current - it's always midpoint between the two on pulses) and try and move to 8kHz which should reduce the ripple by a factor of 2 to around 20A.

The final point is that the firmware measurement to output latency is limited by the PWM reload time. At 4.4kHz there is a reload every 114us, at 8kHz this can drop to 63us. The effect of this can be seen in the below.: The first is a simulation showing the high latency case (180us) and it can be seen that the control loops lose it at around 8400rpm. The second is the same settings but with lower latency (60us) showing that the loops are happy to above 9000rpm (they still lose it at 10125rpm though). I'm much keener on the second one! Worth noting that controlling the current on a low inductance motor is, in some ways, harder on the control loops (things change faster) so this problem may not be as bad on higher inductance motors.

So that's the why, what about the effect on the inverter? Now I've tried finding the justification for the 4.4KHz operation on the Prius inverter and all I can find is comments that it seemed happy at that frequency (and I'm not clear whether that is the Gen2 or Gen3). Now without more information (in what way was it unhappy at other frequencies, what motor was it running, what battery voltage, etc) this is fairly meaningless so I've decided to ignore it for now. So what facts are know - the inverter needs higher deadtimes and it normally runs at 5kHz. Now dead-times are suggestive of slower IGBTs but that is not necessarily the case, the driver turn on and turn off times contribute too. So would Toyota have used slower IGBT to improve some other characteristic, possibly, but even if they have the effect can be worked out - see viewtopic.php?p=50363#p50363. I'm fairly sure that even if the IGBT are significantly slower I can live with the effects. Once I have a working setup I'll measure them to see.

The other point is that Toyota seem to be isolated with their use of 5kHz, see viewtopic.php?p=50393#p50393, they are also unique in their use of higher inductance motors (with Ld of 1-2mH all the above issues disappear). The conclusion I have come to is that at 4.4kHz the inverter may be happy but I'm not convinced the motor or control loops will be. In the absence of any hard data from anyone who has tried the Prius Gen3 inverter on a low inductance motor at 8.8kHz I think it's got to be worth a try running at the higher frequency. I'm hoping that at 8kHz the inverter, motor and control loops will all be happy enough!

I think it is great that you push the envelope for what can be done with a Toyouta inverter. I'm curious to find out what improvments that can be done!
Higher frequency also tend to reduce switch noise to that would be an extra bonus.

One interesting data point about Toyota inverters is the weird sounds the GS450H inverter makes with its OEM control board and software. It sounds like it's varying the PWM according to the speed of the motor, or it's doing something else that sounds very different compared to what a Leaf OEM inverter sounds like (Leaf OEM doesn't sound like anything at all really.)

Another data point: I'm using a Prius gen 3 inverter as a charger at 10kHz. I picked that frequency because anything lower sounds absolutely deafening.

Interesting on the Toyota inverter noises. Varying the frequency would make a lot of sense, gives you the lower losses at lower speeds while retaining the higher update rates, and lower latencies, at higher speeds where it's needed. Unfortunately I don't think it's an option on lower inductance motors as the ripple currents would just get too big at the lower frequencies. Is it possible that the Prius inverter does this too and the 5kHz figure is what it uses at low speeds and it actually shifts to higher frequencies as the motor speed increases?

Encouraging that you have been able to run the Gen3 at 10kHz too.

Also just noticed on that post of inverter frequencies that I linked above that the Gen2 Prius is shown as 2.5kHz. If that's right then we already run it at twice the Toyota frequency, if the Gen3 could cope with the same factor then 8kHz may be fine?

I agree with celeron55, the buck-boost is very noisy, even at 10kHz but at 4kHz you need hearing protection to stand close...

The buck-boost in prius gen3 seem to run at 7,45kHz. When I google it I find this, but if I click the link I can't find the post containing that information?

It would be very surprising if it's not possible to run the inverter at 8kHz.

bexander wrote: ↑Fri Jan 27, 2023 1:56 pm I agree with celeron55, the buck-boost is very noisy, even at 10kHz but at 4kHz you need hearing protection to stand close...

Ahh, OK, I'd misunderstood and thought that was talking about using the actual inverter for charging rather than the buck/boost. Guessing it's the buck/boost inductor that makes the noise?

After fighting compiler/linker flags most of the afternoon I have a full floating point build for the F405 that builds, loads and appears to run

Ended up changing pretty much everything in pwmgeneration, foc, sine_core and picontroller to float. The sin lookup is still using the integer lookup table though. The PwmGeneration::Run() function now executes in 19us rather than 15us (with fixed point math) which surprised me a little but having reviewed the relative speeds of integer arithmetic vs floating point on the coprocessor maybe it's not too surprising that it's a little slower? Turning off debug optimisations gets it down to 15us again. Given that I have 60us available it's not a problem either way. No idea whether the new code actually works properly yet, need to get a build working inside the simulator to check but not today.

For anyone else planning on using the F405 with standard library functions the problem I was having was with use of the standard gcc math library functions, the linker seemed to want to pull in the software floating point version of libm and libc rather than the hardware floating point version and so refused to link. The following makefile seems to have sorted it (no idea whether this is the best solution but it seems to work), the key seems to be giving the linker the -mcpu, -mfpu and -mfloat-abi flags instead of the -march flag. and adding '-lm -lc' to the end of the BINARY command:

Pete9008 wrote: ↑Fri Jan 27, 2023 7:34 pm Guessing it's the buck/boost inductor that makes the noise?

Yes, that's my guess to.

Let me tell you using the motor as inductor is not quieter It's a shame I never made a video of Polo charging, it was quite a palaver. 8.8 kHz plus 100 Hz hum. With 17.8 kHz it was just 100 Hz hum plus hot inverter.

Nice find on LDFLAGS rather then hard coding the -L to the hardfp libs.

Was it a lot of changes to the F1 code base to run on the F4?