• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 33 subscribers
  • Views 777 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Enumeration issues : Reduce memory footprint removing HOST and run from RAM

Pierre Lorent
Prodigy 190 points
Other Parts Discussed in Thread: TMS320F28062

Hi,

I currently work on a product using USB and have some troubles with enumerations. 

Recently, I have updated the USB library from v135 to v151. This helped to reduce the failure rate but resulted in new issues. The library sources v135 were originally copied locally and the files were modified to relocate the USB functions to a "run from ram" section. To do it in a cleaner way with v151, I now preferred to link the .lib file directly to the project to ease future updates. Doing so resulted in the USB functions not being in RAM anymore and a memory footprint of the USB library which seems 3 times larger ... so I cannot afford to place all of it in RAM anymore ...

Initially I thought the linker was including unused content erroneously. See this thread for details. With some help of George Mock, I was able to determine that the module related to HOST mode functionalities seems to be included in the final binary output while I only intend to perform DEVICE mode operations. Below is the analysis of some .map content when not trying to relocate to ram :

map content

I know my predecessor already solved problems similar to the ones I'm having by running the library from RAM. See here. So I really need to be able to do this (It is also much longer to bootload ... :/) 

* How can I configure the library or modify my code such that the HOST related functionalities and any other undesired modules are not included in the binary output ?

* Which modules are most important regarding USB lower layer protocol and should preferably be relocated in RAM if I cannot fit all of it as previously ? (I think to relocate first usbdenum.obj and usbdhandler.obj)

For now, the last version of my project uses the library v151, included as a .lib, running from flash (even for interrupt handlers). The product happen to fail at enumeration after about 40 reboot cycles of the host (without powering down the device). The device is based on a TMS320F28062 and the host is a windows 10 computer. I already observed that during this process, the 5V from the usb does not drop so I cannot reset the USB stack based on this event and on "suspend event" doing more than flushing the buffers seems dangerous ...

My implementation is based on the method described in the "TivaWare™ USB Library User guide" to use the generic bulk device class (par. 2.5.2) and is close to the related example project (usb_dev_bulk) from the control suite. If  someone has any other idea or clues on how to get rid of this, please tell me.

  • 0
    Prodigy 190 points

    For archives, I have not found any solutions to reduce the memory footprint of the USB library in memory BUT managed to find a solution to the enumeration failures.

    First, some functions from the base (non-USB) library of the micro-controller shared the same name as some custom functions and were not detected by the compiler. Resulting in the initialization of the device being potentially incorrect.

    Second, there was a space character in some descriptors of the USB stack, causing apparently a non-deterministic behavior using windows 10. Fields were sometimes missed and sometimes correctly exchanged.

    Given the time spend on this, I stopped searching for more unnecessary optimizations.

  • 0 in reply to Pierre Lorent
    TI__Mastermind 32995 points
    Please concisely detail the specific problems you are facing.

    The linker should not be linking in unused code. To try to eliminate this, make sure you have optimizations turned on, at least -O2 level.

    sal