Puma board for FreeEMS

Marcos' unmaintained, but still in-use, Puma for FreeEMS circuit board/hardware design!
TonyS
LQFP112 - Up with the play
Posts: 192
Joined: Mon Jun 21, 2010 4:18 pm

Re: Puma board for FreeEMS

Post by TonyS »

Jharvey -
uC input set to pull-down sounds reasonable, except that Fred said the problem was fixed by removing the zener. If the uC was the issue, removing the zener would not have fixed the problem.

What is the mfg part number being used for the zener (just curious)?

I personally do not see the need to provide this sort of intra-board protection for the uC. Under what scenario would "protection" be provided?

Also, can you please, please, please, try to generate a pdf of the schematic for me using FreePDF (http://freepdfxp.de/xpDownload.html). You select it as a "printer" and "print" to a pdf. I have used it for years with no problems and it retains the text information in the document so that you can search for "R21" or "U7" and locate these parts on the schematic.

Thanks
-Huff
User avatar
Fred
Moderator
Posts: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Puma board for FreeEMS

Post by Fred »

Jared, re the 4.8v minimum, thats for the zener POINT, the thing is, NO zener has ever had a point, they are all CURVES, we knew this up front as they can not be used on analog stuff.... the mistake here is a mismatch between the weak pullup and the curve of the zener, and including it at all internally like that. I will do an experiment on some other pin and feed the digi circuit first a 10k pullup, then a flat 5v and see how high it goes, maybe 1k outside IS ok, but maybe its not, if not, the design process I would follow would be to find what the diode can handle, match a res value to that, then spec the power requirement of the resistor to that. not spec the power of the resistor, then determine the value, then accept the behaviour.

In any case, thank you for helping me, you were instrumental in finding (and solving) this issue even if you were off on a tangent a lot :-) You lead me to the issue!!
TonyS wrote:uC input set to pull-down sounds reasonable, except that Fred said the problem was fixed by removing the zener. If the uC was the issue, removing the zener would not have fixed the problem.
Exactly!!!!!! :-)
I personally do not see the need to provide this sort of intra-board protection for the uC. Under what scenario would "protection" be provided?
He's saying that in the case that the max chip dies it is protected, however I think ONE layer of protection is enough. I 100% agree that intra-board things should not be protected, nicely worded, thank you.

Thanks Huff! :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Puma board for FreeEMS

Post by Fred »

TonyS wrote:Jharvey -
uC input set to pull-down sounds reasonable, except that Fred said the problem was fixed by removing the zener. If the uC was the issue, removing the zener would not have fixed the problem.
Also, jesus.... its MY code, I KNOW what it does/doesn't do, mostly! :-p These have been set to input mode for 2+ years! :-p LOL...
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Puma board for FreeEMS

Post by jharvey »

TonyS wrote:uC input set to pull-down sounds reasonable, except that Fred said the problem was fixed by removing the zener. If the uC was the issue, removing the zener would not have fixed the problem.
Fred also noted he changed the resistance. You're right, that variation in the two 1k's shouldn't have made that much of a difference, so yes the diode appears to be faulty, or wrong for some reason. I don't think it's a design issue. The diode doesn't appear to be matching the datasheet. When removed from the board, what is it's resistance? Does it read something around 25k? Most DVM's will provide a small current. If the voltage is high enough, it might show a conducting diode when it shouldn't.

I believe these diodes were installed with an iron not a re-flow. Do we know if that is correct? Irons are not typically used in production as they cause ESD issues, and they dump massive amounts of heat when they touch the part. The rapid temp variation can cause the silicone to crack, as can ESD spikes. You can typically get away with this on things like MCU's because the silicone isn't well coupled to the pin. There is usually a small wire that connects the pin to the ASIC. This prevent the heat from rapidly getting to the ASIC which helps prevent thermal stressing. Resistors and caps are also very grainy by design, they can typically handle a fair bit of thermal stress before cracking. Well at least a fair bit before the crack noticeably right away. Iron heat stress/ESD stress can start micro cracks, that aren't noticeable now, but over time the heat fatigue can cause those cracks to propagate. Crack in the glass kind of thing. Doides on the other hand, typically rely on the lead to remove heat, and have a low Rth, this allows the heat and ESD to really whack them if given the chance. Thermal stress would likely not crack all the way across, and could change part of the PN junction to a simple resistor.

Hmmm, could the diode be in backwards? I see at a forward bias of 10mA the voltage drop is .9v, I would bet that voltage is much higher at 1mA. I wonder if it might be around 3.7v.
TonyS wrote:What is the mfg part number being used for the zener (just curious)?
From the BOM on puma.freeems.org the 5v1 is noted as BZT52C5V1-FDICT-ND Here's a link to the datasheet. http://www.diodes.com/datasheets/ds18004.pdf

The datasheet notes two thing of interest here. One is that at 0mA the voltage drop is about 4.8v, at 1mA it's 5.0v and at 5mA it's 5.1v. This is the curve Fred noted. I expect, if a multi meter is use to measure the diodes resistance, it will probably not conduct at all in on direction, and would likely read fairly high in the other. DVM's often use a small current with a max of around 1.5v, if you get a reading in both directions, the zener is bad. If the resistance in one direction is say under 20k ish, that also likely indicates the diode is cracked and resistive when it shouldn't be.

The other thing the datasheet notes, is the markings. This means we can verify the components is correct. I've seen digikey swap components both accidentally and purposefully.
TonyS wrote:I personally do not see the need to provide this sort of intra-board protection for the uC. Under what scenario would "protection" be provided?
You don't have to install them if you don't want to. They take up minimal space, and cost a minimal $. This board is already quite small. If you want some extra protection, you have the option. Think of it as a double rubber. Failure can really suck, so perhaps it's a good idea.

I look at it as small space, and a $1 investment, that could save me hundreds of $ and many yours of work. Seems like cheap insurance to me. Many OEM's rely on two layers of protection, or at least that the purpose of an IGBT. It offers the double layer that most OEM's require. If you would like to remove them, I'd be willing to help you with your efforts. However in this case, the extra protection was put in.
TonyS wrote:Also, can you please, please, please, try to generate a pdf of the schematic for me using FreePDF (http://freepdfxp.de/xpDownload.html). You select it as a "printer" and "print" to a pdf. I have used it for years with no problems and it retains the text information in the document so that you can search for "R21" or "U7" and locate these parts on the schematic.
I also use FreePDF. I believe that is how these were made, but I don't know for sure. I just made a PDF again and it doesn't allow text selection. KICAD must be sending a raster to the printer instead of a vector graphic. I'll see if I can find a way to make it and keep the text search option. I seem to recall the older PS2PDF thing I did was text searchable. I'll add that to the TODO list.

And I'm back out the door, It will be a couple more hours before I'm back.

TonyS, is that the same as puma_numero_uno?
User avatar
nitrousnrg
LQFP144 - On Top Of The Game
Posts: 468
Joined: Tue Jun 24, 2008 5:31 pm

Re: Puma board for FreeEMS

Post by nitrousnrg »

Have leave soon, but reading fast i can comment bout a few things:

Fred's board has been entire assembled in the oven, except for the through hole parts. Passives and schottkys were reflowed twice (first I assembled the pasives, then the ICs, etc), I'm concerned about how long i can let the paste in te free air.
He's saying that in the case that the max chip dies it is protected, however I think ONE layer of protection is enough
I think that conflcts with some things said during the development. I'm keen to get rid of those diodes, EGT, VR, and a something else have the diodes. XOR and P&H doesn't.

Aghh out of battery!! so unfair!
Marcos
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Puma board for FreeEMS

Post by jharvey »

nitrousnrg wrote:Fred's board has been entire assembled in the oven
Hmmm, Damn. I was hoping we had a finger to point. The part doesn't match the datasheet curve. Should we do some testing on that part before it gets touched with the heat? I wonder if it's temperature sensitive.
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Puma board for FreeEMS

Post by jharvey »

Fred wrote:Also, jesus.... its MY code, I KNOW what it does/doesn't do, mostly! :-p
I can say the same about hardware, but I would rather focus on the problem. I'm relying on you as my eyes, ears, and arms. I'm functioning with a very limited amount of bandwidth. Can you cut me some slack, or better give me more good data to work from. Crap like that comment are bad data I have to filter out. Sounds like you have it working on your board. I see several other modifications to your board as well. I don't know what can and can't be trusted, or what the status of your setup is.
User avatar
Fred
Moderator
Posts: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Puma board for FreeEMS

Post by Fred »

One of the zeners I pulled came off nicely and I can test that, the other got toasted. They were installed with the correct orientation, good point, checked camera for macro shots and found them correctly installed.

OK, re the datasheet values, Hmmmm, sure its not what we're seeing, but never the less, I am not surprised, AND, they are not needed, and Marcos seems to agree, and so does Huff, so, lets rip them out and make room for something more interesting that DOESN'T fuck with the signal.

Re the my code comment, that code is 2 years old, it's been thoroughly tested and not changed, it works the same as it always did... hence my comment.

If you can help me find another circuit with them installed then I can do some testing of the aux circuit to confirm operation with various external V's applied.

The max chip config was the issue TOO, anyway, so, I bridged them out of the equation by removing R40 and R42 and solderiing wires from the inputs to there and inverting my code, and i have it working on the car to the extent that its done. No cpu resets, stable v readings even with cranking etc, but I need to make the ADCS update faster when not running to catch noise during cranking and properly profile the changes during that period.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Puma board for FreeEMS

Post by jharvey »

Alright, I understand you are using a 0v to 5V input signal, not a VR and you're bypassing both the max chip and digi protect. Is this your truck or puma_numero_uno's? Is your's VR and his optical?

You have a solution you seem to be happy with, and we have room for improvement. With the digi protect's room for improvement was expected, that kind of protection is typically known for it's black magic adjustments. Sounds like we want to change that diode, but will need more testing to do so. If it were me with the optical input, I'd bypass the max, and leave the option of putting the diode back in. I think your example case is exactly why it should be left in. Yes the max is probably good enough protection, but what happens when your signal isn't the VR it was designed for? We're talking about PCB real estate equivalent to 2 grains of rice, which costs about as much as 2 grains of rice.

I know you're bent on not using KICAD. This will hinder my abilities to get you data in the short allocations of time I have, but I'll do what I can. The top level drawing notes 4 digiprotects connected to the 4 ignitions circuits. There are also 12 others that are simply connected to external pins.

MCU PJ0 is connected to digi_protect_PJ0 which is connected to connector27/pin 27 on P99. This digiprotect is page 13.
MCU PM0 is connected to digi_protect_PM0 which is connected to connector 31/pin 31 on P99. This digiprotect is page 7.
ect, ect.

That took me perhaps 5 seconds in KICAD. I understand it can be a bear in PDF land. Perhaps a helpful solution would be to name the pages something like digi_protect_PM0_PG7.
User avatar
Fred
Moderator
Posts: 15433
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Puma board for FreeEMS

Post by Fred »

Re the PDF, one thing that would help is if the text was searchable. Another would be if multiple small and/or related circuits were on a sheet together, to reduce the page count and make them less sparse.

I hear you're working on a csv of spare pins, great! That'll be good documentation for the other puma buyers :-)

We do need digi protect circuits for spare pins etc, yes, but we dont need them on stuff that has another chip in the way, intra-board as tony/huff put it so nicely. I know it costs stuff all and I know it takes no space, but it shouldn't be there, I'm not concerned about space or cost, just correctness, and it's wrong to have those components there in my eyes, and huffs too by the sound.

Once I see that CSV, I'll test a few pins with various inputs and outputs to verify voltages etc. At least that way we can get the digi protect stuff right for the pins that DO need it. Hooray.

Also, as you figured out, I am puma_numero_uno on the mac :-) My VR wheel fell off on the motorway when the engine blew up, fortunately I have a CAS with twin disks too, so i'm using it with both MegaSquirt and FreeEMS. It's niuce because its pretty safe to connect it direct to the cpu via a resistor and pull up resistor, and have a nice clean 5v square wave with no fuss. The only issue is that its not inverted and it should be, but that we can solve at a later date, just not in code.

BTW, I'm not bent on not using kicad, I like it, I'm bent on making sure others dont have to, and if I make enough noise, you guys will give me decent non kicad docs to go by - this is what everyone else will use too.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply