??? 03/08/07 19:44 Modified: 03/08/07 19:46 Read: times |
#134592 - there is no problem, so why do you state there is Responding to: ???'s previous message |
I also have no doubt that you've seen JTAG interfaces incorrectly wired. I've not had to deal with "memory loss" in XILINX CPLD's or, for that matter in LATTICE or ALTERA CPLD's. I've not had to deal with FPGA-booters that were corrupted. If you say it happens, I'll look into it. This is the first time I've encountered such a claim.
No, not "incorrectly wired", it you leave the JTAG TCK open just a tad of EMI will make the chip 'lose it's mind'. The simple solution is a pullup resistor, the "nugget" I used was to avoid reworking 1000s of boards to install the resistor. If you could get rid of your supervisorfobia we could end this. No, you're imagining things, Erik. I've got no problem with supervisor chips. If you want to use one, then go ahead. Clearly there's some problem, and if using a supervisor IC helps, then, by all means ... go ahead! As for "ending this," it's YOU who turned what I hoped would be a productive discussion of a perennial problem into an argument with apparently only one "correct" solution. I have never argued that your so called solution (cost by your estimate $4) would work. What I have stated is "why spend $4 when $0.39 will do the trick". Since you're so firmly persuaded that there is only one solution, that being a "proper" supervisor, please tell me, and everyone else, which supervisor IC that would be, and why, exactly, you believe it to be the perfect solution. Be careful, though, because you frequently criticize others for saying, "Well, it works for me ..." so you have to provide some basis in fact, as provided by an informed third party, and not just random conjecture based on your limited sample. "only one solution" never said that, see above "conjecture"? maybe - id so "informed conjecture" "your limited sample" no way a) "limited sample" I have more than 1,000,000 thingies of mine running, none with flash loss or erratic start. b) "your" Kai, Oleg, Dave, Andy (informed third parties), ... have described the same. The argument you have pushed with various 'attachments' can be condensed to one thing "the bad, bad chip makers have made chips that require a supervisor. Since that is so I will push the argument by adding a lot of extraneous crap to make my point" All I've attempted to do is to isolate the various potential problems so this could be addressed systematically. Instead, you want it to be an argument over who's right and who's wrong. If that's all that matters to you, then go ahead! Trumpet on about how clever you are. ONCE MORE: WHAT PROBLEM when you use a proper reset (supervisor or the one built into SILabs f12x/f13x (and other modern chips?)) THERE IS NO PROBLEM I've merely proposed that an attempt be made, mostly by me, but with some input from others on this forum, to isolate the various potential faults that could contribute to this problem. WHO GIVES A FRIGGIN HOOT use a proper reset and THERE IS NO PROBLEM Since you're unwilling and/or unable to do anything along this line, why do you go on and on to oppose it? Are you afraid that the facts that arise from such a study will prove you wrong? There's nothing to win or lose here ... no prize. THERE IS NO PROBLEM why the ... analyze a problem that is not there The fact is that when you use a proper supervisor there is no problem Again, I have to wonder on what documented facts you base this blatant assumption. Why not tell us, as I asked before, which supervisor is "proper" and what published basis you have for making such a statement. Here we go again anyone that disagree with you have to 'prove', you, however just postulate I see the current use of "supervisor" IC's as a band-aid for a problem not addressed by chip makers all too anxious to field FLASH memory in their, by now, static MCU design based on a reset intended for the previously dynamic architecture. If they'd been clever, they'd have redesigned the reset and clock circuitry. However, they were probably in a hurry. WHO GIVES A HOOT if a band-aid fixes the problem add a band-aid instead of crying about the bad, bad amnufacturers The original Intel design apparently had this reset flaw from Day 1, but it had no impact until program memory became volatile. By that time, Intel was no longer concerned with the part, since they were pushing what they thought was a better series. It DID have impact. There have been cases of improper start of machinery due to the use of RC resets even with the steam driven original '51s. So why do you keep adding more stuff? is it trying to win an argument you have already lost? What is this obsession you so frequently demonstrate? Can't you have any kind of discussion without someone winning and someone losing? I was proposing that I add a function in order to establish whether it helps with the problem of ensuring that the MCU doesn't run away and "tinkle" on the program store during the power-off transient. If you are not intersted in "winning" (I could not care less about that) why do you keep harping about 'solutions' to a problem that IS solved? Kai, Oleg, Dave, Andy and I all have stated "use a supervisor and <THERE IS NO PROBLEM so "whether it helps with the problem" is established to the satisfactio of all except you. I fear that the typical supervisor doesn't protect against the random write or erase of program memory during the power-down transient, which is its most vulnerable phase of operation. Kai, Oleg, Dave, Andy and I all have stated "use a supervisor and THERE IS NO PROBLEM so "whether it helps with the problem" is established to the satisfaction of all except you. Your favorites are, of course, inelegible because they're not offered in the most popular packages and supply voltage. That would be "populat to Richard and other amateurs" the 3V3 in TSOP is the standard for industrial use. Erik |