USB Lib, MSC Host application hangs when device is removed

Trey,

thanks for the respond, I'm using Concerto F28M35H52C.

I already thought of trying the new V201 driverlib, but I'm always cautious with updates (I`m a software developer myself :-)).

Is there a change log available for the usblib? I couldn't find any fixes regarding my problem in the ###_Software_Quickstart_Readme.pdf

Stefan

All right, I switched completely from Mware V160 to V201 (driverlib, usblib, ...).

It got worse!!

Now my USB-stick (USB Host MSC application) is not detected and the usb-lib hangs in the detection process so I get a reset from my watchdog timer.
The watchdog timer timeout is set to 5 seconds, so there should be plenty of time to react...

Or is there any hookup function for servicing the watchdog in the usblib?

Best regards,
Stefan

Stefan,

There aren't any hookups to enable servicing of the watchdog in usblib, but you shouldn't need it.  There should be plenty of time between when the stack runs for your code to kick the watchdog.

I just tested the example and it does it fact work.  I would recommend you start with the micro USB cable plugged into the controlCARD.  I think the mode detection is turned off in this example and it has problems if the USB cable isn't plugged in when the example boots.

Hi Trey,

I have my own application using the USB lib in the version V160. So far I didn't have any problems with the library. (Except that the default stack size in your USB host MSC M3 example was not large enough to handle data on USB; I have just verified that you have corrected this in the lib V201.)

I think I don't use mode detection as well. No problem if I plug in the USB flash drive when the application is already running. In most times the lib will also detect if the USB device is removed correctly. Just sometimes it stalls, probably when transfering data to/from the flash drive. It also won't detect the medium if it was reconnected again. But that's no problem for me.

My problem:
When I switch the MWare to V201 my applciation stalls when connecting an USB flash drive. If I switch back to V160 everything works fine...
Again: No changes in my application code!

Since I don't have the time to take much effort into that issue I will stick with V160 and don't worry about it. An removal of the USB flash drive shouldn't be done while the bootloader signals activity to the user anyway.

Best regards,
Stefan

Hi Trey,

so my concerns of switching to the new MWARE lib were right... I will check the next "improved" bugfix :-).

By the way: I have finished my bootloader project we had conversation on earlier. It took me more time than I expected but in the end everythink worked out fine.
I wanted to thank your team for the support! It always helped me a lot to get some input for problem seeking/solving. Especially since I am new to this target (and IDE).

Maybe you want to suggest a solution in an app note or in the wiki since everybody in the production will run into that issue?

My solution looks like that:

It consists of two parts, C28 and M3. The part of the M3 resides in Flash, these sections are reserved and can't be used for firmware application.
The part of the C28 is also stored in the flash of the M3 and is loaded to shared RAM S0|S1 at startup.

After reset, the M3 bootloader will be started (reset_isr). It boots the C28 from shared RAM, checks for valid application firmware, update request and either branches to the application firmware or checks for an USB flash media to start an update procedure.

• My Bootloader Application in M3 includes:
  • Your USB lib (with fatfs) for handling a USB flash media (MSC host), my aplication has functions for reading and writing files
  • crc32 checksum calculation for verifying firmware of bin-files and flash (table driven since the concerto uCRC does not support real CRC-32)
  • application functions for handling Metadata concerning firmware build information (this metadata is stored in a 16kB flash section of the ARM)
  • bootloader application of C28 stored as data in Flash, loaded to shared RAM at startup and C28 is reseted(!) and booted using IPC branch command at startup of M3
  • Your Flash API lib and my application functions for handling the flash of the ARM (erase, program, verify)
  • IPC command handler (I created an own simple one):
    • triggering the C28 bootloader for writing, reading and erasing flash, data is transfered in blocks via the 2kByte Message RAM
    • triggering the C28 bootloader for reading/writing GPIO data (user interaction)
  • application functions for controlling the firmware update process (state machines)
  • debug output to UART (printf), additionally writing a logfile to the USB flash media after an update process
  • application functions to flash firmware to an external SPI Flash for the FPGA application of our controller card
  • termination of all bootloader configurations/interrupts, resetting C28 and starting ARM firmware application via branch
    
    
• My Bootloader Application in C28 includes:
  • Flash API lib and application functions for handling the flash of the DSP (erase, program, verify)
  • IPC command handler and application functions for serving the requests of the M3 bootloader

To update my bootloader I have written an application which will be handled like a firmware application. When it is called it will read the new bootloader from USB flash medium and overwrite the bootloader. This is critical since if this fails it could be possible that there is no valid bootloader existent. If a reset happens there could be no valid code at 0x200030 (reset_isr). Or do you have a suggestion that I could branch to the updater application if a reset would occur?

As you see it is quite a complex project. I wasn't awre of that when I started that project...
Maybe this helps someone who is seeking a solution implementing a bootloader.

Regards,
Stefan

Hi,

  Could you please take a look into this. http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/304806.aspx

Thanks in advance 

Thirumoorthy.R