I've been a Third Party uCHIP Developer since the 16c5x days and your experiences are by no means unique. I've had some pretty hot exchanges with some pretty senior people there concerning these same issues and more. Your point regarding marketeers vs. engineers is perceptive. The marketing guys asert that nothing is perfect, other mfrs have problems too, and that uCHIP does a better job of getting the info out and if we really emphasized some of the issues our competition would use it to beat us up etc etc. True enough and perfectly reasonable concerns from a marketing perspective. As engineers and programmers, we'd of course like full disclosure of everything up front so that we could make informed choices in the design stage to keep from making expensive mistakes. Since one of those choices might be not to use the part in the first place.. well.. that's where the two departments will clash and we get caught in the middle. As to who bears the sometimes staggering costs that result.. you already know the answer to that one.
In your particular case, the data books all describe how the I/O works during r-m-w with the admonition to use NOPs at higher clock speeds etc etc and advice is bantered around about what's good design practice yada yada. If the data book said something like
"During any bsf, bcf to an output pin, ALL other pins on the port will be rewritten with the value that appears on that pin during the Q1 phase of the instruction. This means that at 20mhz, for example, a 50 nanosecond transient concurrent with Q1 can corrupt any or all outputs on that port, and that includes internal peripherials that may use the port.." (which in fact what is really going on)..
you'd sit up and listen. That's way
different than a few NOPs or delays. Because what all of that means is that unless you are absolutely SURE you are never going to experience even a 50ns transient EVER, the probability of losing control of your outputs is finite and non-zero. Can't speak for anybody else, but I ain't never that
sure, pardner. It would be nice indeed to have these things a bit easier to know.
Do you get proactive and put in the fix? Well, as was so kindly pointed out above, firmware fixes to cover bad design (I believe the word was 'incompetent') is not good engineering. I agree. I've also met lots of guys (usually glowering at me from across a conference room table) who insist that they shouldn't need to incorporate things like shadowed I/O and other defensive measures because they have a solid design that's been thoroughly tested and that the drivers shouldn't generate noise anyway etc etc and have only one word for that way of thinking:
For me, when I get called in to fix it and God-forbid but since you mentioned lawyers, plaintiffs, when you are called to explain that yes, you knew about the I/O issues but no, you elected not to incorporate a known fix because in your professional view, it was not necessary. For me, I'm defensive as hell and put in every trick and process I know into every design, every time and shamelessly advocate the same. If that makes me guilty of making blanket statements, mea culpa. My blanket doesn't have any 50ns holes in it, how about yours?
I'm not advocating abandoning uCHIP. Far from it. Properly implemented and deployed, they are virtually bulletproof. But it would just be nice not to have to find out about known issues the hard way. It could be worse. One guy I know got tired of the uCHIP stuff and designed a new product around another processor. Turns out that when the batteries were changed the chip would think it was in a programmer and erase its flash. Annoying, except that also erased the bootloader/programming firmware, necessitating that the SMT be removed from the board for reprogramming. The mfr's response was 'yeah we know, lots of guys are having that problem but we're not going to fix it..' Well, we fixed it, rev'ed the board and got it into production only to have the mfr discontinue the part. I remain in uCHIPs camp, wrinkles and all.
I appreciate your rational post and understand your anger and frustration completely. You are not alone by a long shot. I would urge you to develop a close relationship with your local FAE. They have more interest in your success than promoting some personal agenda or engineering world-view (mea culpa, again). Don't be shy about calling with 'stupid' questions like 'does this thing really
run at 48Mhz in HS-PLL mode like the datasheet says?' You might just find that the answer is 'NO.. but the errata's coming out soon..' (18F67J11) Saves a lot of trouble.
Sorry you got bit on this one but it sounds like you're on the right track. Keep at it.
post edited by john - 2008/02/06 19:29:17