• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 1706 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

USB Interrupt not Being Preempted by Higher Priority Interrupt (StarterWare & AM1808)

Timothy Eastham
Intellectual 360 points
Other Parts Discussed in Thread: AM1808

Presently, I have GPIO bank 8 interrupt set to channel priority 2.  I have the USB interrupt set to 4.  The UART is set to priority 7.  I am doing this with the command IntChannelSet().  What I am seeing with a logic analyzer is that for some reason the USB interrupt is not being interrupted by the GPIO interrupt.  This is bad because the GPIO interrupt needs to occur on a 10hz cycle because I have an ADC using it to signal a conversion completion.  I am testing this with the logic analyzer by toggling a memory location when I enter and exit each interrupt.  I have a memory location toggle in the GPIOIsr() and one in the USB0DeviceIntHandler() functions.  When I monitor the memory locations and compare them to the GPIO pin toggle from the ADC, I am seeing that sometimes the USB interrupt takes a while to finish.  During these long stretches, a GPIO trigger occurs but the CPU waits until the USB interrupt finishes before it services the GPIO interrupt.

I searched my project for IntChannelSet and found the following:

IntChannelSet(SYS_INT_TINT12_0, 3);

IntChannelSet(SYS_INT_TINT34_0, 5);

IntChannelSet(SYS_INT_GPIOB8, 2);

IntChannelSet(UART_INT, 7);

IntChannelSet(SYS_INT_USB0, 4);

If I understand the architecture properly, this should mean that my GPIO8 interrupt service routine should preempt any of the other interrupts.  Has anyone seen this issue or have advice as to why this might happen?  I am using the AM1808 and coding with StarterWare 1_10_03_03, TMS470  5.0.1 compiler, and CCS5.

Thanks!

  • 0
    TI__Intellectual 1640 points

    Hi Timothy,

    AM1808 Starterware does not currently support nested interrupts . What this essentially means is that, the exception handler code  (exceptionhandler.S) does not jump to the highest priority Interrupt after saving the required registers.

     Please note that the AM18x architecture ( HW) does have a support for nesting of interrupts  ( Refer Am18x TRM section 11.3.7 Interrupt Nesting).

     You may also refer to the file [ ..\StarterWare\system_config\armv7a\am335x\gcc\exceptionhandler.S] inorder to get an idea of how to modify the exception handler for your AM18x platform.

     

  • 0 in reply to Vineeth Balan
    Intellectual 360 points

    Is the FIQ treated differently or is Sujith wrong in the thread below?

    http://e2e.ti.com/support/embedded/starterware/f/790/p/182872/660788.aspx

  • 0 in reply to Timothy Eastham
    Intellectual 360 points

    It would be difficult for me to understand this assembly code.  Will I just be able to copy the AM335x IRQHandler code and replace the existing AM18xx IRQHandler code with it?

  • 0 in reply to Timothy Eastham
    Intellectual 360 points

    I really really need this resolved.  Is there a way to get this implemented?  Is there a mechanism about which I can get this custom code added by TI?

    A realtime system without nesting for higher priority does not seem very useful.  Do most other developers with StarterWare and the ARM9 just do simple projects that don't have isochronous requirements in the interrupt system?  Even a high resolution timer would cause difficulty under this issue.

    Thanks,

    Tim

  • 0 in reply to Timothy Eastham
    TI__Intellectual 1640 points

    Hello Timothy,

    I agree that it might not be an easy task to implement a nested IRQ handler. Since you have asked for routing the necessary interrupt as an FIQ interrupt , you would need to configure USB interrupt to be routed through channel 0 or 1 . You can refer AM1808 TRM section 11.2 Interrupt mapping( version SPRUH82A–December 2011) for the same.

    To do this you would

    • need to enable FIQ interrupt  in the code by calling  IntFIQEnable ()  and IntMasterFIQEnable () . Then route USB interrupt through channel 0 or 1 ( FIQ channels) using the IntChannelSet () function . ( file : ..\StarterWare\system_config\armv5\am1808\interrupt.c)
    •  IntChannelSet ( SYS_INT_USB0 , 1) // map USB interrupt to be an FIQ interrupt.
    • increase FIQ stack size from 0x8 to say 0x100 (..\StarterWare\system_config\armv5\gcc\init.S )

    I have given you a big picture on how to enable the FIQ interrupt and you would probably need to refer any of the USB example files to check out how AINTC is currently being configured.  

    Please note that we have not tested the FIQ handler to the full extent ,also using a higher priority FIQ interrupt would impact all timing routines .  

     

  • 0 in reply to Vineeth Balan
    Intellectual 360 points

    I gave up on working this out as an interrupt.

    I am now running the USB on the main thread.  To be honest, I have had more versatile 186 chips at handling interrupts than the AM1808.

    For right now, this seems to be working for me.  Hopefully, I won't find any other needed peripherals in the future that expect nesting because of their huge ISR demands but don't get support for it because the software doesn't handle it...

    Thanks to the guys at CriticalLink (http://www.criticallink.com) for suggesting moving the USB to the main thread.

    Tim