Memory leak in MQX USB Host stacks?

Showing results for 
Search instead for 
Did you mean: 

Memory leak in MQX USB Host stacks?

Specialist II

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?



Labels (1)
Tags (1)
0 Kudos
1 Reply

NXP Employee
NXP Employee


the memory leaks caused by stack are almost impossible.


Can you check what is the used memory when inserting for the first time and for the second time? Can you check the usage of your tasks stacks plus interrupt stack usage?




0 Kudos