Sign in

username:

password:



Not a member?

Search Comp.Arch.Embedded



Search tips

embedded by Keywords

68HC11 | 68HC12 | 8051 | 8052 | ARM | ARM7 | Asic | AT91 | AT91RM9200 | Atmel | AVR | AVRStudio | Bootloader | CFP | CompactFlash | Cygnal | Cypress | Dataflash | DSP | eCos | EEPROM | Embedded Linux | Emulator | Endian | Ethernet | Firewire | FPGA | Freescale | GCC | GNUARM | GSM | H8 | HDLC | I2C | Infineon | Interrupts | Java | JTAG | LCD | LED | LPC2000 | MCU | Microchip | MMC | MPLAB | MSP430 | PC104 | PCB | PCI | PCMCIA | PowerPC | Rabbit | RS232 | RS485 | RTOS | SBC | SDRAM | Sensor | SPI | STK500 | UART | UML | USART | USB | Verilog | VHDL | VxWorks | Xilinx

Ads

Discussion Groups

Discussion Groups | Comp.Arch.Embedded | Cypress EZ-USB help

There are 14 messages in this thread.

You are currently looking at messages 0 to 10.

Cypress EZ-USB help - galapogos - 04:04 03-10-07

Hi,

I'm trying to modify the Cypress EZ-USB firmware for some added
functionality, but I'm having some problems regarding running out of
code space. It seems that when I call some of the EZUSB I2C library
functions, my code space balloons by quite a bit. For example
EZUSB_InitI2C would increase my code space by 500bytes. The default
firmware already uses up over 6KB, which leaves me with about 1KB+ to
play with, so 500 bytes is a lot to be just calling an initialize
function. Has anyone experienced similar problems? Is there any way of
solving this?

btw I'm using Keil uVision2 with the Cypress CY3686 EZUSB NX2 LP-FLEX
DVK.

Thanks.



Re: Cypress EZ-USB help - 18:02 03-10-07

On Oct 3, 1:04 am, galapogos <gois...@gmail.com> wrote:
> Hi,
>
> I'm trying to modify the Cypress EZ-USB firmware for some added
> functionality, but I'm having some problems regarding running out of
> code space. It seems that when I call some of the EZUSB I2C library
> functions, my code space balloons by quite a bit. For example
> EZUSB_InitI2C would increase my code space by 500bytes. The default
> firmware already uses up over 6KB, which leaves me with about 1KB+ to
> play with, so 500 bytes is a lot to be just calling an initialize
> function. Has anyone experienced similar problems? Is there any way of
> solving this?
>
> btw I'm using Keil uVision2 with the Cypress CY3686 EZUSB NX2 LP-FLEX
> DVK.
>
> Thanks.

Cypress or no Cypress, it's still an 8051.  And 8051s do NOT program
well in C.

My guess is that you will need to do what every 8051 programmer has
done when they have run out of space:  Re-code in assembly, and
manually optimize it.

Luckily, there are a number of web sites about this process.  Google
is your friend.

G.

Re: Cypress EZ-USB help - Tim Wescott - 00:15 04-10-07

On Wed, 03 Oct 2007 08:04:10 +0000, galapogos wrote:

> Hi,
> 
> I'm trying to modify the Cypress EZ-USB firmware for some added
> functionality, but I'm having some problems regarding running out of
> code space. It seems that when I call some of the EZUSB I2C library
> functions, my code space balloons by quite a bit. For example
> EZUSB_InitI2C would increase my code space by 500bytes. The default
> firmware already uses up over 6KB, which leaves me with about 1KB+ to
> play with, so 500 bytes is a lot to be just calling an initialize
> function. Has anyone experienced similar problems? Is there any way of
> solving this?
> 
> btw I'm using Keil uVision2 with the Cypress CY3686 EZUSB NX2 LP-FLEX
> DVK.
> 
> Thanks.

It sounds like the I2C library includes the kitchen sink -- is the
EZUSB_InitI2C 500 bytes, or does it pull in the whole library along with
it?

The suggestion to write your own material in assembly is a good one.  To
that I would add that if it's not too late in the development cycle, you
should get yourself a bigger chip.  If you can't c'est la vie -- but your
code is only going to get bigger.

-- 
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

Re: Cypress EZ-USB help - Bill Davy - 05:51 05-10-07

"galapogos" <g...@gmail.com> wrote in message 
news:1...@w3g2000hsg.googlegroups.com...
> Hi,
>
> I'm trying to modify the Cypress EZ-USB firmware for some added
> functionality, but I'm having some problems regarding running out of
> code space. It seems that when I call some of the EZUSB I2C library
> functions, my code space balloons by quite a bit. For example
> EZUSB_InitI2C would increase my code space by 500bytes. The default
> firmware already uses up over 6KB, which leaves me with about 1KB+ to
> play with, so 500 bytes is a lot to be just calling an initialize
> function. Has anyone experienced similar problems? Is there any way of
> solving this?
>
> btw I'm using Keil uVision2 with the Cypress CY3686 EZUSB NX2 LP-FLEX
> DVK.
>
> Thanks.
>



I looked at the actual code sizes from my link and found the following (in 
the M51 file):

000DH     EZUSB_INITI2C
00F9H     I2C_ISR
004AH     _EZUSB_RESULT
0038H     _EZUSB_WAITFOREEPROMWRITE
0033H     _EZUSB_READI2C_
0031H     _EZUSB_WRITEI2C_
000DH     _EZUSB_READI2C
000DH     _EZUSB_WRITEI2C

Of course, it is possible your I2C code may be pulling in something esle, 
perhaps the printf() functions even.

And there are known errors in the I2C code, in case you are doing serious 
work.

Rgds,
    Bill

Re: Cypress EZ-USB help - galapogos - 22:54 07-10-07

On Oct 5, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> "galapogos" <gois...@gmail.com> wrote in message
>
> news:1...@w3g2000hsg.googlegroups.com...
>
>
>
> > Hi,
>
> > I'm trying to modify the Cypress EZ-USB firmware for some added
> > functionality, but I'm having some problems regarding running out of
> > code space. It seems that when I call some of the EZUSB I2C library
> > functions, my code space balloons by quite a bit. For example
> > EZUSB_InitI2C would increase my code space by 500bytes. The default
> > firmware already uses up over 6KB, which leaves me with about 1KB+ to
> > play with, so 500 bytes is a lot to be just calling an initialize
> > function. Has anyone experienced similar problems? Is there any way of
> > solving this?
>
> > btw I'm using Keil uVision2 with the Cypress CY3686 EZUSB NX2 LP-FLEX
> > DVK.
>
> > Thanks.
>
> I looked at the actual code sizes from my link and found the following (in
> the M51 file):
>
> 000DH     EZUSB_INITI2C
> 00F9H     I2C_ISR
> 004AH     _EZUSB_RESULT
> 0038H     _EZUSB_WAITFOREEPROMWRITE
> 0033H     _EZUSB_READI2C_
> 0031H     _EZUSB_WRITEI2C_
> 000DH     _EZUSB_READI2C
> 000DH     _EZUSB_WRITEI2C
>
> Of course, it is possible your I2C code may be pulling in something esle,
> perhaps the printf() functions even.
>
> And there are known errors in the I2C code, in case you are doing serious
> work.
>
> Rgds,
>     Bill

Thanks Bill. I believe it's pulling in those functions, because it
throws me warnings about unused functions whenever I don't use all the
functions(eg when I readi2c but don't writei2c).

What known errors are you talking about btw?

Re: Cypress EZ-USB help - Bill Davy - 05:51 08-10-07

"galapogos" <g...@gmail.com> wrote in message 
news:1...@57g2000hsv.googlegroups.com...
> On Oct 5, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> "galapogos" <gois...@gmail.com> wrote in message
>>
>> news:1...@w3g2000hsg.googlegroups.com...
>>
>>
>>
>> > Hi,
>>
>> > I'm trying to modify the Cypress EZ-USB firmware for some added
>> > functionality, but I'm having some problems regarding running out of
>> > code space. It seems that when I call some of the EZUSB I2C library
>> > functions, my code space balloons by quite a bit. For example
>> > EZUSB_InitI2C would increase my code space by 500bytes. The default
>> > firmware already uses up over 6KB, which leaves me with about 1KB+ to
>> > play with, so 500 bytes is a lot to be just calling an initialize
>> > function. Has anyone experienced similar problems? Is there any way of
>> > solving this?
>>
>> > btw I'm using Keil uVision2 with the Cypress CY3686 EZUSB NX2 LP-FLEX
>> > DVK.
>>
>> > Thanks.
>>
>> I looked at the actual code sizes from my link and found the following 
>> (in
>> the M51 file):
>>
>> 000DH     EZUSB_INITI2C
>> 00F9H     I2C_ISR
>> 004AH     _EZUSB_RESULT
>> 0038H     _EZUSB_WAITFOREEPROMWRITE
>> 0033H     _EZUSB_READI2C_
>> 0031H     _EZUSB_WRITEI2C_
>> 000DH     _EZUSB_READI2C
>> 000DH     _EZUSB_WRITEI2C
>>
>> Of course, it is possible your I2C code may be pulling in something esle,
>> perhaps the printf() functions even.
>>
>> And there are known errors in the I2C code, in case you are doing serious
>> work.
>>
>> Rgds,
>>     Bill
>
> Thanks Bill. I believe it's pulling in those functions, because it
> throws me warnings about unused functions whenever I don't use all the
> functions(eg when I readi2c but don't writei2c).
>
> What known errors are you talking about btw?
>
a) In EZUSB_WriteI2C_() and EZUSB_ReadI2C_(), set up I2CPckt before setting 
bmSTART or it is possible that an I2C interrupt will occur before I2CPckt 
is set up.


BOOL EZUSB_WriteI2C_(BYTE addr, BYTE length, BYTE xdata *dat)
{
#ifndef TNG
   // if in progress, wait for STOP to complete
   while (I2CS & bmSTOP)
  ;
#endif

 if(I2CPckt.status == I2C_IDLE)
 {

  I2CPckt.length = length;
  I2CPckt.dat = dat;
  I2CPckt.count = 0;
  I2CPckt.status = I2C_SENDING;

  //
  // 17 September, 2007
  // XXX of Cypress says these should be after the I2CPckt structure is set 
up.
  //
  I2CS |= bmSTART;
  I2DAT = addr << 1; // 0 for write byte

  return(TRUE);
 }

 return(FALSE);
}

BOOL EZUSB_ReadI2C_(BYTE addr, BYTE length, BYTE xdata *dat)
{
#ifndef TNG
   // if in progress, wait for STOP to complete
   while (I2CS & bmSTOP)
  ;
#endif

   if(I2CPckt.status == I2C_IDLE)
 {
  I2CPckt.length = length;
  I2CPckt.dat = dat;
  I2CPckt.count = 0;
  I2CPckt.status = I2C_PRIME;

  //
  // 17 September, 2007
  // XXX of Cypress says these should be after the I2CPckt structure is set 
up.
  //
  I2CS |= bmSTART;
  I2DAT = (addr << 1) | 0x01; // 1 for read byte

  return(TRUE);
 }

 return(FALSE);
}

b) If there is an I2C error detected in i2c_isr(), set bmSTOP:

void i2c_isr(void) interrupt I2C_VECT
{             // I2C State Machine

 if(I2CS & bmBERR)
  {
  I2CPckt.status = I2C_BERROR;
  //
  // 17 September, 2007
  // XXX of Cypress says this should be here too.
  //
  I2CS |= bmSTOP;
  }
 else if ((!(I2CS & bmACK)) && (I2CPckt.status != I2C_RECEIVING))
  {
  I2CPckt.status = I2C_NACK;
  I2CS |= bmSTOP; // RWD 8 June, 2005
  }
 else
  switch(I2CPckt.status)
  {
   case I2C_SENDING:
    I2DAT = I2CPckt.dat[I2CPckt.count++];
    if(I2CPckt.count == I2CPckt.length)
     I2CPckt.status = I2C_STOP;
    break;
   case I2C_PRIME:
    I2CPckt.dat[I2CPckt.count] = I2DAT;
    I2CPckt.status = I2C_RECEIVING;
    if(I2CPckt.length == 1) // may be only one byte read
     I2CS |= bmLASTRD;
    break;
   case I2C_RECEIVING:
    if(I2CPckt.count == I2CPckt.length - 2)
     I2CS |= bmLASTRD;
    if(I2CPckt.count == I2CPckt.length - 1)
    {
     I2CS |= bmSTOP;
     I2CPckt.status = I2C_IDLE;
    }
    I2CPckt.dat[I2CPckt.count] = I2DAT;
    ++I2CPckt.count;
    break;
   case I2C_STOP:
    I2CS |= bmSTOP;
#ifdef TNG
    I2CPckt.status = I2C_WAITSTOP;
#else
    I2CPckt.status = I2C_IDLE;
#endif
    break;
   case I2C_WAITSTOP:
    I2CPckt.status = I2C_IDLE;
    break;
  }
 EXIF &= ~0x20;  // Clear interrupt flag IE3

}

c) There is a race hazard in main() in fw.c in that as it stands, GotSUD can 
be cleared after ISR_Sudav() has set it.

  if ( GotSUD )            // Wait for SUDAV
   {
   //
   // Swap the order here.
   //
   GotSUD = FALSE;       // Clear SUDAV flag
   SetupCommand();       // Implement setup command
   }

d) There are probably others but in general Cypress do not seem willing to 
share them with their users for reasons which are, frankly, baffling.  XXX 
above is to protect a helpful contact in Cypress.  The above problems tend 
to occur more if there are lengthy ISR which while never is a good thing is 
sometimes necessary.

Does anyone else have bugs they can share?

Rgds,
   Bill Davy

Re: Cypress EZ-USB help - galapogos - 22:40 08-10-07

On Oct 8, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> "galapogos" <gois...@gmail.com> wrote in message
>
> news:1...@57g2000hsv.googlegroups.com...
>
> > On Oct 5, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> >> "galapogos" <gois...@gmail.com> wrote in message
>
> >>news:1...@w3g2000hsg.googlegroups.com...
>
> >> > Hi,
>
> >> > I'm trying to modify the Cypress EZ-USB firmware for some added
> >> > functionality, but I'm having some problems regarding running out of
> >> > code space. It seems that when I call some of the EZUSB I2C library
> >> > functions, my code space balloons by quite a bit. For example
> >> > EZUSB_InitI2C would increase my code space by 500bytes. The default
> >> > firmware already uses up over 6KB, which leaves me with about 1KB+ to
> >> > play with, so 500 bytes is a lot to be just calling an initialize
> >> > function. Has anyone experienced similar problems? Is there any way of
> >> > solving this?
>
> >> > btw I'm using Keil uVision2 with the Cypress CY3686 EZUSB NX2 LP-FLEX
> >> > DVK.
>
> >> > Thanks.
>
> >> I looked at the actual code sizes from my link and found the following
> >> (in
> >> the M51 file):
>
> >> 000DH     EZUSB_INITI2C
> >> 00F9H     I2C_ISR
> >> 004AH     _EZUSB_RESULT
> >> 0038H     _EZUSB_WAITFOREEPROMWRITE
> >> 0033H     _EZUSB_READI2C_
> >> 0031H     _EZUSB_WRITEI2C_
> >> 000DH     _EZUSB_READI2C
> >> 000DH     _EZUSB_WRITEI2C
>
> >> Of course, it is possible your I2C code may be pulling in something esle,
> >> perhaps the printf() functions even.
>
> >> And there are known errors in the I2C code, in case you are doing serious
> >> work.
>
> >> Rgds,
> >>     Bill
>
> > Thanks Bill. I believe it's pulling in those functions, because it
> > throws me warnings about unused functions whenever I don't use all the
> > functions(eg when I readi2c but don't writei2c).
>
> > What known errors are you talking about btw?
>
> a) In EZUSB_WriteI2C_() and EZUSB_ReadI2C_(), set up I2CPckt before setting
> bmSTART or it is possible that an I2C interrupt will occur before I2CPckt
> is set up.
>
> BOOL EZUSB_WriteI2C_(BYTE addr, BYTE length, BYTE xdata *dat)
> {
> #ifndef TNG
>    // if in progress, wait for STOP to complete
>    while (I2CS & bmSTOP)
>   ;
> #endif
>
>  if(I2CPckt.status == I2C_IDLE)
>  {
>
>   I2CPckt.length = length;
>   I2CPckt.dat = dat;
>   I2CPckt.count = 0;
>   I2CPckt.status = I2C_SENDING;
>
>   //
>   // 17 September, 2007
>   // XXX of Cypress says these should be after the I2CPckt structure is set
> up.
>   //
>   I2CS |= bmSTART;
>   I2DAT = addr << 1; // 0 for write byte
>
>   return(TRUE);
>  }
>
>  return(FALSE);
>
> }
>
> BOOL EZUSB_ReadI2C_(BYTE addr, BYTE length, BYTE xdata *dat)
> {
> #ifndef TNG
>    // if in progress, wait for STOP to complete
>    while (I2CS & bmSTOP)
>   ;
> #endif
>
>    if(I2CPckt.status == I2C_IDLE)
>  {
>   I2CPckt.length = length;
>   I2CPckt.dat = dat;
>   I2CPckt.count = 0;
>   I2CPckt.status = I2C_PRIME;
>
>   //
>   // 17 September, 2007
>   // XXX of Cypress says these should be after the I2CPckt structure is set
> up.
>   //
>   I2CS |= bmSTART;
>   I2DAT = (addr << 1) | 0x01; // 1 for read byte
>
>   return(TRUE);
>  }
>
>  return(FALSE);
>
> }
>
> b) If there is an I2C error detected in i2c_isr(), set bmSTOP:
>
> void i2c_isr(void) interrupt I2C_VECT
> {             // I2C State Machine
>
>  if(I2CS & bmBERR)
>   {
>   I2CPckt.status = I2C_BERROR;
>   //
>   // 17 September, 2007
>   // XXX of Cypress says this should be here too.
>   //
>   I2CS |= bmSTOP;
>   }
>  else if ((!(I2CS & bmACK)) && (I2CPckt.status != I2C_RECEIVING))
>   {
>   I2CPckt.status = I2C_NACK;
>   I2CS |= bmSTOP; // RWD 8 June, 2005
>   }
>  else
>   switch(I2CPckt.status)
>   {
>    case I2C_SENDING:
>     I2DAT = I2CPckt.dat[I2CPckt.count++];
>     if(I2CPckt.count == I2CPckt.length)
>      I2CPckt.status = I2C_STOP;
>     break;
>    case I2C_PRIME:
>     I2CPckt.dat[I2CPckt.count] = I2DAT;
>     I2CPckt.status = I2C_RECEIVING;
>     if(I2CPckt.length == 1) // may be only one byte read
>      I2CS |= bmLASTRD;
>     break;
>    case I2C_RECEIVING:
>     if(I2CPckt.count == I2CPckt.length - 2)
>      I2CS |= bmLASTRD;
>     if(I2CPckt.count == I2CPckt.length - 1)
>     {
>      I2CS |= bmSTOP;
>      I2CPckt.status = I2C_IDLE;
>     }
>     I2CPckt.dat[I2CPckt.count] = I2DAT;
>     ++I2CPckt.count;
>     break;
>    case I2C_STOP:
>     I2CS |= bmSTOP;
> #ifdef TNG
>     I2CPckt.status = I2C_WAITSTOP;
> #else
>     I2CPckt.status = I2C_IDLE;
> #endif
>     break;
>    case I2C_WAITSTOP:
>     I2CPckt.status = I2C_IDLE;
>     break;
>   }
>  EXIF &= ~0x20;  // Clear interrupt flag IE3
>
> }
>
> c) There is a race hazard in main() in fw.c in that as it stands, GotSUD can
> be cleared after ISR_Sudav() has set it.
>
>   if ( GotSUD )            // Wait for SUDAV
>    {
>    //
>    // Swap the order here.
>    //
>    GotSUD = FALSE;       // Clear SUDAV flag
>    SetupCommand();       // Implement setup command
>    }
>
> d) There are probably others but in general Cypress do not seem willing to
> share them with their users for reasons which are, frankly, baffling.  XXX
> above is to protect a helpful contact in Cypress.  The above problems tend
> to occur more if there are lengthy ISR which while never is a good thing is
> sometimes necessary.
>
> Does anyone else have bugs they can share?
>
> Rgds,
>    Bill Davy

Thanks Bill,

Just wondering, how did you manage to obtain the actual code for these
library functions. Do you have the code for the other i2c functions
too? Also, is the code you show already modified or awaiting
modification? Lastly how can i modify the code? Do I have to write new
functions w/a different name and use these? What about the isr?

Re: Cypress EZ-USB help - Bill Davy - 05:13 09-10-07

"galapogos" <g...@gmail.com> wrote in message 
news:1...@g4g2000hsf.googlegroups.com...
> On Oct 8, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> "galapogos" <gois...@gmail.com> wrote in message
>>
>> news:1...@57g2000hsv.googlegroups.com...
>>
>> > On Oct 5, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> >> "galapogos" <gois...@gmail.com> wrote in message
>>
>> >>news:1...@w3g2000hsg.googlegroups.com...
>>
>> >> > Hi,
>>
>> >> > I'm trying to modify the Cypress EZ-USB firmware for some added
>> >> > functionality, but I'm having some problems regarding running out of
>> >> > code space. It seems that when I call some of the EZUSB I2C library
>> >> > functions, my code space balloons by quite a bit. For example
>> >> > EZUSB_InitI2C would increase my code space by 500bytes. The default
>> >> > firmware already uses up over 6KB, which leaves me with about 1KB+ 
>> >> > to
>> >> > play with, so 500 bytes is a lot to be just calling an initialize
>> >> > function. Has anyone experienced similar problems? Is there any way 
>> >> > of
>> >> > solving this?
>>
>> >> > btw I'm using Keil uVision2 with the Cypress CY3686 EZUSB NX2 
>> >> > LP-FLEX
>> >> > DVK.
>>
>> >> > Thanks.
>>
>> >> I looked at the actual code sizes from my link and found the following
>> >> (in
>> >> the M51 file):
>>
>> >> 000DH     EZUSB_INITI2C
>> >> 00F9H     I2C_ISR
>> >> 004AH     _EZUSB_RESULT
>> >> 0038H     _EZUSB_WAITFOREEPROMWRITE
>> >> 0033H     _EZUSB_READI2C_
>> >> 0031H     _EZUSB_WRITEI2C_
>> >> 000DH     _EZUSB_READI2C
>> >> 000DH     _EZUSB_WRITEI2C
>>
>> >> Of course, it is possible your I2C code may be pulling in something 
>> >> esle,
>> >> perhaps the printf() functions even.
>>
>> >> And there are known errors in the I2C code, in case you are doing 
>> >> serious
>> >> work.
>>
>> >> Rgds,
>> >>     Bill
>>
>> > Thanks Bill. I believe it's pulling in those functions, because it
>> > throws me warnings about unused functions whenever I don't use all the
>> > functions(eg when I readi2c but don't writei2c).
>>
>> > What known errors are you talking about btw?
>>
>> a) In EZUSB_WriteI2C_() and EZUSB_ReadI2C_(), set up I2CPckt before 
>> setting
>> bmSTART or it is possible that an I2C interrupt will occur before I2CPckt
>> is set up.
>>
>> BOOL EZUSB_WriteI2C_(BYTE addr, BYTE length, BYTE xdata *dat)
>> {
>> #ifndef TNG
>>    // if in progress, wait for STOP to complete
>>    while (I2CS & bmSTOP)
>>   ;
>> #endif
>>
>>  if(I2CPckt.status == I2C_IDLE)
>>  {
>>
>>   I2CPckt.length = length;
>>   I2CPckt.dat = dat;
>>   I2CPckt.count = 0;
>>   I2CPckt.status = I2C_SENDING;
>>
>>   //
>>   // 17 September, 2007
>>   // XXX of Cypress says these should be after the I2CPckt structure is 
>> set
>> up.
>>   //
>>   I2CS |= bmSTART;
>>   I2DAT = addr << 1; // 0 for write byte
>>
>>   return(TRUE);
>>  }
>>
>>  return(FALSE);
>>
>> }
>>
>> BOOL EZUSB_ReadI2C_(BYTE addr, BYTE length, BYTE xdata *dat)
>> {
>> #ifndef TNG
>>    // if in progress, wait for STOP to complete
>>    while (I2CS & bmSTOP)
>>   ;
>> #endif
>>
>>    if(I2CPckt.status == I2C_IDLE)
>>  {
>>   I2CPckt.length = length;
>>   I2CPckt.dat = dat;
>>   I2CPckt.count = 0;
>>   I2CPckt.status = I2C_PRIME;
>>
>>   //
>>   // 17 September, 2007
>>   // XXX of Cypress says these should be after the I2CPckt structure is 
>> set
>> up.
>>   //
>>   I2CS |= bmSTART;
>>   I2DAT = (addr << 1) | 0x01; // 1 for read byte
>>
>>   return(TRUE);
>>  }
>>
>>  return(FALSE);
>>
>> }
>>
>> b) If there is an I2C error detected in i2c_isr(), set bmSTOP:
>>
>> void i2c_isr(void) interrupt I2C_VECT
>> {             // I2C State Machine
>>
>>  if(I2CS & bmBERR)
>>   {
>>   I2CPckt.status = I2C_BERROR;
>>   //
>>   // 17 September, 2007
>>   // XXX of Cypress says this should be here too.
>>   //
>>   I2CS |= bmSTOP;
>>   }
>>  else if ((!(I2CS & bmACK)) && (I2CPckt.status != I2C_RECEIVING))
>>   {
>>   I2CPckt.status = I2C_NACK;
>>   I2CS |= bmSTOP; // RWD 8 June, 2005
>>   }
>>  else
>>   switch(I2CPckt.status)
>>   {
>>    case I2C_SENDING:
>>     I2DAT = I2CPckt.dat[I2CPckt.count++];
>>     if(I2CPckt.count == I2CPckt.length)
>>      I2CPckt.status = I2C_STOP;
>>     break;
>>    case I2C_PRIME:
>>     I2CPckt.dat[I2CPckt.count] = I2DAT;
>>     I2CPckt.status = I2C_RECEIVING;
>>     if(I2CPckt.length == 1) // may be only one byte read
>>      I2CS |= bmLASTRD;
>>     break;
>>    case I2C_RECEIVING:
>>     if(I2CPckt.count == I2CPckt.length - 2)
>>      I2CS |= bmLASTRD;
>>     if(I2CPckt.count == I2CPckt.length - 1)
>>     {
>>      I2CS |= bmSTOP;
>>      I2CPckt.status = I2C_IDLE;
>>     }
>>     I2CPckt.dat[I2CPckt.count] = I2DAT;
>>     ++I2CPckt.count;
>>     break;
>>    case I2C_STOP:
>>     I2CS |= bmSTOP;
>> #ifdef TNG
>>     I2CPckt.status = I2C_WAITSTOP;
>> #else
>>     I2CPckt.status = I2C_IDLE;
>> #endif
>>     break;
>>    case I2C_WAITSTOP:
>>     I2CPckt.status = I2C_IDLE;
>>     break;
>>   }
>>  EXIF &= ~0x20;  // Clear interrupt flag IE3
>>
>> }
>>
>> c) There is a race hazard in main() in fw.c in that as it stands, GotSUD 
>> can
>> be cleared after ISR_Sudav() has set it.
>>
>>   if ( GotSUD )            // Wait for SUDAV
>>    {
>>    //
>>    // Swap the order here.
>>    //
>>    GotSUD = FALSE;       // Clear SUDAV flag
>>    SetupCommand();       // Implement setup command
>>    }
>>
>> d) There are probably others but in general Cypress do not seem willing 
>> to
>> share them with their users for reasons which are, frankly, baffling. 
>> XXX
>> above is to protect a helpful contact in Cypress.  The above problems 
>> tend
>> to occur more if there are lengthy ISR which while never is a good thing 
>> is
>> sometimes necessary.
>>
>> Does anyone else have bugs they can share?
>>
>> Rgds,
>>    Bill Davy
>
> Thanks Bill,
>
> Just wondering, how did you manage to obtain the actual code for these
> library functions. Do you have the code for the other i2c functions
> too? Also, is the code you show already modified or awaiting
> modification? Lastly how can i modify the code? Do I have to write new
> functions w/a different name and use these? What about the isr?
>


The code is in C:\Cypress\USB\Target\Lib\Ezusb (i2c.c and i2c_rw.c) on my 
machine and that included the I2C ISR.

There is also EZUSBLIB.h somewhere.  I do think some of the function 
declarations are wrong (for example, EZUSB_ReadI2C() really returns a BYTE 
not a BOOL).

The code above is already patched (compare with the originals when you find 
them).

It would probably result in smaller code if I2C_OK had the value zero.

I should probably not have posted the source code above, but it is hard to 
describe the changes otherwise.

Hope this helps,
   Bill

Re: Cypress EZ-USB help - galapogos - 22:03 09-10-07

On Oct 9, 5:13 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> "galapogos" <gois...@gmail.com> wrote in message
>
> news:1...@g4g2000hsf.googlegroups.com...
>
>
>
> > On Oct 8, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> >> "galapogos" <gois...@gmail.com> wrote in message
>
> >>news:1...@57g2000hsv.googlegroups.com...
>
> >> > On Oct 5, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> >> >> "galapogos" <gois...@gmail.com> wrote in message
>
> >> >>news:1...@w3g2000hsg.googlegroups.com...
>
> >> >> > Hi,
>
> >> >> > I'm trying to modify the Cypress EZ-USB firmware for some added
> >> >> > functionality, but I'm having some problems regarding running out of
> >> >> > code space. It seems that when I call some of the EZUSB I2C library
> >> >> > functions, my code space balloons by quite a bit. For example
> >> >> > EZUSB_InitI2C would increase my code space by 500bytes. The default
> >> >> > firmware already uses up over 6KB, which leaves me with about 1KB+
> >> >> > to
> >> >> > play with, so 500 bytes is a lot to be just calling an initialize
> >> >> > function. Has anyone experienced similar problems? Is there any way
> >> >> > of
> >> >> > solving this?
>
> >> >> > btw I'm using Keil uVision2 with the Cypress CY3686 EZUSB NX2
> >> >> > LP-FLEX
> >> >> > DVK.
>
> >> >> > Thanks.
>
> >> >> I looked at the actual code sizes from my link and found the following
> >> >> (in
> >> >> the M51 file):
>
> >> >> 000DH     EZUSB_INITI2C
> >> >> 00F9H     I2C_ISR
> >> >> 004AH     _EZUSB_RESULT
> >> >> 0038H     _EZUSB_WAITFOREEPROMWRITE
> >> >> 0033H     _EZUSB_READI2C_
> >> >> 0031H     _EZUSB_WRITEI2C_
> >> >> 000DH     _EZUSB_READI2C
> >> >> 000DH     _EZUSB_WRITEI2C
>
> >> >> Of course, it is possible your I2C code may be pulling in something
> >> >> esle,
> >> >> perhaps the printf() functions even.
>
> >> >> And there are known errors in the I2C code, in case you are doing
> >> >> serious
> >> >> work.
>
> >> >> Rgds,
> >> >>     Bill
>
> >> > Thanks Bill. I believe it's pulling in those functions, because it
> >> > throws me warnings about unused functions whenever I don't use all the
> >> > functions(eg when I readi2c but don't writei2c).
>
> >> > What known errors are you talking about btw?
>
> >> a) In EZUSB_WriteI2C_() and EZUSB_ReadI2C_(), set up I2CPckt before
> >> setting
> >> bmSTART or it is possible that an I2C interrupt will occur before I2CPckt
> >> is set up.
>
> >> BOOL EZUSB_WriteI2C_(BYTE addr, BYTE length, BYTE xdata *dat)
> >> {
> >> #ifndef TNG
> >>    // if in progress, wait for STOP to complete
> >>    while (I2CS & bmSTOP)
> >>   ;
> >> #endif
>
> >>  if(I2CPckt.status == I2C_IDLE)
> >>  {
>
> >>   I2CPckt.length = length;
> >>   I2CPckt.dat = dat;
> >>   I2CPckt.count = 0;
> >>   I2CPckt.status = I2C_SENDING;
>
> >>   //
> >>   // 17 September, 2007
> >>   // XXX of Cypress says these should be after the I2CPckt structure is
> >> set
> >> up.
> >>   //
> >>   I2CS |= bmSTART;
> >>   I2DAT = addr << 1; // 0 for write byte
>
> >>   return(TRUE);
> >>  }
>
> >>  return(FALSE);
>
> >> }
>
> >> BOOL EZUSB_ReadI2C_(BYTE addr, BYTE length, BYTE xdata *dat)
> >> {
> >> #ifndef TNG
> >>    // if in progress, wait for STOP to complete
> >>    while (I2CS & bmSTOP)
> >>   ;
> >> #endif
>
> >>    if(I2CPckt.status == I2C_IDLE)
> >>  {
> >>   I2CPckt.length = length;
> >>   I2CPckt.dat = dat;
> >>   I2CPckt.count = 0;
> >>   I2CPckt.status = I2C_PRIME;
>
> >>   //
> >>   // 17 September, 2007
> >>   // XXX of Cypress says these should be after the I2CPckt structure is
> >> set
> >> up.
> >>   //
> >>   I2CS |= bmSTART;
> >>   I2DAT = (addr << 1) | 0x01; // 1 for read byte
>
> >>   return(TRUE);
> >>  }
>
> >>  return(FALSE);
>
> >> }
>
> >> b) If there is an I2C error detected in i2c_isr(), set bmSTOP:
>
> >> void i2c_isr(void) interrupt I2C_VECT
> >> {             // I2C State Machine
>
> >>  if(I2CS & bmBERR)
> >>   {
> >>   I2CPckt.status = I2C_BERROR;
> >>   //
> >>   // 17 September, 2007
> >>   // XXX of Cypress says this should be here too.
> >>   //
> >>   I2CS |= bmSTOP;
> >>   }
> >>  else if ((!(I2CS & bmACK)) && (I2CPckt.status != I2C_RECEIVING))
> >>   {
> >>   I2CPckt.status = I2C_NACK;
> >>   I2CS |= bmSTOP; // RWD 8 June, 2005
> >>   }
> >>  else
> >>   switch(I2CPckt.status)
> >>   {
> >>    case I2C_SENDING:
> >>     I2DAT = I2CPckt.dat[I2CPckt.count++];
> >>     if(I2CPckt.count == I2CPckt.length)
> >>      I2CPckt.status = I2C_STOP;
> >>     break;
> >>    case I2C_PRIME:
> >>     I2CPckt.dat[I2CPckt.count] = I2DAT;
> >>     I2CPckt.status = I2C_RECEIVING;
> >>     if(I2CPckt.length == 1) // may be only one byte read
> >>      I2CS |= bmLASTRD;
> >>     break;
> >>    case I2C_RECEIVING:
> >>     if(I2CPckt.count == I2CPckt.length - 2)
> >>      I2CS |= bmLASTRD;
> >>     if(I2CPckt.count == I2CPckt.length - 1)
> >>     {
> >>      I2CS |= bmSTOP;
> >>      I2CPckt.status = I2C_IDLE;
> >>     }
> >>     I2CPckt.dat[I2CPckt.count] = I2DAT;
> >>     ++I2CPckt.count;
> >>     break;
> >>    case I2C_STOP:
> >>     I2CS |= bmSTOP;
> >> #ifdef TNG
> >>     I2CPckt.status = I2C_WAITSTOP;
> >> #else
> >>     I2CPckt.status = I2C_IDLE;
> >> #endif
> >>     break;
> >>    case I2C_WAITSTOP:
> >>     I2CPckt.status = I2C_IDLE;
> >>     break;
> >>   }
> >>  EXIF &= ~0x20;  // Clear interrupt flag IE3
>
> >> }
>
> >> c) There is a race hazard in main() in fw.c in that as it stands, GotSUD
> >> can
> >> be cleared after ISR_Sudav() has set it.
>
> >>   if ( GotSUD )            // Wait for SUDAV
> >>    {
> >>    //
> >>    // Swap the order here.
> >>    //
> >>    GotSUD = FALSE;       // Clear SUDAV flag
> >>    SetupCommand();       // Implement setup command
> >>    }
>
> >> d) There are probably others but in general Cypress do not seem willing
> >> to
> >> share them with their users for reasons which are, frankly, baffling.
> >> XXX
> >> above is to protect a helpful contact in Cypress.  The above problems
> >> tend
> >> to occur more if there are lengthy ISR which while never is a good thing
> >> is
> >> sometimes necessary.
>
> >> Does anyone else have bugs they can share?
>
> >> Rgds,
> >>    Bill Davy
>
> > Thanks Bill,
>
> > Just wondering, how did you manage to obtain the actual code for these
> > library functions. Do you have the code for the other i2c functions
> > too? Also, is the code you show already modified or awaiting
> > modification? Lastly how can i modify the code? Do I have to write new
> > functions w/a different name and use these? What about the isr?
>
> The code is in C:\Cypress\USB\Target\Lib\Ezusb (i2c.c and i2c_rw.c) on my
> machine and that included the I2C ISR.
>
> There is also EZUSBLIB.h somewhere.  I do think some of the function
> declarations are wrong (for example, EZUSB_ReadI2C() really returns a BYTE
> not a BOOL).
>
> The code above is already patched (compare with the originals when you find
> them).
>
> It would probably result in smaller code if I2C_OK had the value zero.
>
> I should probably not have posted the source code above, but it is hard to
> describe the changes otherwise.
>
> Hope this helps,
>    Bill

Thanks again Bill. I'm able to find the i2c.c and i2c_rw.c. Would it
be possible to make the changes in these files and expect the library
to be updated? I don't have EZUSBLIB.h, but instead I find a EZUSB.LIB
which I assume is precompiled already.

Re: Cypress EZ-USB help - Bill Davy - 05:52 10-10-07

"galapogos" <g...@gmail.com> wrote in message 
news:1...@50g2000hsm.googlegroups.com...
> On Oct 9, 5:13 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> "galapogos" <gois...@gmail.com> wrote in message
>>
>> news:1...@g4g2000hsf.googlegroups.com...
>>
>>
>>
>> > On Oct 8, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> >> "galapogos" <gois...@gmail.com> wrote in message
>>
>> >>news:1...@57g2000hsv.googlegroups.com...
>>
>> >> > On Oct 5, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> >> >> "galapogos" <gois...@gmail.com> wrote in message
>>
>> >> >>news:1...@w3g2000hsg.googlegroups.com...
>>
>> >> >> > Hi,
>>
>> >> >> > I'm trying to modify the Cypress EZ-USB firmware for some added
>> >> >> > functionality, but I'm having some problems regarding running out 
>> >> >> > of
>> >> >> > code space. It seems that when I call some of the EZUSB I2C 
>> >> >> > library
>> >> >> > functions, my code space balloons by quite a bit. For example
>> >> >> > EZUSB_InitI2C would increase my code space by 500bytes. The 
>> >> >> > default
>> >> >> > firmware already uses up over 6KB, which leaves me with about 
>> >> >> > 1KB+
>> >> >> > to
>> >> >> > play with, so 500 bytes is a lot to be just calling an initialize
>> >> >> > function. Has anyone experienced similar problems? Is there any 
>> >> >> > way
>> >> >> > of
>> >> >> > solving this?
>>
>> >> >> > btw I'm using Keil uVision2 with the Cypress CY3686 EZUSB NX2
>> >> >> > LP-FLEX
>> >> >> > DVK.
>>
>> >> >> > Thanks.
>>
>> >> >> I looked at the actual code sizes from my link and found the 
>> >> >> following
>> >> >> (in
>> >> >> the M51 file):
>>
>> >> >> 000DH     EZUSB_INITI2C
>> >> >> 00F9H     I2C_ISR
>> >> >> 004AH     _EZUSB_RESULT
>> >> >> 0038H     _EZUSB_WAITFOREEPROMWRITE
>> >> >> 0033H     _EZUSB_READI2C_
>> >> >> 0031H     _EZUSB_WRITEI2C_
>> >> >> 000DH     _EZUSB_READI2C
>> >> >> 000DH     _EZUSB_WRITEI2C
>>
>> >> >> Of course, it is possible your I2C code may be pulling in something
>> >> >> esle,
>> >> >> perhaps the printf() functions even.
>>
>> >> >> And there are known errors in the I2C code, in case you are doing
>> >> >> serious
>> >> >> work.
>>
>> >> >> Rgds,
>> >> >>     Bill
>>
>> >> > Thanks Bill. I believe it's pulling in those functions, because it
>> >> > throws me warnings about unused functions whenever I don't use all 
>> >> > the
>> >> > functions(eg when I readi2c but don't writei2c).
>>
>> >> > What known errors are you talking about btw?
>>
>> >> a) In EZUSB_WriteI2C_() and EZUSB_ReadI2C_(), set up I2CPckt before
>> >> setting
>> >> bmSTART or it is possible that an I2C interrupt will occur before 
>> >> I2CPckt
>> >> is set up.
>>
>> >> BOOL EZUSB_WriteI2C_(BYTE addr, BYTE length, BYTE xdata *dat)
>> >> {
>> >> #ifndef TNG
>> >>    // if in progress, wait for STOP to complete
>> >>    while (I2CS & bmSTOP)
>> >>   ;
>> >> #endif
>>
>> >>  if(I2CPckt.status == I2C_IDLE)
>> >>  {
>>
>> >>   I2CPckt.length = length;
>> >>   I2CPckt.dat = dat;
>> >>   I2CPckt.count = 0;
>> >>   I2CPckt.status = I2C_SENDING;
>>
>> >>   //
>> >>   // 17 September, 2007
>> >>   // XXX of Cypress says these should be after the I2CPckt structure 
>> >> is
>> >> set
>> >> up.
>> >>   //
>> >>   I2CS |= bmSTART;
>> >>   I2DAT = addr << 1; // 0 for write byte
>>
>> >>   return(TRUE);
>> >>  }
>>
>> >>  return(FALSE);
>>
>> >> }
>>
>> >> BOOL EZUSB_ReadI2C_(BYTE addr, BYTE length, BYTE xdata *dat)
>> >> {
>> >> #ifndef TNG
>> >>    // if in progress, wait for STOP to complete
>> >>    while (I2CS & bmSTOP)
>> >>   ;
>> >> #endif
>>
>> >>    if(I2CPckt.status == I2C_IDLE)
>> >>  {
>> >>   I2CPckt.length = length;
>> >>   I2CPckt.dat = dat;
>> >>   I2CPckt.count = 0;
>> >>   I2CPckt.status = I2C_PRIME;
>>
>> >>   //
>> >>   // 17 September, 2007
>> >>   // XXX of Cypress says these should be after the I2CPckt structure 
>> >> is
>> >> set
>> >> up.
>> >>   //
>> >>   I2CS |= bmSTART;
>> >>   I2DAT = (addr << 1) | 0x01; // 1 for read byte
>>
>> >>   return(TRUE);
>> >>  }
>>
>> >>  return(FALSE);
>>
>> >> }
>>
>> >> b) If there is an I2C error detected in i2c_isr(), set bmSTOP:
>>
>> >> void i2c_isr(void) interrupt I2C_VECT
>> >> {             // I2C State Machine
>>
>> >>  if(I2CS & bmBERR)
>> >>   {
>> >>   I2CPckt.status = I2C_BERROR;
>> >>   //
>> >>   // 17 September, 2007
>> >>   // XXX of Cypress says this should be here too.
>> >>   //
>> >>   I2CS |= bmSTOP;
>> >>   }
>> >>  else if ((!(I2CS & bmACK)) && (I2CPckt.status != I2C_RECEIVING))
>> >>   {
>> >>   I2CPckt.status = I2C_NACK;
>> >>   I2CS |= bmSTOP; // RWD 8 June, 2005
>> >>   }
>> >>  else
>> >>   switch(I2CPckt.status)
>> >>   {
>> >>    case I2C_SENDING:
>> >>     I2DAT = I2CPckt.dat[I2CPckt.count++];
>> >>     if(I2CPckt.count == I2CPckt.length)
>> >>      I2CPckt.status = I2C_STOP;
>> >>     break;
>> >>    case I2C_PRIME:
>> >>     I2CPckt.dat[I2CPckt.count] = I2DAT;
>> >>     I2CPckt.status = I2C_RECEIVING;
>> >>     if(I2CPckt.length == 1) // may be only one byte read
>> >>      I2CS |= bmLASTRD;
>> >>     break;
>> >>    case I2C_RECEIVING:
>> >>     if(I2CPckt.count == I2CPckt.length - 2)
>> >>      I2CS |= bmLASTRD;
>> >>     if(I2CPckt.count == I2CPckt.length - 1)
>> >>     {
>> >>      I2CS |= bmSTOP;
>> >>      I2CPckt.status = I2C_IDLE;
>> >>     }
>> >>     I2CPckt.dat[I2CPckt.count] = I2DAT;
>> >>     ++I2CPckt.count;
>> >>     break;
>> >>    case I2C_STOP:
>> >>     I2CS |= bmSTOP;
>> >> #ifdef TNG
>> >>     I2CPckt.status = I2C_WAITSTOP;
>> >> #else
>> >>     I2CPckt.status = I2C_IDLE;
>> >> #endif
>> >>     break;
>> >>    case I2C_WAITSTOP:
>> >>     I2CPckt.status = I2C_IDLE;
>> >>     break;
>> >>   }
>> >>  EXIF &= ~0x20;  // Clear interrupt flag IE3
>>
>> >> }
>>
>> >> c) There is a race hazard in main() in fw.c in that as it stands, 
>> >> GotSUD
>> >> can
>> >> be cleared after ISR_Sudav() has set it.
>>
>> >>   if ( GotSUD )            // Wait for SUDAV
>> >>    {
>> >>    //
>> >>    // Swap the order here.
>> >>    //
>> >>    GotSUD = FALSE;       // Clear SUDAV flag
>> >>    SetupCommand();       // Implement setup command
>> >>    }
>>
>> >> d) There are probably others but in general Cypress do not seem 
>> >> willing
>> >> to
>> >> share them with their users for reasons which are, frankly, baffling.
>> >> XXX
>> >> above is to protect a helpful contact in Cypress.  The above problems
>> >> tend
>> >> to occur more if there are lengthy ISR which while never is a good 
>> >> thing
>> >> is
>> >> sometimes necessary.
>>
>> >> Does anyone else have bugs they can share?
>>
>> >> Rgds,
>> >>    Bill Davy
>>
>> > Thanks Bill,
>>
>> > Just wondering, how did you manage to obtain the actual code for these
>> > library functions. Do you have the code for the other i2c functions
>> > too? Also, is the code you show already modified or awaiting
>> > modification? Lastly how can i modify the code? Do I have to write new
>> > functions w/a different name and use these? What about the isr?
>>
>> The code is in C:\Cypress\USB\Target\Lib\Ezusb (i2c.c and i2c_rw.c) on my
>> machine and that included the I2C ISR.
>>
>> There is also EZUSBLIB.h somewhere.  I do think some of the function
>> declarations are wrong (for example, EZUSB_ReadI2C() really returns a 
>> BYTE
>> not a BOOL).
>>
>> The code above is already patched (compare with the originals when you 
>> find
>> them).
>>
>> It would probably result in smaller code if I2C_OK had the value zero.
>>
>> I should probably not have posted the source code above, but it is hard 
>> to
>> describe the changes otherwise.
>>
>> Hope this helps,
>>    Bill
>
> Thanks again Bill. I'm able to find the i2c.c and i2c_rw.c. Would it
> be possible to make the changes in these files and expect the library
> to be updated? I don't have EZUSBLIB.h, but instead I find a EZUSB.LIB
> which I assume is precompiled already.
>


No idea, sorry.  I just build the source files (like 
H:\Husky\Cypress\EZUSB_LIB\i2c.c which I have edited) into my project.  The 
linker drops out unused functions.
Good luck.
Bill

| 1 | 2 | next