I decided to start a need thread rather than continue the tangent in this thread: http://forum.allaboutcircuits.com/threads/saving-settings-in-pic-memory.128085/page-2#post-1047873

For those who only read the first few lines, I found this old discussion in the Hi-Tech forum informative: http://forum.htsoft.com/all/showthreaded.php/Cat/0/Number/2138/page/.-/vc/1 Those DS links are still available, if you search in Google by the number.

I decided to see whether I could duplicate the GIE problem with a 12F1840. Here is how the pins were assigned:

MCLR had the usual 10k pull-up and there was decoupling across the power pins. Signal generator was an Asian-branded, dual channel, DDS device. Mode was square wave with 95% duty cycle at various frequencies. Internal oscillator was used at 4 MHz.

My code is attached (GIE Test.zip).

I could not duplicate the GIE problem. Here is one image of the output taken with a 1 kHz stimulus:


Probe_4: LED3 showing normal ISR operation
Probe_3: Stimulus
Probe_2: LED2 showing normal loop (Start --> bra Start) operation
Probe_1: LED1 -- monitors loop created when GIE "problem" exists (theoretical)

Here is a capture with a 2 kHz stimulus and a slower sweep:

I have never observed anything in Probe_1. This morning, I set the 'scope to trigger once on Probe_1 rising edge, and there is nothing after two hours.

Without a positive control, i.e., one of the very early 16Cxx chips (no suffix) or another chip known to show the problem, one can't conclude whether this test would have detected the GIE problem if it existed. Unfortunately, no reputable source currently sells those chips. They are listed on eBay, but those chips don't have a Microchip pedigree. Nevertheless, the evidence -- including the Hi-Tech link and its references -- are consistent with a conclusion that the problem was solved by Microchip last century.

Regards, John

 

Is this concerning the EEPROM saving issue ?

 

That's the main reason I started a new thread. Yes, it is related to the EEPROM write routine as parts of that routine can be corrupted by an interrupt. Thus, one usually turns off the interrupts before writing. That is where the issue came to light for us newbies. (I had never read a 16F84 datasheet, much less a 16C84 datasheet before JohninTx pointed it out.) However, it applies to any routine that is not immune to interrupts and for which one usually disables interrupts.

John

 

John,
How early do you want? I have lots that are days away from the dumpster.

 

The chips for which the problem is clearly admitted to exist by Microchip are the 16C73 and 74. 16C71 may also be in that group (see: DS30390D, page 133 and DS30390E,page 141). DS31008A, page 8 muddies the waters a bit and is vague about the scope of applicability. I think the 16C73/74 (without suffix) are probably the best examples. The 16C71 would be OK.

Today, I was going through my old collection and found a few, never used 12C672 and 16C54 (both windowed and non-windowed versions). My excitement was short lived, though. Several years ago I moved to the ICD3 for newer chips and gave my PICStart Plus to Roman Black based on the false assumption the ICD3 could do all of the old and current chips. Well, it won't do any of those old chips. Neither will the PK3. They require the PICStart or some other programmer. Aside from the problem with my programmers, as best I can tell MPLab 8.92 will not do the 16C73 or 74. It will do the 16C71. I have no idea whether MPLab X will do any of those chips.

In conclusion, I am not able to program any of the chips known to have the problem. Solving the PICStart/ICD-3 problem is probably easier than solving the software problem. You may want to keep a couple of 73/74 chips, in case someone wants to follow up with them and has the software to do it. Until I move to the new development suite (assuming it will program those old chips), the only chip I would be interested in is a 16C71.

As a slight addendum, I cleaned up the program a little, got rid of most of the NOP's so the relative exposure of the bcf GIE step would be increased, and decreased the chip's frequency to 125 kHz so my stimulus generator could test at a higher rate relative to the chip's Tcy. It ran most of the day on the 12F1840 without a glitch.

Regards, John

 

Not related but I could not help it.
When both of you say John....we know in this thread it's either of you referring to each other.
I need to type in your user name to point out which John I am referring to in my thread

 

One is in Texas; the other in a farm...!

 

A

The chips for which the problem is clearly admitted to exist by Microchip are the 16C73 and 74. 16C71 may also be in that group (see: DS30390D, page 133 and DS30390E,page 141). DS31008A, page 8 muddies the waters a bit and is vague about the scope of applicability. I think the 16C73/74 (without suffix) are probably the best examples. The 16C71 would be OK.

Today, I was going through my old collection and found a few, never used 12C672 and 16C54 (both windowed and non-windowed versions). My excitement was short lived, though. Several years ago I moved to the ICD3 for newer chips and gave my PICStart Plus to Roman Black based on the false assumption the ICD3 could do all of the old and current chips. Well, it won't do any of those old chips. Neither will the PK3. They require the PICStart or some other programmer. Aside from the problem with my programmers, as best I can tell MPLab 8.92 will not do the 16C73 or 74. It will do the 16C71. I have no idea whether MPLab X will do any of those chips.

In conclusion, I am not able to program any of the chips known to have the problem. Solving the PICStart/ICD-3 problem is probably easier than solving the software problem. You may want to keep a couple of 73/74 chips, in case someone wants to follow up with them and has the software to do it. Until I move to the new development suite (assuming it will program those old chips), the only chip I would be interested in is a 16C71.

As a slight addendum, I cleaned up the program a little, got rid of most of the NOP's so the relative exposure of the bcf GIE step would be increased, and decreased the chip's frequency to 125 kHz so my stimulus generator could test at a higher rate relative to the chip's Tcy. It ran most of the day on the 12F1840 without a glitch.

Regards, John

I recall doing all my learning with the 16C57 (eldest brother of the 54, IIRC) using the programmer whose name ended with "B". Not sure, but I suspect the 16C57 would not work with a Picstart Plus out of the box.

 

I don't believe the 16C5x chips had interrupts. That squashed any plan to use my 16C54.

Anyway, getting a "universal" programmer (DV007004) for the affected chips is about $895 for the base unit plus $200 for an adapter plug, and that assumes the IDE being used supports the chips. Finding exactly what chips are supported by a particular IDE without installing it is not easy. I found a Microchip page what had a link to such a list for MPLab X, but the link had been moved. If JohninTX has a 16C71, then presumably all I need to do is find someone with a PICStart Plus to burn my program to it. That also assumes the updated software for the PICStart will recognize and program that chip. Lots of if's.

John

 

Well, I just bought a couple of 16C71's from a USA source at an outrageous price ($2 each). At least, the MCC datasheet still has the warning about GIE.

I no longer have a PICStart Plus programmer. Anyone in the Cleveland area or elsewhere with a PICStart Plus or Universal Programmer willing to burn my code to them? Return postage will be pre-paid.

John

 

BEATING A DEAD ZEBRA


Since my last post on this subject, I have tried to get a 12F683 or 12F1840 to show the GIE glitch (GIE error) without success. The parts I needed to test a chip (16C71) that is known to exhibit that glitch arrived Wednesday. In brief, one can easily make the 16C71 demonstrate the glitch. The same method does not cause a glitch with the 12F683 or 12F1840, even when the latter are monitored for hours.

Design
In my testing scheme for a device, two programs are needed, Stimulus and DUT. Several minor changes were made in the past two weeks to both program types that are not worth describing. I have attached the current DUT programs for both the 12F1840 and 16C71. Note in particular these additional comments on the instructions after "Start" in the DUT programs:

Start
  bsf      INTCON,GIE ;Enables interrupt from a falling edge on the INT pin.
  bcf      DUT_RDY    ;This is a signal to the Stimulus PIC to start timing.  DUT_RDY (DUT ready) idles    ;high, and the Stimulus chip responds to the falling edge of that signal by sending    ;an interrupt signal to DUT. 
  bsf      DUT_RDY    ;This gives a 32-us lapse before GIE is cleared.  That allows time for Stimulus to    ;react and to begin  pulsing the interrupt pin before the "bcf GIE" instruction.  
  bcf      INTCON,GIE
  btfss    INTCON,GIE ;Begins an instruction sequence to test for and report an error.

Since the 16C71 does not have a built-in oscillator, I used the Reference Clock function of the Stimulus PIC as an external clock for all DUT's. Stimulus runs at 4 MHz. Reference Clock is set to 1:32, which gives 125 kHz as Fosc for the DUT (32 us per Tcy). I used such a slow clock for the DUT to give Stimulus ample time to bang away at the "bcf GIE" instruction to elicit the glitch. Both of the DUT programs are given because of different configurations that have to be set and small differences in the instruction sets. In brief, the code provides that when the GIE error occurs and the program proceeds past the interrupt with GIE incorrectly set, a flag bit is set for about 17 Tcy (544 us). That long delay made the pulse obvious and distinct from a noise blip regardless of the scan rate used and frequency with which the error occurred. As it turned out, when the error occurred, it was very reproducible and not at all sporadic.

Stimulus Code Discussion
The Stimulus program (12F1840 chip) was a little more interesting to manipulate. Initially, as noted above, I just used an independent frequency source to pulse the interrupt pin of the DUT. The DUT has housekeeping to perform between critical "bcf GIE" instructions. Multiple interrupts during that time gave a messy scope result to interpret. Using a second, Stimulus chip allowed quasi-synchronization so the interrupts could be set to occur slightly before, during, and slightly after the "bcf GIE" instruction. The program for Stimulus is attached.

For Stimulus, "Start" begins with a delay of about 400 us so one sequence of pounding on "bcf GIE" with an interrupt doesn't overlap with the next. There is next a short delay determined by the value set with "movlw" before the interrupt pin of the DUT is toggled. As it turns out, successful demonstration of the GIE error is sensitive to that early delay.

When I was working on early versions of this program, I had yet to evoke a successful GIE error, so a lot of guess work and some code, which has since been deleted, was included to cover various eventualities. For one thing, I could not find anywhere a description of which cycle involved in executing an instruction was subject to an interrupt and caused the glitch. I did not want to "bang" multiple times during the same cycle, so I included a section of code that increased the delay for each successive test impulse to the DUT interrupt pin. That code effectively incremented the literal operand for the "movlw" instruction to allow toggling of the interrupt at any time during and even after the "bcf GIE" instruction.

The GIE error was not sensitive to that sequence of increasing delays, and I deleted that section from the version of code posted here.

Results
Several images are attached. In all images, the top trace (yellow) is for the "GIEerr" output. It idles low and an error is manifest by a positive pulse of 544 us. The subsequent three traces are in the order in which the signals occur. Trace 2 (cyan) is the DUT signal to Stimulus that it is ready (i.e., housekeeping is done). Trace 3 (magenta) is the Stimulus signal to the interrupt pin of the DUT, and Trace 4 (blue) is the interrupt toggle done during the ISR. In other words, every blue blip means the chip has entered and is in its interrupt. Since the 12F1840 never showed the problem, only one oscilloscope image from its testing is included and has a scan of 100 us/div to show the various delays (Figure 1).

The GIE error was easily demonstrated on the 16C71 chip. The literal used for setting the delay was varied between "no delay" (i.e., commented out completely), delays of 1,2, or 3 nop's (i.e., no loop was used), and literals between 2 and 13.

Delays of ≤ 2 nop's and delays with a literal of ≥ 13 did not cause the glitch. Delays between those limits did cause the glitch. In other words, a delay of at least 3 us and less than 38 us is required.* The time for the DUT to signal Stimulus, for Stimulus to react, and for DUT to recognize the interrupt signal is not included.

For the 16C71, Figure 2 the shows the GIE error scanned at 500 us/div. Note how reproducible the glitch is. Figure 3 shows a glitch at 100us/div to show relative timing. Figure 4 is from a test with "no delay"

Conclusion
The GIE error is real. It was documented by Microchip in the late 1990's to occur with just 3 chips, the 16C71 and 16C73/74. Microchip acknowledged the problem and quickly corrected it. The datasheets from that time make it clear which chips were affected, and a workaround is given for those chips. PIC16C73/74 chips with a suffix are not affected.

I have not been able to find any documented reports for other chips being affected. I let the 12F683 and 12F1840 run most of a day each in single trace mode triggered on the GIEerr signal. Nothing occurred.

Regards, John


* The loop time for each count before the branch is 3 Tcy. Branch on zero is 2 Tcy. Execution of "bcf Stimulus" is one Tcy. It is constant regardless of the delay and is not counted in my calculation of the delay.

 

@jpanhalt
Very nice work, John.