Interrupt no. for Bulk EndPoint 2 for CY7C64613

I have written a firmware to download bulk data from my pc to an onboard flash which is interfaced using a cypress EzUSB-Fx chip(CY7C64613). I am using bulk endpoint 2 to send the 64 byte packets from the pc to the board.

As soon as I setup up 64 bytes in the OUT2BUF on the host (PC) and set OUT2BC to 64, an interrupt is supposed to be raised, and my firmware has to enter the Interrupt Service Routine(ISR), from the while(1) loop where it indefinitely waits.
The Keil C51 allows a function to be declared as an ISR using the 'interrupt' keyword along with the interrupt no. (in the range from 0 to 31) for which it is meant. I am unable to find what this interrupt no. would be for Bulk endpoint 2 (i.e. EP2OUT). The vector address for EP2OUT as per the datasheet is Ox2C while the "ezusb.h" header file contains the following line:
#define OUT2BUF_USBVECT (11 << 2)
usage of which gives an error at compile time.

The Keil Application Note 103 which is supposed to talk abt 8051 interrupt vectors does provide these nos. but none of them corresponds to vector address 0x002C.

Does anyone have any idea about this?
Thanks in anticipation.

Parents
  • Ashish,

    Something about your message seems confused. The 8051 architecture has interrupt vectors starting at code address 0x0003 and reserving 8-bytes of code space for each vector. This puts the closest vector location to 0x2C beginning at 0x002B (interrupt 5). Thus, there's no way to use the interrupt keyword to define an interrupt in Keil that's located at that location. I'm not sure, but the compiler might not complain if you manually location something there to jump to your actual ISR.

    What I suspect more, however, is that you've got something confused and this isn't where your processor will actually vector when this event occurs.

    Taking a moment to refer to the datasheet, I can see that you've got things really messed up with regard to the way interrupts on this chip work. This chip has ONE USB interrupt for all of these various "endpoints" and then an "autovectoring" function to unload some work from the processor. This 0x2C offset you mention is in a table that you have to setup on some page boundary. So... the interrupt function you actually have to write is interrupt number 8 as far as Keil's concerned. If you have the autovector function enabled and some byte offset loaded into the buffer, then it will translate the LJMP instruction in interrupt 8 in a manner that sends you to this jump table you've created on some page. That's where the offset 0x2C comes in.

Reply
  • Ashish,

    Something about your message seems confused. The 8051 architecture has interrupt vectors starting at code address 0x0003 and reserving 8-bytes of code space for each vector. This puts the closest vector location to 0x2C beginning at 0x002B (interrupt 5). Thus, there's no way to use the interrupt keyword to define an interrupt in Keil that's located at that location. I'm not sure, but the compiler might not complain if you manually location something there to jump to your actual ISR.

    What I suspect more, however, is that you've got something confused and this isn't where your processor will actually vector when this event occurs.

    Taking a moment to refer to the datasheet, I can see that you've got things really messed up with regard to the way interrupts on this chip work. This chip has ONE USB interrupt for all of these various "endpoints" and then an "autovectoring" function to unload some work from the processor. This 0x2C offset you mention is in a table that you have to setup on some page boundary. So... the interrupt function you actually have to write is interrupt number 8 as far as Keil's concerned. If you have the autovector function enabled and some byte offset loaded into the buffer, then it will translate the LJMP instruction in interrupt 8 in a manner that sends you to this jump table you've created on some page. That's where the offset 0x2C comes in.

Children
More questions in this forum