[info] Frankenso - ECU shield compatible with OEM case / official

[AndreyB]

Unless we remember why is it this strange way I suggest to simplify high-side schematics by changing input network names to match output names. Output names are already part of some other documents so we have to keep these, but the inputs # could better match output #.

112) reduce high-side schematics confusion where H_IN1 is HL2, H_IN3 is HL1 etc.

[AndreyB]

Looks like footprint position files are missing positions for all SIL-2 and SOD-123 components like F1001 and D420, somehow the assembly shop was getting away without it before but now they want it

[kb1gtt]

First orders were probably hand soldered, for some reason they are pushing PNP this time. Perhaps this is because it has a couple repeat orders or perhaps they have extra capacity in the PNP. Who knows why, but they are doing machine assemble this time.

[AndreyB]

And the answer is http://kicad-users.yahoogroups.narkive.com/OHuIAYkP/components-missing-in-position-file for all of these. I will fix 0.4 in repo but would not touch current 0.5 board in development

I forgot to update the attributes of the footprint to Normal + Insert!

So we have

113) "Normal + Insert" attributes for all SIL-2 and SOD-123 footprints to fix position file generation

[AndreyB]

New batch is on the way, this time with a vertical USB socket and with the button on all boards.

[kb1gtt]

There are some concerns with the assembly, most aren't that critical, but would certainly raise issues if we were an OEM making boards. On one hand, they are low cost assembly and are better quality than most DIYers trying to assemble it. But on the other hand it's not really OEM quality work. See below pictures that show, shinny and dull solder joints, bulging solder joint, void in solder joint, flux blobs and randomly filled P13. If someone has a suggested assembly house that does good electrical checks, and does good quality of craftsmanship, we would be all ears. For now they are likely to be assembled by this house, and other than the PCB shorting issue, they are all manageable issues.

[AndreyB]

rusEfi racing debut at http://www.24hoursoflemons.com/events-results/article/166-real-hoopties-of-new-jersey this weekend.

What is the probably that one of these LCD mounting nuts would get loose, fly just a little bit and shorten/kill the brain board? Lock tight? Plastic nuts? Opinions?

[Abricos]

A nyloc nut, also referred to as a nylon insert lock nut, polymer insert lock nut, or elastic stop nut, is a kind of locknut

[AndreyB]

Could be too tall but order placed for m3 nylon lock steel nuts.

[Abricos]

Nylon PCB Space Support Mounting

[kb1gtt]

I second the plastic spacer concept. They work surprisingly well, and if they fall apart they don't short things.

[AndreyB]

I love hardware!
Right now I am playing with a VW with a distributor - so just one high-side PE14 is initialized by the firmware, the other high side pins are in whatever state.

Once I start cranking, a couple of times four or five high-side LEDs would blink in sync with the PE14 - PC7, PC9 and PE10, after a second only three LEDs would be blinking instead of only the expected PE10.

Changed the firmware settings to explicitly initialize pins PC7, PC9 and PE10 and now they do NOT blink in sync. Conclusion: floating control pins get something from somewhere?

[kb1gtt]

Remember that floating will still be limited by the rail diodes, I seem to recall one diode will make for a very light pull down, such that float will typically float close to 0V.

[Dial0]

You are talking about the TC4427?
Looking at the datasheet the input looks like a mosfet.
What I think could be happening is that mosfet gate is charging and discharging, because all the high side input traces run parallel so the other input traces have a tiny current induced in them from the signal on the PE14 trace.

Setting the pins to immediately initialise as low, will probably work fine. The only worry is that when you first power the ECU board, it could cause the output of the high side drivers to output high.
Which was a problem with one of the megasquirt boards, causing the spark plugs to spark when the key was first turned on.

[AndreyB]

Yes TC4427. This issue is now tracked as https://sourceforge.net/p/rusefi/tickets/293/

Another not so fan fact: not only these extra LEDs blink, somehow this also affects timing?! I believe we have observed a ~10 degree timing shift between just one LED blinking as it should (with the firmware initializing the rest via a hacky-configuration) and the current default state where the firmware is not touching the pins

[Dial0]

I am not able to test this in hardware right now.

However looking at the files, there are a few things I am not sure about In the board patch file.

Just to clarify whats been changed.

PCMLK(PC7?) and PC9 have been changed to an output.

PCMLK(PC7?) is set to floating output. PC9 is changed from a pull up to floating?

PE8, PE10, PE12, PE14 all set to output.

PE12 is set to a pull up. PE14 is set to a pull down. PE8, PE10 are set to floating?

Code: Select all

@@ -491,9 +491,9 @@
                                      PIN_MODE_INPUT(GPIOC_PIN4) |           \
                                      PIN_MODE_INPUT(GPIOC_PIN5) |           \
                                      PIN_MODE_INPUT(GPIOC_PIN6) |           \
-                                     PIN_MODE_ALTERNATE(GPIOC_MCLK) |       \
+                                     PIN_MODE_OUTPUT(GPIOC_MCLK) |       \
                                      PIN_MODE_INPUT(GPIOC_PIN8) |           \
-                                     PIN_MODE_INPUT(GPIOC_PIN9) |           \
+                                     PIN_MODE_OUTPUT(GPIOC_PIN9) |           \
                                      PIN_MODE_ALTERNATE(GPIOC_SCLK) |       \
                                      PIN_MODE_INPUT(GPIOC_PIN11) |          \
                                      PIN_MODE_ALTERNATE(GPIOC_SDIN) |       \
@@ -541,7 +541,7 @@
                                      PIN_PUPDR_PULLUP(GPIOC_PIN6) |         \
                                      PIN_PUPDR_FLOATING(GPIOC_MCLK) |       \
                                      PIN_PUPDR_PULLUP(GPIOC_PIN8) |         \
-                                     PIN_PUPDR_PULLUP(GPIOC_PIN9) |         \
+                                     PIN_PUPDR_FLOATING(GPIOC_PIN9) |         \
                                      PIN_PUPDR_FLOATING(GPIOC_SCLK) |       \
                                      PIN_PUPDR_PULLUP(GPIOC_PIN11) |        \
                                      PIN_PUPDR_FLOATING(GPIOC_SDIN) |       \
@@ -726,13 +726,13 @@
                                      PIN_MODE_INPUT(GPIOE_PIN5) |           \
                                      PIN_MODE_INPUT(GPIOE_PIN6) |           \
                                      PIN_MODE_INPUT(GPIOE_PIN7) |           \
-                                     PIN_MODE_INPUT(GPIOE_PIN8) |           \
+                                     PIN_MODE_OUTPUT(GPIOE_PIN8) |           \
                                      PIN_MODE_INPUT(GPIOE_PIN9) |           \
-                                     PIN_MODE_INPUT(GPIOE_PIN10) |          \
+                                     PIN_MODE_OUTPUT(GPIOE_PIN10) |          \
                                      PIN_MODE_INPUT(GPIOE_PIN11) |          \
-                                     PIN_MODE_INPUT(GPIOE_PIN12) |          \
+                                     PIN_MODE_OUTPUT(GPIOE_PIN12) |          \
                                      PIN_MODE_INPUT(GPIOE_PIN13) |          \
-                                     PIN_MODE_INPUT(GPIOE_PIN14) |          \
+                                     PIN_MODE_OUTPUT(GPIOE_PIN14) |          \
                                      PIN_MODE_INPUT(GPIOE_PIN15))
 #define VAL_GPIOE_OTYPER            (PIN_OTYPE_PUSHPULL(GPIOE_INT1) |       \
                                      PIN_OTYPE_PUSHPULL(GPIOE_INT2) |       \
@@ -778,9 +778,9 @@
                                      PIN_PUPDR_FLOATING(GPIOE_PIN9) |       \
                                      PIN_PUPDR_FLOATING(GPIOE_PIN10) |      \
                                      PIN_PUPDR_FLOATING(GPIOE_PIN11) |      \
-                                     PIN_PUPDR_FLOATING(GPIOE_PIN12) |      \
+                                     PIN_PUPDR_PULLUP(GPIOE_PIN12) |      \
                                      PIN_PUPDR_FLOATING(GPIOE_PIN13) |      \
-                                     PIN_PUPDR_FLOATING(GPIOE_PIN14) |      \
+                                     PIN_PUPDR_PULLDOWN(GPIOE_PIN14) |      \
                                      PIN_PUPDR_FLOATING(GPIOE_PIN15))
 #define VAL_GPIOE_ODR               (PIN_ODR_HIGH(GPIOE_INT1) |             \
                                      PIN_ODR_HIGH(GPIOE_INT2) |             \

[AndreyB]

By default looks like pins are set to input mode by chibios. My first step was to try output, pulldown which to my suprise did not get the result I was looking for. At this point I've started trying random combnations to no avail.

[Dial0]

My Suggestion would be to set up the pins connected to the TC4427's as:

VAL_GPIOI_MODER
PIN_MODE_INPUT(GPIOI_PIN14)

VAL_GPIOI_OTYPER
PIN_OTYPE_PUSHPULL(GPIOI_PIN14)

VAL_GPIOI_OSPEEDR
PIN_OSPEED_100M(GPIOI_PIN14)

VAL_GPIOI_PUPDR
PIN_PUPDR_PULLDOWN(GPIOE_PIN14)

VAL_GPIOI_ODR
PIN_ODR_HIGH(GPIOI_PIN0)


Then in the rusefi code when those pins are assigned to an ignition channel they should be setup as outputs.

VAL_GPIOI_ODR
PIN_ODR_LOW(GPIOI_PIN0) -- Set the initial output to low by setting the ODR to low.

VAL_GPIOI_MODER
PIN_MODE_OUTPUT(GPIOE_PIN14)

VAL_GPIOI_OTYPER
PIN_OTYPE_PUSHPULL(GPIOI_PIN14)

VAL_GPIOI_OSPEEDR
PIN_OSPEED_100M(GPIOI_PIN14)

VAL_GPIOI_PUPDR
PIN_PUPDR_PULLDOWN(GPIOE_PIN14)

[kb1gtt]

My vague understanding of the MS issue was that some pins would default to hard drive to +V, then the software would change it to float or what ever it needed. Then if you had a brown out condition, or watch dog condition, that pin would never get set via software. This could cause your coil to burn up, or fuel injectors to fill you intake with fuel.

My understanding of the STM is that it's powered on default is to float, with a very slight tendency to float low. The rail clamping diodes have some leakage, with slightly more leakage going to the negative rail. As well this leakage is largely based on voltage, so you have less leakage when you are at say 1V. I could see how energy could get coupled into these signal lines and it would take a fraction of a second to leak to the rail, which might allow a small fuel pulse or small spark event. I would not expect MS problems though. A pull down resistor is probably a good idea, I'm not sure whey I didn't do that. As well I generally include a current limiting series resistor. Such that a failed MOSFET doesn't burn up the brain chip. I just added this to my list to function as a reminder to look at this for the next spin.

114) Add pull down and series resistors to hi/low mosfet driver

The STM can be configured to have pull up or pull down resistors, as well the transistors can drive high or low. I understand the ADC's can also be connected, such that you could have a pull down resistor, with a transistor that pulls high, then the ADC can verify the voltage making sure you have actually reached the proper level to turn off or on the pin.

[AndreyB]

Thank you @ I think it did it! I was putting PIN_PUPDR_PULLDOWN into the wrong section and that's why it was not working, now it's good - https://sourceforge.net/p/rusefi/tickets/293/ is resolved for hi-side, will do the same for low-side a bit later.

Jared, we have four layers here:
1) stm32 chip
2) rusEfi board
3) ChibiOS does explicitly set some state for each pin - that's the board.h file we are changing, that board.h file does not have same state for all pins - they do it accordingly with stm32f4discovery in our case
4) rusEfi firmware changes mode of the pins it wants to use, leaving the rest in the ChibiOS default state

So, we've changed ChibiOS defaults in our repository and this has resolved the issue. Let's welcome @ to the ranks of contributors

[kb1gtt]

Yipee, contributors are cool, and thanks @Dial0.

I'll still plan for 113) as that makes it a bit stronger.

[AndreyB]

We have a merge conflict, can you please take my version of the file

114) PC0 - hip9011 vs USB OTG current limiting chip STMPS2141STR conflict
115) PD5 vs USB OTG current limiting chip STMPS2141STR conflict
116) better part number for D703 to avoid leakage
117) Add pull down and series resistors to hi/low mosfet driver

[Dial0]

Awesome! Glad we got a solution.

I agree with kb1gtt on the external pull down and current limiting resistor. We kinda have solved a hardware issue with software.
I think the only reason to use the internal pull down would be to save board space or reduce cost, and I don't think either of those are issues.

will do the same for low-side a bit later.

You shouldn't need to change the low-side configuration, as it has the external pull down resistor. However there is no harm in configuring it to have an internal pull down as well.

[AndreyB]

118) add silkscreen labels matching Frankenso analog inputs mapping on wiki - maybe closer to diodes?

I mean these CLT IAT MAP TTS VBATT labels like on

[AndreyB]

117) Add pull down and series resistors to hi/low mosfet driver

Yep, we do need these for sure - but hopefully we can also survive this as is on the existing boards:

[video][/video]

[AndreyB]

@ has stopped by today and we've notices something strange using his oscilloscope. 5v output, clt/iat/tps signals all look nice. VBatt signal on the other hand shows some ripple. We've tried some troubleshooting but the results are pretty puzzling:

Frankenso board without stm32 on the car: clean vbatt signal
Frankenso board without stm32 on the car: periodic noise, see pictures (stm32 removed from frankenso, 5k+5k resistor as input into the vbatt pin: clean signal)

Update: on all pictures the car was NOT running. All measures were taken on discovery pins - either discovery pins or Frankenso header if discovery was removed. Scale could be 10x off since there was some scale drama, but it's the shape which is probably more important.
Battery pin is PC4, I've checked the schematics - it's mentioned on the audio chip page but it says 'resistor not fitted', I guess I would need to double-check on the actual board. Pins which looksed better were PC1 PC2 PA2.

[kb1gtt]

I'm not following your pictures. I think your saying you see noise when the STM32 is installed. Were you measuring the battery directly, of was this the resistor divider after the opamp?

I see the 12V signal appears to be at 13V, perhaps 13.5, was the engine running?
The yellow 5V signal appears it's at 50V not 5V. Perhaps you have the 10X vs 1X settings set wrong on the scope / probe. Either way you are full scale on that 5V signal so it's data is not valid.

If you are looking for ripple, you can set the scope software to AC mode instead of DC mode, this will allow you to zoom in on the ripple of the signal.

[puff]

it might be the module/coils, which are being energized/drained all the time the ignition is on.

[AndreyB]

Sorry I should have provided more details right from the beginning. Update posted, see the original message.

[puff]

Frankenso board without stm32 on the car: clean vbatt signal
Frankenso board without stm32 on the car: periodic noise, see pictures
stm32 removed from frankenso, 5k+5k resistor as input into the vbatt pin: clean signal

the second line should read 'with'?
What I mean to say is it seems obvious, stm32 is commanding some devices to turn on, which gives a slight drop on the battery. It might be coils, it might be fuel pump. What else is there which is connected and turned on by stm32?