- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I am trying to get the INT0# to trigger on the FX2LP. I can see on an oscope that the external pin, pin 34 on CY7C68016A-56LTXC, is transitioning from high to low but my isr function does not run. INT1# is held high. Here is the code.
From bulkloop.c
// Port A Configuration
PORTACFG |= bmINT1 + bmINT0; // Enable Interrupts INT0_N (PA0) and INT1_N (PA1)
SYNCDELAY;
TCON |= 0x05; // INT0 and INT1 are configured as Edge triggered interrupt
IE |= 0x85; SYNCDELAY; // Enable global interrupts and INT0# and INT1#
OEA = 0xF4;
From another file.
void keypress_isr (void) __interrupt INT1_VECT
{
led_color_set(1,0xff,0xff,0xff);
}
Any help would be greatly appreciated.
Thanks,
Dave
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Dave,
I was able to reproduce the issue and correct the same.
Please declare the line in the fx2regs.h
__sfr __at (0x92) _XPAGE ;
after
__sfr __at (0x92) MPAGE ;
This will properly initialize the XPAGE as per the SDCC user guide.
Please confirm if this resolved the issue.
Thanks,
Yatheesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Dave,
[Updated]
I checked your code snippet by adding it to bulkloop firmware project (TD_init) and toggling a pin in the ISR, and its working fine.
interrupt 0 ,interrupt 2 , interrupt 10, interrupt 11 , interrupt 12 tells the compiler to look for the ISR at address 0x0003,0x0013,
0x0053 ,0x005B,0x0063 respectively . Refer to Table 4-1. EZ-USB Interrupts in EZ-USB Technical Reference Manual.
The numbers 10,11 ,12 are derived from the natural priority of the interrupt for INT4/5/6
When the ISR is declared in a different file, for example ISR for INT1# interrupt i.e natural priority 3 as per the interrupt table mapped to interrupt number 2 (0x0013) , please declare the ISR as below
void external_int_1(void) interrupt 2 // natural priority 3
{
TCON &= 0xF7; // Clear INT1 TCON.3 Flag . This is also automatically cleared by hardware.
toggle();
}
Also, make sure that the higher priority ISR is declared in the same file even if they are not used. This is to clear the higher priority interrupt when it occurs.
for example: INT0# is not used: isr.c file
#include <stdio.h>
#include "fx2.h"
#include "fx2regs.h"
#include "syncdly.h"
void toggle(void);
void external_int_0 (void) interrupt 0 // for INT0#
{
// clears INT0# interrupt
}
void external_int_1 (void) interrupt 2 // for INT1#
{
TCON &= 0xF7; // Clear INT1 TCON.3 Flag . This is also automatically cleared by hardware.
toggle();
}
void toggle (void)
{
IOB ^= 0xFF;
SYNCDELAY;
IOB ^= 0xFF;
}
Thanks,
Yatheesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Yatheesh,
I do have the other priority interrupt, int0#, in the same file as int1#. I am using the sdcc compiler and found in the User Guide that there MUST be a prototype of the isr in the same file that has the main function. That didn't help though. Where can I look to see if the isr address is being written to the interrupt vector table?
Thanks,
Dave
UPDATE:
I found that by adding the .h file to fw.c where the main function is does add the isr function to the interrupt vector table. Line 7 and 11 below show the two added isr functions.
Function keypress_isr is still not running when the external int#1 pin is transitioned from high to low.
828 ;--------------------------------------------------------
829 ; interrupt vector
830 ;--------------------------------------------------------
831 .area HOME (CODE)
000000 832 __interrupt_vect:
000000 02r00r00 [24] 833 ljmp __sdcc_gsinit_startup
000003 02r00r00 [24] 834 ljmp _rotary_isr
000006 835 .ds 5
00000B 32 [24] 836 reti
00000C 837 .ds 7
000013 02r00r00 [24] 838 ljmp _keypress_isr
000016 839 .ds 5
00001B 32 [24] 840 reti
00001C 841 .ds 7
000023 32 [24] 842 reti
000024 843 .ds 7
00002B 32 [24] 844 reti
00002C 845 .ds 7
000033 02r04rD3 [24] 846 ljmp _resume_isr
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Dave,
Can you please try toggling a Port pin directly in the keypress_isr() and check if its a success?
This is to check if the PC is executing the ISR.
Thanks,
Yatheesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Yatheesh,
I have confirmed that adding a gpio toggle to the keypress_isr() function does not work. I did confirm that I can toggle the same gpio pin from another function.
This is the code I used.
void keypress_isr (void) __interrupt 2
{
PB3 ^= 0x01;
}
Thanks,
Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Dave,
The ISR function call address is being overlapped and can be seen in your fw.rst file.
In the interrupt vector table, all the ISR functions have the same address 02r00r00.
Please follow the below steps:
1. Create a new isr.c file and declare the ISR's for the respective Interrupts INT0 and INT1 with interrupt number INT0_VECT and INT1_VECT respectively.
Refer to the attached isr.c and isr.h files.
2. Create a isr.h file define the prototypes of functions present in isr.c file.
3. Add the reference to isr.h file in both isr.c and fw.h files.
4. Build the project. Check the interrupt vector table in the fw.rst file.
It will be similar to the below. The address corresponding to the ISR calls should be different and should match with the address of the ISR functions in isr.rst file.
Fw.rst file:
828 ;--------------------------------------------------------
829 ; interrupt vector
830 ;--------------------------------------------------------
831 .area HOME (CODE)
000000 832 __interrupt_vect:
000000 02 00 6F [24] 833 ljmp __sdcc_gsinit_startup
000003 02 0E 1C [24] 834 ljmp _external_int_0
000006 835 .ds 5
00000B 32 [24] 836 reti
00000C 837 .ds 7
000013 02 0E 3A [24] 838 ljmp _external_int_1
000016 839 .ds 5
00001B 32 [24] 840 reti
00001C 841 .ds 7
000023 32 [24] 842 reti
000024 843 .ds 7
00002B 32 [24] 844 reti
00002C 845 .ds 7
000033 02 0B 92 [24] 846 ljmp _resume_isr
isr.rst file
000E1C 833 _external_int_0:
000E1C C0 07 [24] 834 push ar7
000E1E C0 06 [24] 835 push ar6
000E20 C0 D0 [24] 836 push psw
000E22 75 D0 00 [24] 837 mov psw,#0x00
000E3A 865 _external_int_1:
000E3A C0 21 [24] 866 push bits
000E3C C0 E0 [24] 867 push acc
000E3E C0 F0 [24] 868 push b
000E40 C0 82 [24] 869 push dpl
You can see that the 0E 1C and 0E 3A are the address of the ISRs and matches with the call address in the fw.rst file.
I have verified the interrupt operation using the attached files.
Please try it on your side.
Thanks,
Yatheesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Yatheesh,
I think what I sent earlier was not from the fw.rst but instead from the fw.lst. I tried your code and I got the same thing only because I was looking at the fw.lst file. When I looked at the fw.rst file I got the following.
828 ;--------------------------------------------------------
829 ; interrupt vector
830 ;--------------------------------------------------------
831 .area HOME (CODE)
000000 832 __interrupt_vect:
000000 02 00 6F [24] 833 ljmp __sdcc_gsinit_startup
000003 02 0F 7C [24] 834 ljmp _external_int_0
000006 835 .ds 5
00000B 32 [24] 836 reti
00000C 837 .ds 7
000013 02 0F 93 [24] 838 ljmp _external_int_1
000016 839 .ds 5
00001B 32 [24] 840 reti
00001C 841 .ds 7
000023 32 [24] 842 reti
000024 843 .ds 7
00002B 32 [24] 844 reti
00002C 845 .ds 7
000033 02 0B 92 [24] 846 ljmp _resume_isr
I then backed out your code and tried the original code and got this from the fw.rst.
828 ;--------------------------------------------------------
829 ; interrupt vector
830 ;--------------------------------------------------------
831 .area HOME (CODE)
000000 832 __interrupt_vect:
000000 02 00 6F [24] 833 ljmp __sdcc_gsinit_startup
000003 02 13 94 [24] 834 ljmp _rotary_isr
000006 835 .ds 5
00000B 32 [24] 836 reti
00000C 837 .ds 7
000013 02 13 D3 [24] 838 ljmp _keypress_isr
000016 839 .ds 5
00001B 32 [24] 840 reti
00001C 841 .ds 7
000023 32 [24] 842 reti
000024 843 .ds 7
00002B 32 [24] 844 reti
00002C 845 .ds 7
000033 02 0B 92 [24] 846 ljmp _resume_isr
Here is the keypress_isr assembly.
0013D3 1125 _keypress_isr:
0013D3 C0 21 [24] 1126 push bits
0013D5 C0 E0 [24] 1127 push acc
0013D7 C0 F0 [24] 1128 push b
0013D9 C0 82 [24] 1129 push dpl
0013DB C0 83 [24] 1130 push dph
It looks like jump addresses are being inserted correctly but the isr still does not run. I wonder what could be preventing it from running.
Thanks,
Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Dave,
Can you please confirm if the device is bound to the cyusb3 driver version 1.2.3.20?
Th driver can be found in the FX3 SDK for windows.
https://www.cypress.com/documentation/software-and-drivers/ez-usb-fx3-software-development-kit
Thanks,
Yatheesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ystheesh,
It looks like it is bound to that driver.
Thanks,
Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Dave,
Please share your project so that we can proceed to find the root cause for the issue.
Thanks,
Yatheesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Dave,
I tried your firmware and was able to reproduce the issue.
Root Cause: Memory overlap of __xdata variables with the interrupt vector table.
Solution: Wherever variables are declared as __xdata, please provide an absolute address to the xdata variables using the __at () keyword including the fx2lpi2c.c file.
You can refer to the SDCC compiler user guide: http://sdcc.sourceforge.net/doc/sdccman.pdf for the use of __at keyword.
Please make sure that the assigned absolute address to the variables should not overlap with the code area.
Let me know if this solves the issue.
Thanks,
Yatheesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Yatheesh,
I will try this out. How do I find where _xdata starts? Also, I have some variables declared as _code. I wonder if I change the _xdata variables to _code if that will work.
Thanks,
Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Yatheesh,
I cannot figure this out. Please help. I am not a software engineer by training but I though this would be a fun project. Any help would be greatly appreciated.
Thanks,
Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Dave,
Please follow the below steps to Relocate all the xdata variables (xdata range) in your project:
Right click on project in eclipse -> Properties -> C/C++ Build -> Settings -> SDCC Linker
In the Command text box , next to sdcc add "--xram-loc 0x3000" (without quotes)
Click Apply and then OK.
Build the project and check for interrupts.
This will start the XSEG from address 0x3000, so that it will not overlap with the code area.
Please make sure that the code area will not exceed a certain limit and overlap with the xdata area.
This can be done by using --code-size <maximum size limit of code> in the linker command box.
When the code area exceeds the maximum limit, Linker Error will be generated while building the project.
Thanks,
Yatheesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Dave,
I was able to reproduce the issue and correct the same.
Please declare the line in the fx2regs.h
__sfr __at (0x92) _XPAGE ;
after
__sfr __at (0x92) MPAGE ;
This will properly initialize the XPAGE as per the SDCC user guide.
Please confirm if this resolved the issue.
Thanks,
Yatheesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Yatheesh,
It works! Thanks so much.
I am toggling the PB3 line in the isr. If I add the function after the function led_color_set(1,0xff,0xff,0xff); execution seems to freeze.
Thanks,
Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Dave,
This maybe due to the I2C write/read functions.
Thanks,
Yatheesh