• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 100 subscribers
  • Views 369 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.

No Usb0 interrupts after restart and/or reset.

Cor
Intellectual 375 points
Other Parts Discussed in Thread: OMAPL138

I've been working on implementing the starterware USB bulk drivers into our sys/bios system on a custom board based on the OMAPL-138EVM board from logicPD.
So far everything is working after boot up, however when I restart the program or reload the program I stop getting any Usb0 interrupts. Only after a power cycle does the program work.

I've checked the register values when it fails, and it seems that the Usb peripheral is still generating interrupts as USB0DSP_INTMASKEDR.EP0 is 1. The event #19 is also still linked to int6 in DSPINTC0DSP_INTMUX1.INTSEL6 and int6 is enabled in IER.IE06.

The Host-pc detects the device, but fails to enumerate as the device will never respond if it's interrupt is never triggered.

I'm out of ideas what could cause the interrupt service routine to never run after a restart.

Other interrupts, like for example the SPI, are still functioning.

  • 0
    TI__Mastermind 43955 points

    Hi Cor,

    Thanks for your post. This is an important and good question.

    when you mean by system reset, whether it is a power-on-reset or warm reset? as per this wiki http://processors.wiki.ti.com/index.php/OMAP-L138_Bootloader#During_Reset

     or do you mean module resets such as  syncreset/SwRstDisable?

    Regards,

    Shankari

     

    ----------------------------------------------------------------------------------------------------------

    Please click the verify answer button if this post answer you question.

    ----------------------------------------------------------------------------------------------------------

  • 0 in reply to Shankari G
    Intellectual 375 points

    Hello Shankari,

    Restart is the name of the option in the CCS debugger I use. I assume it's a warm reset as mentioned on the wiki. 

  • 0 in reply to Cor
    TI__Mastermind 43955 points

    Hi Cor,

    In CCS debugger, when you use the system reset option, it can act upon the processor you select at that time. I mean, in the debugging window, it will display both the cores. (DSP +ARM).

    Case 1:

    By default, When you run the ARM only example project, the ARM processor will be in running mode and DSP processor in disconnected mode.

    Case 2:

    When you run the DSP example project, the ARM processor will boot and then it should wake up DSP processor. In your usecase, whether both the processors are in running mode?? and On selecting which core, you tried out the system reset option??

    In CCS, we are not sure about the "system reset" option. The best forum to answer would be CCS forum.

    However, I will try from our end and get back if find anything correct and working with "system reset" option.

     

    Regards,

    Shankari

     

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.
    --------------------------------------------------------------------------------------------------------

  • 0 in reply to Shankari G
    Intellectual 375 points

    I'm working with case 2, but the ARM core is in suspended mode and is not used by the application.

    I've checked the restart option of CCS (the mention of system reset in the first post was incorrect) and it's definitely a warm reset where the register values are not reset. However as I listed in the first post all the reg values indicate that I should be receiving interrupts. Maybe there are other registers that I need to check as well?

  • 0 in reply to Cor
    TI__Guru** 116100 points

    Hi Cor,

    Please refer the following ti e2e posts and TI wiki to understand the CCS resets and its types,

    http://processors.wiki.ti.com/index.php/Emulation_Resets

    http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/302525.aspx

    http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/305366.aspx

    http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/305599.aspx

    http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/305610.aspx

    If you want to reset some particular registers related to any peripheral (say e.g. USB) then my suggestions that add one "hot menu" option in gel file and put appropriate default registers values and Do a reset by selecting that "hot menu" option in "Scripts" option in CCS.

    Try "CPU reset" and "Wait in Reset" in CCS,

    So far everything is working after boot up, however when I restart the program or perform a system reset I stop getting any Usb0 interrupts. Only after a power cycle does the program work.

    Why do you want "system reset" while running DSP app in CCS?

    Any intended reason?

    Flash your DSP app into any media (SPI/NAND/NOR) & reset your board through the hw "reset" button, then test the whether the problem exists (anyway this issue wont come at this time),

    What is your CCS version?

  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 375 points

    The system reset mentioned in the first post was an error, it was supposed to be reloading the program.

    Initially I just wanted to be able to reprogram the device with the debugger without having to go through a disconnect>powercycle>connect sequence every time.

    We're also planning on being able to load in a new program at runtime, however our bootloader is not yet finished so I cannot test that. I was worried that this bug will appear then as well.

    I've been trying different scenarios:

    1 - Powercycled board, connect, load program, run = usb0 int works

    2 - Same as 1 then, break, load program, run = usb0 int does not work

    3 - Same as 1 then, break, cpu reset, load program, run = usb0 int does not work

    4 - Same as 1 then, break, system reset, load program, run = usb0 int works

    5 - Same as 1 then, call USBDBulkTerm(), break, load program, run = usb0 int works

    6 - Added USBDBulkTerm() at init, but did not help.

    Because of situation 5 working I can work around it for now, but I still cannot figure out what is causing this behaviour.

    I'm using CCS 5.5, SYS/BIOS 6.35.4.50 and OMAPL138_StarterWare_1_10_04_01

  • 0 in reply to Cor
    TI__Guru** 116100 points

    Hi,

    We're also planning on being able to load in a new program at runtime, however our bootloader is not yet finished so I cannot test that. I was worried that this bug will appear then as well.

    I am sure that, this problem wont occur if you are using bootloader(ARM UBL, If device is OMAPL138)  (bootloader should do the gel file job)

    The system reset mentioned in the first post was an error, it was supposed to be reloading the program.

    Now, I understood your problem,

    I have also faced this unexpected behaviors from some of the projects(In your case is USB) when you are reloading program,

    Starterware code will doing the low level initialization, some of the variables is not getting cleared when you are reloading/loading program without quitting the CCS,

    1) You can disconnect the target(DSP CPU) and connect again then try to load the DSP USB program.

    Because, When you are doing disconnect/connecting the target(DSP) again, the gel will initialize the all peripherals including USB,

    2)

    Anyway, CCS tool is used for debugging purposes and CCS won't be used for product release, So better to use ARM UBL code to wakup the DSP and call DSP program through entry point.(through flashing those ARM UBL and DSP app in SPI/NAND/NOR flash media)

    http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L138#Booting_DSP_Binaries

    http://processors.wiki.ti.com/index.php/OMAPL138_StarterWare_Booting_And_Flashing

    I'm doing some experiments for this and ll update,