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.

RTOS USB

Other Parts Discussed in Thread: SYSBIOS

Hi I am using TIVA C for an application with USB  and RTOS.

I have developed the application in two phases so first the application was only USB Host and then it became also Device.

While I was developing the application as HOST I used :

usbmschfatfsHandle = USBMSCHFatFs_open(Board_USBMSCHFatFs, USB_DRIVE_NUM, &usbmschfatfsParams);

to get the handle and I was able to read/write on a USB stick.

Then I developed the DEVICE part where I have defined the USBHandler in the *.cfg file for the interrupt 60.

The device sw was working fine.
When I have integrated the two parts and I use the USB i HOST mode again, the USBMSCHFatFs_open crash.
Looking for the  problem root cause I found out the function actually recreate the Hwi and so I have this error:

{module#53}: line 138: E_alreadyDefined: Hwi already defined: intr# 60

If I remove the USBHandler in the *.cfg...the SW is back to normal behavior.

Consider that I started the app as HOST using the fatsdusbcopy from TI examples. This example is for RTOS but the Handler for int. #60 is not defined in the *.cfg...

I am trying to understand what is the best way to manage this issue, any suggestions? examples? link?


Thanks!

  • Any comments/helps on this point?

    Thanks
  • I have tried to define the HWI in run-time for the device application... instead to use the cfg file, I used this code:

    Error_init(&eb);
    Hwi_Params_init(&hwiParams);
    hwiParams.arg = 0;
    hwiParams.enableInt = true;

    hwi0 = Hwi_create(60, (ti_sysbios_hal_Hwi_FuncPtr)name, &hwiParams, &eb);

    the sw crashes....
  • Hi Gianluca,

    Sorry for the delayed response, this post slipped through the cracks.

    The problem you are seeing is because you are trying to create a Hwi for an interrupt vector which has already been created.  The USB reference modules in TI-RTOS create the USB Hwi in the "Mod_init()" API.  Thus, if you create a Hwi for interrupt 60 in the *.cfg (statically created), the code will fail when it tries to create the Hwi at runtime (USB reference module).  

    Although TivaC device support USB OTG (MCU as Host & Device dynamically), TI-RTOS does not support USB OTG and we don't have examples.  If you want this functionality, I would recommend you download the full TivaWare package (link).  It will have example projects as well as documentation you can study to familiarize yourself with OTG.

    Regards,

    -- Emmanuel

  • Thanks for the answer,
    my application is already using TivaWare for the driver usbbulk (that is the reason why the TI-RTOS already defines the Hwi 60) . The problem I see is that I must use TI-RTOS for other features and so I have to make the tivaware drivers and the TI-RTOS compatible somehow. Even if I use the OTG, this won't change the way the Hwi is handled right?

    I realized that probably I did not explain well the problem. I do not need to change the USB mode (host/Device) in runtime...but just at PowerON.

    I understand the problem with the interrupt declared(statically) the re-declared dynamically.

    Looking as suggested to the tivaWare example w/o TI-RTOS, I  see that the USB0DeviceIntHandler or the equivalent(OTG) callback pointer is placed in the vector pointer table. Is it possible to do the same with TI-RTOS in dynamic modality? If so, how?


    Thanks!

  • Hi Gianluca,

    Thanks for the clarification.  Unfortunately I do not know much about the USB bulk or the TivaWare example, but if you need to use the same interrupt vector for bulk, you can close the USBMSCHFatFs driver.  Closing the driver will remove the Hwi, you can then dynamically call Hwi_create() in your application with the interrupt vector and the USBbulk ISR.  Just remember that if you are going to use the USBMSCHFatFs driver once more, you must call Hwi_delete() first.

    Let me know if this makes sense,

    -- Emmanuel

  • Thanks Emmanuel,
    I think I have found a solution, I am doing some tests but so far it works. I have removed the call to the Hwi_create in the USBMSCHFatFs driver and used the callback function USBOTGModeIntHandler in the static Hwi definition. This way in both configuration the callback is the same then the Handler will manage the mode.

    Thanks again for the support.

    Gianluca