REFERENCE THE THREAD: http://www.keil.com/forum/docs/thread11961.asp
BTW "the bible" is 20+ years old and I have yet to see someone point out an error in it. -- erik malund
The 'Bible' www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf
This looked too much like a challenge, so I had to bite on that bait.
This is almost an error. At least by an Error-by-omission in clarity... "An Error In Clarity."
"THE BIBLE" quote: [On "How Interrupts Are Handled," p16 last paragraph of hardware pdf] The polling cycle is repeated with each machine cycle, and the values polled are the values that were present at S5P2 of the previous machine cycle. Note that if an interrupt flag is active but not being responded to for one of the above conditions, if the flag is not still active when the blocking condition is removed, the denied interrupt will not be serviced. In other words, the fact that the interrupt flag was once active but not serviced is not remembered. Every polling cycle is new. [On p18 "External Interrupts" second paragraph of the hardware manual] Since the external interrupt pins are sampled once each machine cycle, an input high or low should hold for at least 12 oscillator periods to ensure sampling. If the external interrupt is transition-activated, the external source has to hold the request pin high for at least one cycle, and then hold it low for at least one cycle. This is done to ensure that the transition is seen so that interrupt request flag IEx will be set. IEx will be automatically cleared by the CPU when the service routine is called
Do you realize what that means?
I had to figure it out the hard way while using the Intel "Old-Testament" in which this point was not exactly clear and you had to read-between-the-lines [several times] in order to understand how they implemented the interrupt engine. The verbage was carefully crafted.
At least this New Testament "Bible" by Philips alludes to the core problem with the 8051 interrupt architecture's state machine.
A bit of history first: I had discovered this during a rather High Profile & High Stress $700M military contract award competition in which I had to resolve the issue ('with extreme prejudice')
if( PROBLEM != FIXED ) printf( "You owe us $700,000,000\n" ); // Stick else printf( "Dinner is on us tonight.\n" );// Carrot
I finally found it, and then called Intel and spoke with their 8051 engineers (you could actually speak to them back then). After some discussions, they verbally confirmed the problem, but would not put it in writing for the formal government Corrective Action Report. (I put this denial to-write-it-down into the official report). Intel then published the issue in their data books a year or two later.
It is clearly identified in a 1994 book I have. Subsequent MCS-51 books did start to obscure the clarity, and your New Testament 'bible' seems to have killed off the clarity almost entirely.
I have not tested this problem in all of the various vendor implementations of the Intel core, but I wouldn't doubt if many still have this inherent problem. So, beware...
By having the "S5P2" sampling the interrupt source signal and it being anew on each cycle, an EDGE-TRIGGERED interrupt signal can be ignored entirely if the MCU is currently servicing a higher-priority interrupt.
This is caused by the edge being detected in a cycle (actually its a cycle-pair where the first S5P2 samples a high, and the second S5P2 samples the low transition), but is blocked by the high-priority process.
Once it is blocked by the higher priority process (and not simply the RET/LCALL/RETI/DIV type interrupt postponers) 'detection' is essentially cleared in the following cycles because of the non-change of state between the subsequent "S5P2" samplings. Every polling cycle is new.
At least this 'bible' contains the information to derive the issue. But I still consider it an Error since they don't come right out and state what it means.
It is actually fairly easy to fix within the device, but Intel chose to modify the data-sheet instead of issuing an errata and then rev-ing the die.
So, seek your vendor specific data-sheets and not just rely on this 'bible' for all of your 8051 problems. They/we refer to the Philips NXP data-book set as "The Bible," because it is one of the most comprehensive data-books you can get online for the MCS-51 architecture.
I suspect that the single-cycle core variants have a higher probability of a fix in this area since they had to re-engineer the cycle-sampling state machine interrupt engine anyway. (for those who are doing their own 8051 cores in VHDL, you should review this portion of the controller).
In Intel info that states this issue CLEARLY (while the Philips New Testament 'Bible' does not):
From page 21 of Intel's own "83C51KB Hardware Description Addendum to the MCS-51 Microcontroller Family User's Manual" (Order Number: 272801-001 January, 1996) The polling cycle is repeated with each machine cycle, and the values polled are the values that were present at S5P2 of the previous machine cycle. If the interrupt flag for a level-sensitive external interrupt is active but not being responded to for one of the above conditions and is not still active when the blocking condition is removed, the denied interrupt will not be serviced. In other words, the fact that the interrupt flag was once active but not serviced is not remembered. Every polling cycle is new. (It is also present in ORDER NO.: 272383-002 FEBRUARY 1994)
But just remember, the "Edge-Triggered" mode is just an added feature to the MCS-51 capability and not some fundamental core [error].
--Cpt. Vince Foster c/o VRWC (founding member) 2nd Cannon Place Fort Marcy Park, VA