www.beck-ipc.com
www.beck-ipc.comwww.beck-ipc.com  | ImprintImprint
FAQFAQ  | SearchSearch  |
  |LoginLogin

8259 in Cascade-Mode

Questions and discussions about IPC@CHIP® hardware addons (e.g. FK61-WL01)

8259 in Cascade-Mode

Postby Thomas Wiesner » 19.09.2007, 21:31

Hello,

I tried the Hardware-Example from CASCADE (hwapiv207-examples) but with no real success.

I am using a DK50-Board with a SC13 and an additional board connected to the direct signals of the SC13 via SL3.

The 8259 can be read and written, but if an interrupt occurs, the sc13 says: "Sorry, there is an illegal call at: Int 0xFb AX=0000" for example. The answer differs especially in the presented Int-Number, mainly it is named "Int 0x30".

When not activating the INTA-Cascade and reading the ISR and IRR-Registers continously everything seems to be ok, the selected Int-Number can be correctly seen when forced.

What's wrong? I toke the exact schematic, the only thing I changed is the PCS to 5 in hard- and software.

I have also controlled the compiler options, the processor type is set to "80186" (Borland C++ V5.0), the memory model is "large".

I am wondering if the setvect-function is not really operating in the right way. Especially the case, that the normal INT0-function call (using the hal_isr in the not-cascade-mode as single external interrupt) is a huge-pointer and the setvect-function needs an interrupt-pointer makes me a little bit confused.

Has somebody tried out this construction? What do I have to change?
CU,

Thomas

Postby Andre Pribil » 20.09.2007, 08:43

Hello,

you said that you use the DK50 board. Have you removed the jumper at CTS1?
This is needed, because the pin 25 is used as INTA and the CTS1 functionality is no longer available. CTS1 must not be connected to the RS232 level shifter, else the signals will clash.

I am wondering if the setvect-function is not really operating in the right way. Especially the case, that the normal INT0-function call (using the hal_isr in the not-cascade-mode as single external interrupt) is a huge-pointer and the setvect-function needs an interrupt-pointer makes me a little bit confused.

That's ok. The cascaded interrupts are directly installed into the interrupt vector table. So the "interrupt" key word is required here. This is also the reason why a hal_give_eoi() call is needed inside these handlers.
For normal external interrupts the RTOS installs the interrupt vector table handler and gives the EOI.
The user interrupt handler is called from this RTOS handler. That's the reason why only the key word "huge" is needed here.

regards,
André Pribil
Software Development
Beck IPC GmbH

Postby Thomas Wiesner » 20.09.2007, 11:39

Hi,

TXS for the explaination of the function-call, so this can not be the problem.

I removed the jumper...... :-(. Also I tried different vector-table-adresses. But each time it has the same effect.

Maybe the type of 8259 does not fit (clock). I have a 82C59A which is for 4 MHz busclocks. There is another type for 12,5 MHz, but I have no sample of that. But then, the normal read/write-cycle would not work correct, would it? But it does ....!!!!????
CU,

Thomas

Postby Andre Pribil » 20.09.2007, 13:15

Hello,

if you expect that the timing is the problem, you could try the following things.

1) Increase the number of waitstates for the selected PCS signal. In your case use the function pfe_set_wait_states2().

2) Decrease the CPU clock. Insert these entries into your CHIP.INI configuration for 20 MHz operation

Code: Select all
[DEVICE]
POWERSAVE=2

or 10 MHz operation
Code: Select all
[DEVICE]
POWERSAVE=4


regards,
André Pribil
Software Development
Beck IPC GmbH

Postby Thomas Wiesner » 20.09.2007, 17:00

Hi Andre,

great, with POWERSAVE=2 the 8259 answers.....

But now there is another problem:

Each time an interrupt on 0 or 1 is required, the specific Int and Int7 show counts, not the same amount of requests, but nearly........... and Int7-Input is tied to GND by Hardware...........

But what ever, this should be a hardware problem.

TXS a lot for your quick and good response.
CU,

Thomas

Postby Andre Pribil » 20.09.2007, 20:06

Hello Thomas,

I guess you are currently trigger the INT lines by hand. If this is true, then you can regard the INT7 input problem as a feature. Here's a snippet from the 8259 datasheet, which explains this behaviour:

In both the edge and level triggered modes the IR inputs
must remain high until after the falling edge of the first INTA.
If the IR input goes low before this time a DEFAULT lR7 will
occur when the CPU acknowledges the interrupt. This can
be a useful safeguard for detecting interrupts caused by
spurious noise glitches on the IR inputs. To implement this
feature the lR7 routine is used for “clean up” simply
executing a return instruction, thus, ignoring the interrupt. If
lR7 is needed for other purposes a default lR7 can still be
detected by reading the ISR. A normal lR7 interrupt will set
the corresponding ISR bit, a default IR7 won’t. If a default
IR7 routine occurs during a normal lR7 routine, however, the
ISR will remain set. In this case it is necessary to keep track
of whether or not the IR7 routine was previously entered. If
another lR7 occurs it is a default.


regards,
André Pribil
Software Development
Beck IPC GmbH

Postby Thomas Wiesner » 27.09.2007, 19:45

Hello Andre,

yes, you are right, the Int0 is hand-triggered.

I changed the request to the Int-Output of an PCF8583 I2C-Clock and now everything is alright.

By the way, it is possible to have waitstates on the INTA? My problem was not to read and write the ports of the 8259 in fast-mode (40 MHz), the problem was the cycle of the INTA-request. This only works with 20 MHz or lower.
CU,

Thomas

Postby Muenchow » 27.09.2007, 22:54

Hello,

if the SC13 timing is equivalent to AMD processors, INTA cycle should have 3 busclocks duration. This would require the 12.5 MHz version of 82C59A. For AMD (and probably also SC13), INTA waitstates aren't programmable, INTA cycle can only be extended by deasserting READY, which isn't accessible with SC13.

Regards,
Dr. Frank v. Münchow-Pohl
Beratender Ingenieur

Return to Hardware Addons


Who is online

Users browsing this forum: No registered users and 0 guests


cron