• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 102 subscribers
  • Views 1767 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.

Enabing interrupts causes data abort only after reset

David Whitfield86
Prodigy 70 points

When we run our application, it runs and debugs perfectly when run clean (after a power cycle). If we then halt the processor and reset the target, (jump to the reset vector) and run again, we get an exception. The exception happens after we attempt to jump out of the Starterware function which sets up interrupts (in this case USBInterruptEnable).We see the same issue when running Starterware examples on the Beaglebone Black which use both the MMU and interrupts i.E. “uartEdma_Cache”, “usb_dev_bulk”, “usb_dev_comp_ser_ser”, “usb_dev_msc”, “usb_dev_serial”…etc.

Attached is a video on how to reproduce with the Starterware example “usb_dev_bulk” for Beaglebone Black. You can see that when run the first time, there is no exception after the interrupts are enabled. 

I’ve attached a video on how to reproduce with the Starterware example “usb_dev_bulk” for Beaglebone Black. You can see that when run the first time, there is no exception after the interrupts are enabled. 

  • 0
    TI__Guru* 95265 points
    David,

    Sorry for the late response. I can't find the video, can you re-attach? Also, what is the starterware release you used?

    "If we then halt the processor and reset the target, (jump to the reset vector) and run again, we get an exception. The exception happens after we attempt to jump out of the Starterware function which sets up interrupts (in this case USBInterruptEnable)." =======> Please clarify the operation:
    1) you have a usb_dev_bulk example running
    2) halt the A8 core and do a target reset
    3) so you need to reload the same application again and run
    4) exception happened?

    Why you need to do a target reset? Even for this testing purpose, you have to do a target reset, I don't see any relationship in your real uage: bootloader + application.

    In bootloader + application case, what is your boot mode? The way bootloader worked is that it does some SOC intialization, parse the application for start address, load the application (from MMCSD card for example) into memory, then jump into that application, there is no target reset between bootloader and application. So please clarify how this target reset or interrupt issue related to your bootloader + application case?

    Regards, Eric
  • 0 in reply to lding
    TI__Prodigy 365 points

    Hi Eric,
    Sorry for the confusion; I just forwarded the referenced video to you.
    Thanks, RJ

  • 0 in reply to RJ Hall
    TI__Guru* 95265 points
    Hi,

    The video can't be opened using Windows video player with unsupported codec. Can you tell what player is used and my previous questions how target reset related to your bootloading?

    Regards, Eric
  • 0 in reply to lding
    TI__Intellectual 2685 points
    Hi Eric,

    What worked for me was VLC https://www.videolan.org/vlc/
  • 0 in reply to Ahmed Alani
    TI__Guru* 95265 points
    Hi,

    I looked at your video for the operation. I tried the same usb_dev_bulk example from 2.0.1.1 release with those LCD related functions removed. I can see similar UndefInstHanlder issue.

    But is this an issue? For example, if I power cycle the BBB, load another simple example "uartEcho", runs in while() loop, then I do a "restart" and run from main() again, I saw the same AbortHandler issue. So other programs look not be able to "restart" from main() as well.

    My question still: what the purpose of "restart" during USB main loop execution and re-run from the main()? How this related to your bootloader + application?

    Regards, Eric
  • 0 in reply to lding
    Prodigy 70 points

    Fixed the issue by change function USBInterruptEnable(). In this function, USBInterruptEnable() is called before USB0AINTCConfigure(). This means that at a restart, the interrupts are enabled before setting them up. If USB interrupts are enabled then the system is reset, enabling global interrupts will trigger the USB ISR but it has not been set up yet causing an exception.