AnsweredAssumed Answered

Trouble running MQX USB stack from DRAM (K61)

Question asked by Todd Wade on Oct 1, 2013

I'm working on a K61-based product whose main application runs from DRAM.  I use MQX 4.x RTOS, RTCS & the MQX USB stack.

 

I need to use the USB device stack in order to have serial port emulation.  This port will act as the main terminal-mode user interface for the product, so I'm basing my USB code on the CDC demo application.  I've been able to get the stack running on a FLASH-based boot-loader application.  At some point, the boot-loader copies the RAM-based application to DRAM and jumps to it.  The RAM-based application is also MQX-based.  This all works fine, with the exception of the USB stack.

 

The code that configures the USB parts of the processor is identical to that of the FLASH-based boot loader and the rest of the system clocking and configuration is also taken care of by the boot-loader.  I've confirmed that the register values remain the same across execution from the boot loader to the RAM application.

 

When I initially added in the USB stack to the RAM application, I made no changes.  After having trouble and confirming the hardware configuration was the same, I took a shot and relocated the USB buffer descriptors from DRAM to the K61 internal SRAM, at the same location as they were in the boot-loader.  The PC gets further along the enumeration process, in that instead of showing an unrecognized device, it now sees a Virtual COM port.  However, the PC claims the USB device won't start.

 

My application portion of the code has a call-out routine that is invoked at various points along the stack's enumeration process, yet it never reaches the "USB_APP_ENUM_COMPLETE" stage (based on the CDC demo project provided with the MQX USB stack).

 

So, has anyone experienced anything like this?  I'm mystified that relocating the BDT to SRAM made any difference and more mystified by the fact that it doesn't work directly from DRAM.  Could this be related to cache-able regions or something like that?  Or, is there configuration somewhere that assumes the code will run from FLASH and data will be located in SRAM?  Why would it run perfectly well from FLASH/SRAM and not DRAM?

 

Thanks in advance for any help,

 

Todd

Outcomes