Maker Pro
Maker Pro

MC6802 IRQ Pulse

Danno

Aug 31, 2015
65
Joined
Aug 31, 2015
Messages
65
On some boards I am looking at there is a 555 timer pulsing the IRQ pin of the 6802, why would you want to pulse it rather than just hold it high?
The pulse is about 10ms.

Thanks
 

(*steve*)

¡sǝpodᴉʇuɐ ǝɥʇ ɹɐǝɥd
Moderator
Jan 21, 2010
25,510
Joined
Jan 21, 2010
Messages
25,510
perhaps you want a regular interrupt?
 

AnalogKid

Jun 10, 2015
2,915
Joined
Jun 10, 2015
Messages
2,915
This is called a watchdog timer. If the application firmware gets locked up in a loop somewhere, yanking the processor into an interrupt service routine gives it a chance to examine itself to see if that is happening and take steps to correct the situation. Many newer microcontrollers have this function built in.

ak
 

Danno

Aug 31, 2015
65
Joined
Aug 31, 2015
Messages
65
This is called a watchdog timer. If the application firmware gets locked up in a loop somewhere, yanking the processor into an interrupt service routine gives it a chance to examine itself to see if that is happening and take steps to correct the situation. Many newer microcontrollers have this function built in.

ak


Ah watchdog, ok.

So the timer pulses the IRQ every 80ms (not 10 as above), assuming it hasn’t been masked in software it will jump to the IRQ vector address, perform whatever routine is called then return to normal program?

By looking at the ROMS the reset vector and the IRQ vector both point to address 7800h, so if the IRQ is called it effectively resets the system.

Still a bit confused about the pulsing though, wont it cause a IRQ every 80ms??

Thanks
 

Minder

Apr 24, 2015
3,479
Joined
Apr 24, 2015
Messages
3,479
Generally on a watchdog timer a pulse constantly resets the timer, if the device or system is healthy the timer does not time out and indicate an alarm.
If the source of the pulse fails, then the timer times out and flags an alarm or other function.
M..
 

Danno

Aug 31, 2015
65
Joined
Aug 31, 2015
Messages
65
There isn't a pulse resetting the timer, it is connected direct to the system 5v, schematic is attached, or do you mean it resets via the threshold pin?

Thanks
 

Attachments

  • Snap 2015-09-21 at 16.32.44.png
    Snap 2015-09-21 at 16.32.44.png
    242.9 KB · Views: 149

Minder

Apr 24, 2015
3,479
Joined
Apr 24, 2015
Messages
3,479
The method have used is essentially a missing pulse detector and the trigger input receives the pulses and keeps resetting the 555, if no pulse then it times out and the output changes.
M.
 

AnalogKid

Jun 10, 2015
2,915
Joined
Jun 10, 2015
Messages
2,915
It depends on what the uC is doing. One possibility is that the WDT causes a full reset every 80 ms. I agree it seems awfully short, but can't say without knowing what the application is. Another option is that the WDT ISR is very short - all it does is reset an internal counter. Then, internally, if that counter reaches a much higher number, a software test or interrupt sends the uC into a routine or function or whatever. The schematic looks like the WDT was added later to correct something, so maybe the 80 ms comes from using R and C values already on the BOM for the board rather than from a specific timing requirement.

ak
 

Danno

Aug 31, 2015
65
Joined
Aug 31, 2015
Messages
65
It depends on what the uC is doing. One possibility is that the WDT causes a full reset every 80 ms. I agree it seems awfully short, but can't say without knowing what the application is. Another option is that the WDT ISR is very short - all it does is reset an internal counter. Then, internally, if that counter reaches a much higher number, a software test or interrupt sends the uC into a routine or function or whatever. The schematic looks like the WDT was added later to correct something, so maybe the 80 ms comes from using R and C values already on the BOM for the board rather than from a specific timing requirement.

ak

The application is a fruit machine (slot machine or one arm bandit) so unlikely it does a reset every 80ms, I'm sure its not an add in either.
 

hevans1944

Hop - AC8NS
Jun 21, 2012
4,889
Joined
Jun 21, 2012
Messages
4,889
IRQ is a maskable interrupt, and the default state after a processor reset is to disable IRQ. So, just because it is being asserted every 80 ms or so does not mean the 6802 firmware is paying any attention to it. Your will have to disassemble the firmware code to determine when and why IRQ is enabled to determine why it is being pulsed on a regular, asynchronous, basis from a not-very-stable 555 timer. My guess is it is a fail-safe or watch-dog function of some sort, but you need to examine the interrupt service routine instructions if you want to find out what is going on.
 

Danno

Aug 31, 2015
65
Joined
Aug 31, 2015
Messages
65
IRQ is a maskable interrupt, and the default state after a processor reset is to disable IRQ. So, just because it is being asserted every 80 ms or so does not mean the 6802 firmware is paying any attention to it. Your will have to disassemble the firmware code to determine when and why IRQ is enabled to determine why it is being pulsed on a regular, asynchronous, basis from a not-very-stable 555 timer. My guess is it is a fail-safe or watch-dog function of some sort, but you need to examine the interrupt service routine instructions if you want to find out what is going on.

Ah I see, so the IRQ is masked automatically after power on reset, so I will need to look for a CLI instruction in the code?
 
Last edited:

hevans1944

Hop - AC8NS
Jun 21, 2012
4,889
Joined
Jun 21, 2012
Messages
4,889
Or it starts keypress scan?
That would be a good use for a periodic interrupt too, but we need to see some disassembled code at the ISR vector to get any further.
Ah I see, so the IRQ is masked automatically after power on reset, so I will need to look for a CLI instruction in the code?
Not necessarily. I am not that familiar with the 6802 microprocessor. This product was introduced late in the last century, and not by Intel whose products I am familiar with. This μP automagically clears and disables interrupts when an unmasked or enabled interrupt is serviced, obviating the need for a CLI instruction. However, the IRQ input, being an active-low level-triggered interrupt can be "wire ORed" with multiple interrupting devices. This allows the ISR to determine which device caused the interrupt and possibly rank them by priority, allowing another device to assert an interrupt by issuing a CLI instruction during the ISR. This is tricky business, stacking and prioritizing interrupts, probably a remnant from minicomputer architectures which early μPs attempted (and eventually succeeded) to replace. This is not the case where you are concerned as your schematic shows only one device, the output of the 555 oscillator, connected to the maskable IRQ input.

Here is a flow chart showing how IRQ interrupts are serviced:

upload_2015-9-22_12-43-35.png
Note that the interrupt is serviced only if the Im mask bit is cleared, and if the bit is cleared it is immediately set after saving the MPU status on the stack. This allows the ISR to continue without interruption, if desired. Later, an RTI instruction pops the previous status wherein the Im mask bit is cleared and the program continues from where it was interrupted. Notice that a CLI instruction is not necessary in this instance. OTOH, if multiple devices can assert IRQ by pulling it low, the ISR can issue a CLI instruction to allow those devices to be serviced on a priority basis, thus nesting the ISRs. Clearly this is not happening here, and the details are beyond the scope of the original question.

The above snippet is taken from a PDF file describing assembler programming for the 6802.

This is all "down in the noise" concerning what the IRQ pulses are doing. Post some dis-assembled code to show what is going on if and when the interrupt is enabled and serviced.
 

JWHassler

Dec 22, 2014
86
Joined
Dec 22, 2014
Messages
86
The 555 is (re-)triggered every time a Valid Memory Address appears on the address-bus.
If valid addresses are absent for 80 mSec, meaning the CPU is stalled, the IRQ is tripped.
I think.
 

hevans1944

Hop - AC8NS
Jun 21, 2012
4,889
Joined
Jun 21, 2012
Messages
4,889
The 555 is (re-)triggered every time a Valid Memory Address appears on the address-bus.
If valid addresses are absent for 80 mSec, meaning the CPU is stalled, the IRQ is tripped.
I think.
The only (partial) schematic I have seen appeared in post #7. It shows the 555 connected as a free-running astable oscillator with its output on pin 3 connected to the active-low IRQ input on pin 4 of the 6802. What does a Valid Memory Address have to do with the 555?
 

Danno

Aug 31, 2015
65
Joined
Aug 31, 2015
Messages
65
The 555 is (re-)triggered every time a Valid Memory Address appears on the address-bus.
If valid addresses are absent for 80 mSec, meaning the CPU is stalled, the IRQ is tripped.
I think.

I don't see how, the only place the VMA goes is to the strobe input of a 74154 decoder. The 555 timer is self re-setting.
 

Danno

Aug 31, 2015
65
Joined
Aug 31, 2015
Messages
65
That would be a good use for a periodic interrupt too, but we need to see some disassembled code at the ISR vector to get any further.

Post some dis-assembled code to show what is going on if and when the interrupt is enabled and serviced.

I'll post up some code over the weekend.
 

Danno

Aug 31, 2015
65
Joined
Aug 31, 2015
Messages
65
Managed to do some ROMS, there are 4 system ROMS, VES-D is the highest in memory and the IRQ vector is at address 0x7FF8. The system only uses 15 of the address lines hence why it's not 0xFFF8.

All pretty much double dutch to me but see what you guys think.

Thanks
 

Attachments

  • ves-a.pdf
    78.4 KB · Views: 86
  • ves-b.pdf
    74.4 KB · Views: 86
  • ves-c.pdf
    71.8 KB · Views: 104
  • ves-d.pdf
    44.2 KB · Views: 78

Danno

Aug 31, 2015
65
Joined
Aug 31, 2015
Messages
65
Another example set, two ROMS this time, FC2 is the highest and holds the reset vector.

Thanks
 

Attachments

  • fc1.pdf
    74.1 KB · Views: 91
  • fc2.pdf
    68.9 KB · Views: 99
Top