openinverter forum

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.

Got myself a blue pill
So the best way to figure out whether running on a blue pill is turning on GPIOC12 (Led port of Olimex and other HW revisions) and then read it back. Since the port does not exist on the C8 it reads back as 0.
I also checked the FLASH_SIZE register and its actually 0x80 = 128k flash
Finally I found out that TIM4 actually runs, it is just not connected to any pins. So theoretically it would be possible to restore the over current reference pins using TIM2 and doing the scheduling with TIM4.

So in order to restore the over current reference pins I'd have to delete ESTOP (quite unimportant) and remap DCSW to PC15.
Damien, what do you think?

Well , the only pcb I have done so far for the blue pill is the little gen 2 prius board which i can just hack up my own version to run in a pinch. So i guess it makes sense to bring that feature back if possible.

Alright, here is a new pin map and firmware

Going to be such a laugh running Model 3 motor with a blue pill:)

Next up: the 36-pin part

Good evening, I would like to ask if a single-channel encoder will work on it? What is the exciter pin used for?

yaroslav wrote: ↑Tue Aug 27, 2019 7:41 pm Good evening, I would like to ask if a single-channel encoder will work on it? What is the exciter pin used for?

Single channel not yet but I think it can be restored.
Exciter pin generates a square wave in resolver mode that is turned into a sine wave by a 3-pole low pass filter and then amplified by an audio amplifier. With that the resolvers primary winding is excited, see wikipedia why this is needed.

If it is not difficult you can make support for a single-channel encoder.

Is it actually possible to run a tesla motor with the blue pill?

A have a handfull of those here at home.

JaniK wrote: ↑Thu Aug 29, 2019 5:15 pm Is it actually possible to run a tesla motor with the blue pill?

Yes of course.

Good evening, I collected on such a Board inverter for the test, but there was a mistake DESAT what are the conditions for its appearance?

yaroslav wrote: ↑Sat Aug 31, 2019 4:35 pm Good evening, I collected on such a Board inverter for the test, but there was a mistake DESAT what are the conditions for its appearance?

Are you getting the desat error flagged every time you try start your dev board? You need to pull the fault line low, I believe the same line is used for a few different faults.

A number of the Blue Pills for sale on eBay only have the 64k processor, so you won’t be able to save your parameters unless you change the start of the eeprom block.
0x8001fc00 -> 0x800fc00, basically replace the 1 with a zero.

The current firmware is about 38k, so will easily fit inside the smaller memory.

Dilbert wrote: ↑Sun Sep 01, 2019 9:39 pm

yaroslav wrote: ↑Sat Aug 31, 2019 4:35 pm Good evening, I collected on such a Board inverter for the test, but there was a mistake DESAT what are the conditions for its appearance?

Are you getting the desat error flagged every time you try start your dev board? You need to pull the fault line low, I believe the same line is used for a few different faults.

I think I found the cause, you need to pin pb12 to apply logical unit, as in previous schemes was 0, as then to implement the current protection?

I'm having a little play with my newly arrived Blue Pill, I've moved the little jumper across and run ./stm32flash -r ~/open-inverter/tumanako-inverter-fw-bootloader/stm32_loader.hex /dev/tty.wchusbserial1410

Is there any way of checking this has flashed the inverter fw bootloader as expected?

if you don't get any errors reported it's almost certainly worked. You could add the -v argument for stm32flash to get it to verify.
Have you tried flashing a simple blink program that just blinks the LED on the board? that would also prove that flashing works.

I've used one of the cheap st-link clones and st-flash which works well and gives a whole heap of useful output when I've played with the blue pill in the past.

I previously flashed a blink sketch from Arduino IDE using FTDI. I've now flashed both the bootloader and firmware. I've moved the jumper back over and reset. The LED still blinks, so I'm not 100% convinced it has flashed over.

According to http://manpages.ubuntu.com/manpages/bio ... ash.1.html -r reads the flash, doesn't write it. You'd need -w to write it, probably best regenerate stm32_sine.hex as it's a blinky now then.

Doh, thanks