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
Inputs:
Outputs:
Notes:
******************************************************************************/
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;
}
else
{
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?
Thanks.
