On or about Jan. 15 I wrote Microchip asking; In the "PIC18FXX2 Rev. B3 Silicon Errata Sheet", can you be more specific regarding the "certain conditions" in Issues 5 and 6"? Their response; This means that the behavior only exists for particular code sequences at a voltage/frequency/temperature point. This point depends on the silicon lot. Here's the best way to check if you're experiencing the errata behavior. Try to increase and reduce the frequency to see if your application fails. Also test through the intended temperature range of operation. If at certain temperatures or frequencies, the application changes, then it MIGHT be the errata. Run these tests on a sample set from different lots. I also commented to them that, due to the additional code and instructions cycles required, the 18F452 may be unusable in a current application. Their response; When implementing the workaround, you do not need to insert FFFF NOP at each and every CALL, GOTO, RETURN, or TABLE READ. You only need to look at these instructions that jump across the 4000h boundary. This will limit the scope greatly. And the problem may only be occurring on only one of these statement in all of your code. In this case, it's a matter of finding which one. So the best case scenario is you may only need to add 1 FFFF NOP. That didn't really help me that much as I don't even have one 'lot' to test nor the capability but maybe it will help you. I see that some of the B3 problems have been fixed in B5. Now, how to figure out what date code that is. Mike Jones ----- Original Message ----- From: "Tony K|bek" To: Sent: Monday, February 17, 2003 6:09 AM Subject: [PIC]: PIC18FXX2 Silicon/Data Sheet Errata, experiences ? Hi, This January Microchip released an revised errata for the 18Fxx2 series of chips, and in this there are some disturbing problems mentioned. Particulary refering to 18F452, the errata states that an table read, call, goto, return, retlw or retfie crossing the 0x4000 program boundary can, and I paraphrase, "Under certain conditions.....may yield unxpected results". Now there are no further explanations part from the suggested 'fix' to put 0xFFFF as the first instruction after CALL or GOTO, OR insert 0xFFFF immediately following RETURN, RETLW or RETFIE. It's also recommended to add either or both "as needed" ??? when do I need to add both ? Now, even though I understand the factual information , I am a bit perplexed by this bug, I do use 18F452 and have tables and/or calls that operates across the 0x4000 program boundary. I have not added the suggested fix but still I have not surfaced any problems (yet).Have I just been lucky ? does anyone have more information about the specifics when these errors surface ? Yes I know, short answer, just add the 0xFFFF all other the place, but I'm reluctant to do so, I already have quite a few conditionals to cater to various bugs, adding additional ones is starting to get me very wary aginst using these chips at all. Particulary as when using the linker, normally you do not have full control in which segment an particular routines and/or table is placed. Not crossing 0x4000 boundary is a tricky beast to handle with the linker. Can anyone enlighten me more than the errata ? /Tony -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics