MC6802 IRQ Pulse

[Danno]

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*)]

perhaps you want a regular interrupt?

 

[Danno]

perhaps you want a regular interrupt?

What do you define as regular interrupt please?

 

[AnalogKid]

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]

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]

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]

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

 

[Minder]

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]

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]

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]

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.

 

[GPG]

Or it starts keypress scan?

 

[Danno]

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?

 

[hevans1944]

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:


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]

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]

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]

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]

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]

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

 

[Danno]

Another example set, two ROMS this time, FC2 is the highest and holds the reset vector.

Thanks