"galapogos" <goister@gmail.com> wrote in message 
news:1192012974.001363.320180@22g2000hsm.googlegroups.com...
> On Oct 10, 5:52 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> "galapogos" <gois...@gmail.com> wrote in message
>>
>> news:1191981839.069209.21810@50g2000hsm.googlegroups.com...
>>
>>
>>
>> > On Oct 9, 5:13 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> >> "galapogos" <gois...@gmail.com> wrote in message
>>
>> >>news:1191897647.873572.84310@g4g2000hsf.googlegroups.com...
>>
>> >> > On Oct 8, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> >> >> "galapogos" <gois...@gmail.com> wrote in message
>>
>> >> >>news:1191812077.221537.79290@57g2000hsv.googlegroups.com...
>>
>> >> >> > On Oct 5, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> >> >> >> "galapogos" <gois...@gmail.com> wrote in message
>>
>> >> >> >>news:1191398650.239713.117280@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
>
> OK, thanks anyway Bill. You've been of great help. Now if I can only
> figure out how to squeeze more code into the memory...
>


Well worth looking at the assembly code produced from your C code as a first 
step.  There can be some surprises (nice and nasty) and it is a way to learn 
the assembly code too.

On Oct 10, 5:52 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> "galapogos" <gois...@gmail.com> wrote in message
>
> news:1191981839.069209.21810@50g2000hsm.googlegroups.com...
>
>
>
> > On Oct 9, 5:13 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> >> "galapogos" <gois...@gmail.com> wrote in message
>
> >>news:1191897647.873572.84310@g4g2000hsf.googlegroups.com...
>
> >> > On Oct 8, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> >> >> "galapogos" <gois...@gmail.com> wrote in message
>
> >> >>news:1191812077.221537.79290@57g2000hsv.googlegroups.com...
>
> >> >> > On Oct 5, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> >> >> >> "galapogos" <gois...@gmail.com> wrote in message
>
> >> >> >>news:1191398650.239713.117280@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

OK, thanks anyway Bill. You've been of great help. Now if I can only
figure out how to squeeze more code into the memory...

"galapogos" <goister@gmail.com> wrote in message 
news:1191981839.069209.21810@50g2000hsm.googlegroups.com...
> On Oct 9, 5:13 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> "galapogos" <gois...@gmail.com> wrote in message
>>
>> news:1191897647.873572.84310@g4g2000hsf.googlegroups.com...
>>
>>
>>
>> > On Oct 8, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> >> "galapogos" <gois...@gmail.com> wrote in message
>>
>> >>news:1191812077.221537.79290@57g2000hsv.googlegroups.com...
>>
>> >> > On Oct 5, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> >> >> "galapogos" <gois...@gmail.com> wrote in message
>>
>> >> >>news:1191398650.239713.117280@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

On Oct 9, 5:13 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> "galapogos" <gois...@gmail.com> wrote in message
>
> news:1191897647.873572.84310@g4g2000hsf.googlegroups.com...
>
>
>
> > On Oct 8, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> >> "galapogos" <gois...@gmail.com> wrote in message
>
> >>news:1191812077.221537.79290@57g2000hsv.googlegroups.com...
>
> >> > On Oct 5, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> >> >> "galapogos" <gois...@gmail.com> wrote in message
>
> >> >>news:1191398650.239713.117280@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.

"galapogos" <goister@gmail.com> wrote in message 
news:1191897647.873572.84310@g4g2000hsf.googlegroups.com...
> On Oct 8, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> "galapogos" <gois...@gmail.com> wrote in message
>>
>> news:1191812077.221537.79290@57g2000hsv.googlegroups.com...
>>
>> > On Oct 5, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> >> "galapogos" <gois...@gmail.com> wrote in message
>>
>> >>news:1191398650.239713.117280@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

On Oct 8, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> "galapogos" <gois...@gmail.com> wrote in message
>
> news:1191812077.221537.79290@57g2000hsv.googlegroups.com...
>
> > On Oct 5, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> >> "galapogos" <gois...@gmail.com> wrote in message
>
> >>news:1191398650.239713.117280@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?

"galapogos" <goister@gmail.com> wrote in message 
news:1191812077.221537.79290@57g2000hsv.googlegroups.com...
> On Oct 5, 5:51 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> "galapogos" <gois...@gmail.com> wrote in message
>>
>> news:1191398650.239713.117280@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