On Oct 10, 5:52 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
> "galapogos" <gois...@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

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" <g...@gmail.com> wrote in message 
news:1...@22g2000hsm.googlegroups.com...
> On Oct 10, 5:52 pm, "Bill Davy" <B...@SynectixLtd.com> wrote:
>> "galapogos" <gois...@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
>
> 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. 

I'm new here, but this looks like a bug to me (it's in a sample not a
library): 

void TD_Init(void) 				// Called once at startup
{
   // Enable the SOF and USB Reset interrupts
   USBIEN |= bmSOF + bmURES;

   // Enable the ISO IN endpoints
   INISOVAL = bmEP8;


   // Set up the addresses for the ISO buffers
   IN8ADDR = 0x00;

}

Problem is re-enabling the interrupts before setting up to handle
interrupt if it occurs .... bug? Or am I missing something?

Riley

RileyDeWiley wrote:
> I'm new here, but this looks like a bug to me (it's in a sample not a
> library): 
> 
> void TD_Init(void) 				// Called once at startup
> {
>    // Enable the SOF and USB Reset interrupts
>    USBIEN |= bmSOF + bmURES;
> 
>    // Enable the ISO IN endpoints
>    INISOVAL = bmEP8;
> 
> 
>    // Set up the addresses for the ISO buffers
>    IN8ADDR = 0x00;
> 
> }
> 
> Problem is re-enabling the interrupts before setting up to handle
> interrupt if it occurs .... bug? Or am I missing something?

Perhaps the assumption is that interrupts are masked
globally during system initialization.


-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)

The Beatles were wrong: 1 & 1 & 1 is 1