openinverter forum

Decided to see if the inverter firmware would run in the so called Blue pill cheap STM32 boards that are available for a few Euros on ebay. Loaded in the bootloader and firmware hex with stlink and to my amazement it works. As the blue pill uses the smaller 44 pin package some pins are missing but I think the important ones are present.

Interesting. If you do most of the communication over CAN then you can afford to lose quite a few of the IOs.

At that sort of price, the blue pill might be a candidate for the CAN version of Johannes' BMS Isolator board.

So with some tweaks to the io mapping and deleting some error pins it fits. Tested on a breadboard generating pwm in open and closed loop. Now just need to run a motor:)

Now with resolver exciter generation.

Nice work JB, those blue pill development boards are absurdly cheap. And PC_15 free if needed.

From reading the STM32 datasheet it seems the polarity of the bkin pin can be changed from active high to active low. Looking in the libopencm3 documentation seems to confirm this :
http://libopencm3.org/docs/latest/stm32 ... 49b6533f10

via the timer_set_break_polarity_high() or timer_set_break_polarity_low() commands.
However I can find neither in the code. Anyone care to assist?

found it in pwmgeneration.cpp

Nice work everyone. I like how the hardware is now being scaled down instead of up
I'm on the train back home from another bike trip so will be more active again.

Will adapt the software to detect the Blue Pill. Since TIM3_ETR is missing *maybe* Single Channel encoders won't work. But will look into it later, maybe that pin was never needed in the first place.
Just figured that board is cheaper than the contained STM32 in 1000 quantities on digikey. Absurd.

Atmega 328p is cheaper to get on a Chinese pro-mini than to buy from a distributor too. They must produce millions of them.

Jack Bauer wrote: ↑Sun Aug 11, 2019 10:25 am Now with resolver exciter generation.

Is Black Pill any different?
https://stm32-base.org/boards/STM32F103 ... -Pill.html

Seems the same, only black?
Interesting that 3V3 can only be loaded with 150mA. Not quite sufficient for the wifi mod

It would be perfect for Prius inverter boards. If we would use 2 of those boards. Lets say one for the traction motor and another to control the DCDC (buck-boost) converter - charger. That would make the master boards easier to assemble i think...

So JB do you fancy using both motors for traction or could you use the second UVW as input from L2 charging station?

Way ahead of you:)

viewtopic.php?f=14&t=51&start=140

Here's a first try to make a unified software that supports Blue Pill.
I have added mprot again (to have to change less code) and mapped the error output to the yet free PC15

The code is also on github in the bluepill-test branch

Just more thoughts on the mprot pin. It makes sense to tie it to your supply voltage (aka 12V) via the 4k7/1k2 divider to be able to read the uaux value. So it's not really in the way.
The emcystop pin doesn't do anything useful, it is just used to determine whether a shutdown (bkin) was caused by emcystop or something else. So it would make sense to delete it and map something else like brk_out (brake light output) or vtg_out (over/under voltage output)

I also read about the STM32C8T6 to often have 128k of flash instead of 64k. This is somewhat important because the parameters and CAN mapping is stored in the last two flash pages. So if you can't store and reload you're parameters that would be why.

Spacewise bootloader+firmware+parameters would also fit inside 64k so I could do this in the blue pill to be safe.

First BluePill based board is done:)
https://github.com/damienmaguire/Prius-Gen-2-Inverter

Could it be the 10 Euro inverter board??

Good evening, is it possible to remove a few more functions from the blue board such as estop, mprot, tmpm a tmpm b ?

yaroslav wrote: ↑Fri Aug 16, 2019 7:24 pm Good evening, is it possible to remove a few more functions from the blue board such as estop, mprot, tmpm a tmpm b ?

Those functions are prevention measures. I dont think it would be good to suppress them.
Hm.... Johannes maybe you could rewrite code for digital temperature sensor like this one.
https://www.maximintegrated.com/en/prod ... 18B20.html
A lot of sensor could be on a single pin.
That would clear at least one pin and then you could merge functions of Mprot and EMGCY stop pins?

Yes giving the pins a think-over is certainly indicated. I'd also like to restore the over current reference that is usually produced by Timer 4. The C8 doesn't have TIM4 or maybe its pins are just not present. In that case I could use TIM4 for the task scheduling and TIM2 for the over current reference.

johu wrote: ↑Sat Aug 17, 2019 6:34 am Yes giving the pins a think-over is certainly indicated. I'd also like to restore the over current reference that is usually produced by Timer 4. The C8 doesn't have TIM4 or maybe its pins are just not present. In that case I could use TIM4 for the task scheduling and TIM2 for the over current reference.

If we use scavenged parts there is Fault output for everything connected with IGBTs. That is a single interrupt for like UVLO, Desat, overtemp and overcurrent protection. In case of DIY inverter we would have to add small IC to controller just to monitor those interrupts and signal through that Fault line. How much additional work is that?

So you mean like an AND tree? The output of it could go straight to the BKIN pin as is done on the previous revisions anyway. The additional pins were just connected to the µC to find out what caused the fault. But that is certainly not a must-have.
The programmable over-current limit is useful during testing to take some stress off the power stage. E.g. the Leaf power stage only has desat. Too many desat events (like 100) will ultimately cause the power stage to fail.

johu wrote: ↑Sat Aug 17, 2019 9:44 am So you mean like an AND tree? The output of it could go straight to the BKIN pin as is done on the previous revisions anyway. The additional pins were just connected to the µC to find out what caused the fault. But that is certainly not a must-have.
The programmable over-current limit is useful during testing to take some stress off the power stage. E.g. the Leaf power stage only has desat. Too many desat events (like 100) will ultimately cause the power stage to fail.

Hm... if you use a single digital input you can use the small IC (pic16F?) to sense fault on its pins and then send signal with on byte fault msg which will tell master which error we are dealing with. Then master can decide which level of error it is, shutdown, reset, master alert or caution. This would then correspondingly lit certain LED in the dash scheme.

I agree Desat fault should be HW connected (fast) and this fault logged and counted against repetitive events.