LPC1343 USB MSC ROM with Timer32B0 interrupts

[lpcware]

Content originally posted in LPCWare by S3rd on Mon Feb 28 19:32:42 MST 2011
Hi all,

I have a issue with USB connection failing if interrupts are active during the first 400ms or so of the connection.

I am using a EA LPC1343 Quickstart board, and have implemented a single read only file MSC device using the internal USB ROM drivers.  All this seemed to work fine until I enabled the Timer32B0 capture input and interrupt to process a real world signal.  The signal has frequency of 100Hz and the interrupt is about 4us in duration, so not much CPU time used at all.

It seems that the only way I can get the USB MSC device to connect correctly is to remove the input signal or disable the interrupt during the first 500ms of USB connection.  After that the file can be opened fine.

I'm guessing that there is some poled timing going on in the USB ROM code that is getting out of sync during initial negotiation if time is lost in other interrupts?

Can anyone provide any clarifaction on how  this ROM code works? And whether I need to always make sure interrupts are disabled during initial USB negotiation?

Best Regards
Simon

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Sat Mar 05 02:19:44 MST 2011
Normally, these sorts of issues are because you haven't used "volatile" on variables that are volatile. For example:

int i ;
for(i=0; i<1000; i++)
  ;

will be completely optimized away by the compiler for -O1 and -O2. However:

volatile int i ;
for(i=0; i<1000; i++)
  ;

will increment i from 0 thru 999 whatever level of optimization you have.

[lpcware]

Content originally posted in LPCWare by S3rd on Fri Mar 04 23:57:09 MST 2011
I had looked at the listing and all looks good.  I think there is a timing issue or compiler issue as I have found today that it works fine if I use optimisation levels 1 or 2 (-O1 or -O2) for the compiler setting.  -O1 seems a good setting as I can still get reasonable debug info out.

Simon

[lpcware]

Content originally posted in LPCWare by domen on Fri Mar 04 00:09:48 MST 2011
Check with objdump if your application is using that code area? And if yes (simplest explanation for this problem), then fix the linker file.

[lpcware]

Content originally posted in LPCWare by S3rd on Thu Mar 03 19:02:35 MST 2011
Hi all,

Still no luck with this one.  I have some more info on this issue after spending another couple of days on it and looking at the packet data from my USB protocol analyzer.

From reset if I delay enabling the Timer32B0 CAP0 interrupt a second, then the MSC drive is loaded and the file can be opened.  As soon as I add the 100Hz signal to the CAP0 input P1.5 and either restart without the 1 second delay, or drop the connection with a call to
(*rom)->pUSBD->connect(FALSE);
followed by
(*rom)->pUSBD->connect(TRUE);
after over writing my files data the USB Get Descriptor: Device command returns 64 bytes of what looks like garbage to the PC.  (E1 E1 2E E7 6E 70 B8 4F etc...

When things are working correclty the Get Descriptor: Device command returns 18 bytes
(12 01 00 02 00 00 00 40 4E 21 01 01 10 00 04 20 48 01) as expected.
Some how the timer interrupt is causing points to get messed up.  I've lowered the prioity of the timer interrupt to no effect.

I did notice that the msdstate variable at 0x10000054 is always 0 when breaking after failure.  I have attached a dump of RAM between 0x10000050 and 0x10000180 of each case as there are a few differences.  Maybe those that know a bit more about the ROM code can see the issue?

Is there anyway to debug the ROM?  I'm using Code Red tools.

Simon

(