FX2 interrupt mixed?

- M
- Michael Bahrs
  
  Contact options for registered users
posted
19 years ago

Wed, Jul 28, 2004 7:30 AM

Hi everybody

I have a strange problem with a cypress FX2. I want to work with timers and external events on INT0 and INT1 Pin. (I want to measure the time beween an event on INT0 and INT1). Everything works fine except I get the interrupts IE0, TF0, IE1 and TF1 alltogether on interrupt vector 0x1b (normally only TF1).

If I use 'interrupt 3' everthing works fine. I can enable/disable Timer0 and/or Timer1 and I get the expected result but only on interrupt 3. The same with INT0 and INT1. I get the events but on interrupt 3.

What's wrong?

When I check main.lst everything seems to be ok: 0000 630 __interrupt_vect: 0000 02s00r00 631 ljmp __sdcc_gsinit_startup 0003 32 632 reti 0004 633 .ds 7 000B 32 634 reti 000C 635 .ds 7 0013 32 636 reti 0014 637 .ds 7 001B 02s01r53 638 ljmp _isr01 001E 639 .ds 5 0023 32 640 reti 0024 641 .ds 7 002B 32 642 reti 002C 643 .ds 7 0033 32 644 reti 0034 645 .ds 7 003B 32 646 reti 003C 647 .ds 7 0043 02s00r00 648 ljmp _autovector_jump_table_usb 0046 649 .ds 5 004B 32 650 reti 004C 651 .ds 7 0053 02s00r00 652 ljmp _autovector_jump_table_gpif

How can I get Interrupts on other vectors than 0x1B. Or is it a hardware problem? The autovector interrupts work fine.

BTW I use sdcc 2.4.

I hope someone can give me some hints.

Michael Bahrs

- M
- Martin Walton
  
  Contact options for registered users
Vote on answer
posted
19 years ago

Wed, Jul 28, 2004 11:37 AM

Thats very interesting, I'm currently working with EZUSB FX (not 2) and I'm having great trouble trying to get #INT0 working. I'm using it in level sensitive mode, and I can see IE0 in the TCON register changing state when I change the pin state, and my interrupt mask is correct, but the service routine never gets called. Whats even stranger is that sometimes the value of IE gets changed at this point, such that other interrupts, like the timer, which were previously working stop functioning. I've also seen the PC go off into space at this point as well.

I'm also using SDCC, and as far as I can tell, the code its generating is correct - there is an ljmp at the vector (0x0003) which points to my service routine. I've done all this before on the standard EZUSB (AN2131) and its worked perfectly.

I've not really had much help from Cypress so far, who keep suggesting that I'm not using the 'keil' compiler correctly!

There is also a post on their support site that suggests that other people have seen a similar bug - Article 16525, but it has no fix or work-around.

Regards

Martin

- M
- Mark A. Odell
  
  Contact options for registered users
Vote on answer
posted
19 years ago

Wed, Jul 28, 2004 2:06 PM

Martin Walton wrote in news:ce835a$6b3$1$ snipped-for-privacy@news.demon.co.uk:

I've seen this behavior with 8051's when an ISR is returned from via a ret or jmp instead of an iret. I discovered this trying to "reset" my CPU by jumping to 0x0000 from an external interrupt ISR. Problem was, after that, no more interrupts get serviced. Try and see if there is any way that you might be exiting an ISR without an iret.

--
- Mark ->
--

- J
- Jim Granville
  
  Contact options for registered users
Vote on answer
posted
19 years ago

Thu, Jul 29, 2004 12:39 AM

Sometimes a debug system can fight for interrupt resource?

The 80C51 has 8 bytes for each INT vector, so a simple way to verify INT vector entry, is to allocate a FLAG byte, and code to set that on the first opcode. ( or it can even be a port pin ) Later debug-break can safely inspect that collection of flags, to see what occured.

Start with the simplest code, and work upwards.

ORG 0003H SETB BitTrackVariable.0 ; Catch expected vector LJMP Vector0003Name ORG 000BH SETB BitTrackVariable.1 ; Catch/flag an unexpected vector RETI .. etc for ALL vectors.