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.
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.
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.
Is it actually possible to run a tesla motor with the blue pill?
A have a handfull of those here at home.
Any opinions are my own, unless stated otherwise. I take no responsibility if you follow my way of doing things and it doesn't work. Please double check with someone who knows what they are doing.
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.
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?
VW Beetle 2003
Outlander front generator
Prius Gen 3 inverter (EVBMW logic board)
Outlander charger
3x Golf GTE batteries
Chademo Charging
Outlander water heater
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.
