Forums

Cypress EZ-USB help

Started by galapogos October 3, 2007
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.

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.
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
"galapogos" <goister@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
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?
"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
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: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 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: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