AnsweredAssumed Answered

Memory leak in MQX USB Host stacks?

Question asked by Tomahawk_a on Jan 10, 2011
Latest reply on Jan 27, 2011 by Juraj Vanco

I'm developing a project for the ColdFire 52259 (for CodeWarrior 7.2) that uses the 52259 as a USB host for mass storage devices (flash drives), using the "hvac" example project as a basis.  I've gotten pretty much everything to work properly (after upgrading to MQX 3.6.2), but I've noticed something strange while doing some stress testing.  For the stress testing, I'm doing a while bunch of writes to the flash drive (usually around 10 MB in 1024-byte chunks).  So I can do a few writes, and everything looks just fine.  If I do more, everything locks up, and it looks like I overflowed my stack.  So I increased my USB task stack by a factor of x5, and everything worked fine.  "Victory!", I think.  I disconnect the drive (to verify the files in the drive), then plug it back in.  "What happens if I do a few more writes?" I think.  I do a couple more small writes, and it locks up again.


This feels like some sort of memory leak, as if I decrease the MQX task stack, the lock-up occurrs much quicker, and if I increase the task stack, it takes much longer for the lock-up to occur.  My actual code is pretty dumb, as I'm using the 52259 pretty much just as a USB controller.  Here's an example of my writing code:



Function Name: Fiodrivemgr_fwrite_process
static   void  Fiodrivemgr_fwrite_process( void )
   drivemgrFwriteData_t       reqData;
   drivemgrFwriteRespMsg_t    respMsg;
   drivemgrFwriteRespMsg_t*   pRespMsgCopy;
   int_32                     error;

   reqData = *( drivemgrFwriteData_t* )pUSB_DPM;   // get the data from the DPRAM
   error = write( reqData.reqMsg.pFileHandle, ( char* )reqData.writeBuff, ( int_32 )reqData.reqMsg.size );

   // Assemble response message
   respMsg.header.SIZE = sizeof( drivemgrFwriteRespMsg_t );
   respMsg.header.TARGET_QID = reqData.reqMsg.header.SOURCE_QID;
   respMsg.header.SOURCE_QID = reqData.reqMsg.header.TARGET_QID;
   respMsg.msgId = DRIVEMGR_MSGID_FWRITE_RESP;        // populate the structure elements (writing directly to dpram).

   if( error == reqData.reqMsg.size )  // if successful fwrite returns the number of bytes written
      respMsg.error = 0;
      respMsg.error = error;

   pRespMsgCopy = ( drivemgrFwriteRespMsg_t* )pUSB_DPM;  // point to the DPM
   *pRespMsgCopy = respMsg;                              // send the message back through the DPM

   *pUSB_DPM_SLAVE_SEM = DPM_SEM_RELEASE;                // release the DPM
   *pUSB_DPM_SLAVE_MAILBOX = MAILBOX_EMPTY;              // Clear our mailbox
   *pUSB_DPM_MASTER_MAILBOX = YOUVE_GOT_MAIL;            // let the primary processor know about the message (triggers interrupt)
}  // end Fiodrivemgr_fwrite_process


Like I said, it's pretty dumb.  I've scanned my code for any kind of "*alloc", and there aren't really any.  Anyone have any suggestions?