• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 441 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.

IntDisable/Enable in USB-CDC-Example

qxc
Genius 5820 points

Hi,

in USB-CDC example for BeagleBone Black there is a strange construct:

ulIntsOff = IntDisable();
IntEnable(ulIntsOff);

This disables and then re-enables ALL interrupts of the whole system, so any other interrupt is influenced too. This happens on USB connect- and disconnect-events. What is the purpose of this? Shouldn't it be done for the USB-interrupts only and not for all IRQs? With the current code this influences timing of the whole software running on the board.

  • 0
    Guru 26430 points

    Looks like you are out in the wilderness on this one. No expert on this. My 2 cents. I think you could remove all that code from usb_dev_serial.c. Not so about any other places like usbringbuf.c. In usb_dev_serial.c, the interrupt code enstablishes critical sections around global variable that track update messages.

    volatile unsigned int g_ulFlags = 0;

    char *g_pcStatus;


    ControlHandler()
    {
    ...
      ulIntsOff = IntDisable();
      g_pcStatus = "Host connected.";
      g_ulFlags |= COMMAND_STATUS_UPDATE;
      IntEnable(ulIntsOff);

    ...
    }

    main()
    {
    ...
      while(1)
      {
        if(g_ulFlags & COMMAND_STATUS_UPDATE)
        {
          Intstatus = IntDisable();
          g_ulFlags &= ~COMMAND_STATUS_UPDATE;
          IntEnable(Intstatus);
          DisplayStatus(&g_sContext, g_pcStatus); // Missing from BeagleBone version.
        }
    ...
    }

    - The IntDisable()/IntEnable() in ControlHandler() might be pointless as I think ControlHandler() executes in an interrupt context.
    - The main() critical section is flawed as g_pcStatus is accessed outside of the critical section. That variable could be changed the ISR prior to access.
    - The BeagleBone version does not update a display at all. No need to maintain the USB status for display. It is telling that the Beaglebone does not have the UART status code that other platforms have.