Configurable polarity of I/O

[Fred]

Because the boot loader has fixed polarity when it's running and we can't change that without a BDM. Most people won't use one, so we need it to be right for them.

Fred.

[ababkin]

Ok

again, pardon my ignorance, does XDP put IO pins into high impedance state when bootloading?
If it does, i may have (abstract at this point) solution up my sleeve

Alex

[Fred]

I'd have to check the source of the bootloader to be sure, but certainly it drives a bunch of my transistor buffered LEDs on on a specific subset of the pins (probably for some good reason in the intended application). That's no big deal because you just configure your hardware setup to be OFF when the pins are in that state. Then you configure your software solution to invert them from that state. Additionally, if you wire it up as per the other thread whereby the coils and injectors are all supplied by relays controlled by the fuel pump output then you only have to be concerned with one pin. I don't think we should trust users to do this though so the outputs will have to be setup to behave correctly in hardware regardless and just treat that as a double check in case of bugs etc.

Fred.

[gearhead]

So, I posted a Q in the wrong forum, thx Fred.

If I understand this, We are advocating fixed polarity for inputs? I guess I do not understand the input question. We can assume that all ntc sensors will be wired as we say they should. Same for TPS and MAP sensor. The only one out there is tacho input or missing tooth wheel. This is really not a problem for VR as I understand it as the LM1815 puts out a square wave from the trace. Hall sensors may pose a problem, but it is only with teh edge they are using. Since we are only going to deel with missing tooth wheel decoders, why does this matter? Are we thinking about dizzy triggered spark? A Hall sensor grounds the input, so it sees a tooth (+ material) or gap (material missing between sensor and magnet) and grounds the input. The falling edge or rising edge is what we are concerned with, right? This is not polarity as much as which edge. Please enlighten me. If this is software or hardware, is not that important, though as muchsoftware as we can do is 'better' from a minimization of variables when trying to diagnose a problem over the web.

My main concern is boot loader. I am guessing that all outputs are pulled low during code load. This is not a problem with injector drivers or even relay drivers (fuel pump and other accessories). These would all be inert during code load if these drive circuits are conducting only when logic = hi. I think we should allow the end user to ensure polarity is correct for the ignition outputs. If your coil driver or ignition type is inert when the logic low, you should be OK. If not, you should be able to invert the output. Seeing as this appears to be the default action of the bootload code, we should have the inversion in hardware.

If we do it with the uP driving an IGBT directly, it will ground and make the coil conduct causing certain coil death. If we invert the output before it gets to the IGBT or other drive transistor, all components should be happy. If the uP is driving a logic level signal using a transistor or logic level fet (with a pullup on the output) we need to bypass that inversion if we can fry things by being low. I'd rather this be soldered jumpers or by jumpering from base hole of transistor X to gate hole of fet Y so that you have to do something to actually change it. A jumper header is too easy to get wrong, IMO. I also feel that the default configuration should be toi have the IGBTs drive coils directly. A low level output should be an alternate construction.

Just think how many fried VB921s could have been saved if they just put a 2n3904 as a drive transistor.

Do I have this right?

Gearhead

[davebmw]

Is there any way to do this in software? what i mean is if an IO line is high because the ignition switch is on it disables the re-flashing of the MCU, kind of a write protect pin. Or am i completely talking out of my arse?

[ababkin]

I think my idea would require them to be in high imp state in order for it to work (with your requirement to keep the original bootloader in-tact).
The possibility of having automatic default polarity detection keeps exciting me.

anyway, let me share the abstract idea:
we need to come up with a feedback analog circuit that would let the signal level 'stabilize itself at the point of least current'. Here is what i mean by that:
- bootloader puts the ign/inj IOs into high imp state
- the above feedback circuit would 'pull' the pin to one of the endpoints (i.e. Vss or Vcc)
- this 'pull' puts inj/ign power outputs at certain level of current
- this current level drives the feedback circuit to direct the 'pull' level (i.e stay at the first asserted value or keep moving towards the other side of the spectrum)

furthermore, the feedback will loose its driving ability once MCU IO level is returned to low impedance (i.e push-pull state) so there is no need to actively switch off such self-balancing feedback circuit.
One can see that this idea will necessitate the high-impedance state of the IO during bootload.

please take the above idea with lot's of grains of salt as it happened to originate in my head (a.k.a. koo-koo-land )

[ababkin]

update:

just got off the phone with Karl @ TA.ca
he says that to his knowledge, bootloader leaves majority of the IO pins at their reset state (inputs, high-impedance)
He recommended going through the source code of the serial bootloader to make sure.

Alex

[Fred]

If I understand this, We are advocating fixed polarity for inputs? I guess I do not understand the input question.

That is correct. We don't HAVE to do this, but it will make the code cleaner and avoid configuration based issues where someone forgot the polarity setting etc. One it's setup it stays setup and you don't mess with it. As I said, I have a solution for configurable input polarity, but I don't like it as it is in the ISR section to some extent. There may be a better way, but I think it would make for more comprehensible code if we don't have it configurable and just stick an XOR chip in there instead.

We can assume that all ntc sensors will be wired as we say they should. Same for TPS and MAP sensor. The only one out there is tacho input or missing tooth wheel.

Correct, only the RPM input is up for discussion.

This is really not a problem for VR as I understand it as the LM1815 puts out a square wave from the trace. Hall sensors may pose a problem, but it is only with teh edge they are using. Since we are only going to deel with missing tooth wheel decoders, why does this matter?

Because it's an ugly thing to configure. It is possible, and not hard, but I'd rather take it out of the code if I had my way.

The falling edge or rising edge is what we are concerned with, right? This is not polarity as much as which edge. Please enlighten me.

If you switch the polarity you switch edges. It's that simple. The code always triggers on the falling edge and the user configures whether the falling edge to the micro is the falling or leading edge entering the board. Edge and polarity are one and the same at the end of the day.

Are we thinking about dizzy triggered spark?

No, though any setup would use the same zero-conf, hardware setup system if we go through with it.

If this is software or hardware, is not that important, though as muchsoftware as we can do is 'better' from a minimization of variables when trying to diagnose a problem over the web.

I disagree with this statement. What we are looking to do is help noobs get the system working and then (critically) not hear back from them with complaints and questions after that time. If they have to think and setup the hardware to match their hardware then they will know what they are doing to a greater extent. Secondly they will actively have to change it, not by accident in the software, or through a bug in the software or through a setting being lost upgrading etc.

Do you see where I'm coming from?

The benefits to hardware input polarity are :

1. Cleaner code
2. Faster code
3. Less code
4. Impossibility of accidental change (forces it to be deliberate)

Drawback is :

• Can't change it quickly when experimenting etc.

I'd argue that if we set it up with the close pads as Jean suggested then it's quick and easy to change in hardware too. If you believe my argument there is no drawback really.

My main concern is boot loader. I am guessing that all outputs are pulled low during code load.

Assumption is the mother of all... No, some are high, some are low. we need to be careful about which is which, also, we are susceptible to TA changing the pins states in future bootloader versions (though I strongly doubt they would do that).

This is not a problem with injector drivers or even relay drivers (fuel pump and other accessories). These would all be inert during code load if these drive circuits are conducting only when logic = hi.

Actually, it is a problem because port K are ON during bootload. Port K are our staged pins. They'll be on a second board anyway, but the software should be setup to utilise them in that same fashion such that it's always the same. In hardware = no flooded engines and no burnt coils etc.

I think we should allow the end user to ensure polarity is correct for the ignition outputs. If your coil driver or ignition type is inert when the logic low, you should be OK. If not, you should be able to invert the output. Seeing as this appears to be the default action of the bootload code, we should have the inversion in hardware.

Absolutely :-) Universal agreement on the outputs then at the least. Hooray.

I'd rather this be soldered jumpers or by jumpering from base hole of transistor X to gate hole of fet Y so that you have to do something to actually change it. A jumper header is too easy to get wrong, IMO.

Absolutely, I agree 100%

I also feel that the default configuration should be toi have the IGBTs drive coils directly. A low level output should be an alternate construction.

Sure, this makes good sense.

Just think how many fried VB921s could have been saved if they just put a 2n3904 as a drive transistor.

Only some of them. HEAPS have died during normal use too. They are only good to about 3ms dwell. 5ms is a good number for many modern coils and older ones are even worse... they just overheat and shit themselves way way way too easily WITHOUT a fault condition. Of course, there are no VB921s anymore, they were end of line a long time ago. Good bloody riddance to them.

Do I have this right?

Some of it

Is there any way to do this in software? what i mean is if an IO line is high because the ignition switch is on it disables the re-flashing of the MCU, kind of a write protect pin. Or am i completely talking out of my arse?

The thing is Dave, the bootloader (software we don't control) has a fixed set of states when it is active. This can't be changed without a BDM that most people will not have. So, given that some of the time it is in a fixed state we can't control (but do know about) we must setup the hardware to be OFF during that time and configure our software to match that in a fixed way. If we allow it to be adjustable, people WILL (ms proved this) set things up such that they fry during boot load. This is unacceptable so we need a hardware solution for it.

just got off the phone with Karl @ TA.ca
he says that to his knowledge, bootloader leaves majority of the IO pins at their reset state (inputs, high-impedance)
He recommended going through the source code of the serial bootloader to make sure.

I'd say it's about 33% ON and 66% off/inputs... we need to take care of it anyway in case they change in future. This is not hard to do using some ICs as described earlier.

So, I'll call that settled for outputs, outputs are definitely getting hardware inversion. The main injector FETs don't necessarily need it, but the staged ones and the ignition ones do. If we want to future proof a change in supplied Bootloader code form TA then we should have them on the main injectors too. Ditto the fuel pump outlet FET/transistor.

Now, about those RPM inputs, who thinks what about those? Please justify your opinions as best you can.

Fred.

[Fred]

At least 20 pins are ON and I don't have them all connected to be able to tell at the moment. Some of those are important pins. Either way, as I said, we can't guarantee the future bootloader code of TA boards so we should plan for that now. It's a small price to pay and increases the switch on drive to the injector drivers and buffers the CPU pins as well.

20/90 = 22%

Fred.

[ababkin]

Fred, by ON do you mean push-pull logic level 1 , or also high-imp (configured as input) and pulled up internally?

did you just voltmeter it with no load?

personally, don't see why freescale/TA would change this IO states/behavior, but for fool-proofness we can add specific instructions to specifically check for whether the relevant pins go in ON, OFF or high-imp state into the assembly manual as an intermediate step (i.e before the power units are in)
This level measuring step will have to be present in manual (large font in red) anyway, as the IO pins that are assumed to be ON in the current iteration of the bootloader, may be changed to OFF in future versions.


Alex