cancel
Showing results for 
Search instead for 
Did you mean: 

USB Low-Full-High Speed Peripherals

DaWi_3430881
New Contributor II

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

0 Likes
1 Solution
YatheeshD_36
Moderator
Moderator

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

View solution in original post

0 Likes
18 Replies
YatheeshD_36
Moderator
Moderator

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

0 Likes
DaWi_3430881
New Contributor II

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

0 Likes
YatheeshD_36
Moderator
Moderator

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

0 Likes
DaWi_3430881
New Contributor II

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

0 Likes
YatheeshD_36
Moderator
Moderator

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

0 Likes
DaWi_3430881
New Contributor II

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

0 Likes
YatheeshD_36
Moderator
Moderator

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

0 Likes
DaWi_3430881
New Contributor II

Ystheesh,

It looks like it is bound to that driver.

2020-07-28 09_32_57-Cypress FX2LP Sample Device Properties.png

Thanks,

Dave

0 Likes
YatheeshD_36
Moderator
Moderator

Hello Dave,

Please share your project so that we can proceed to find the root cause for the issue.

Thanks,

Yatheesh

0 Likes
DaWi_3430881
New Contributor II

Hi Yatheesh,

  I have attached my project. Thank you for your assistance, it is greatly appreciated.

Thanks,

Dave

Yatheesh

0 Likes
YatheeshD_36
Moderator
Moderator

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

0 Likes
DaWi_3430881
New Contributor II

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

0 Likes
DaWi_3430881
New Contributor II

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

0 Likes
YatheeshD_36
Moderator
Moderator

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.

pastedImage_0.pngpastedImage_1.png

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.

pastedImage_2.pngpastedImage_17.png

When the code area exceeds the maximum limit, Linker Error will be generated while building the project.

Thanks,

Yatheesh

0 Likes
DaWi_3430881
New Contributor II

Hi Yatheesh,

  I implemented your suggestions and the isr is still not running. This is so strange. I have attached my project if you want to take a look.

Thanks,

Dave

0 Likes
YatheeshD_36
Moderator
Moderator

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

View solution in original post

0 Likes
DaWi_3430881
New Contributor II

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

0 Likes
YatheeshD_36
Moderator
Moderator

Hello Dave,

This maybe due to the I2C write/read functions.

Thanks,

Yatheesh

0 Likes