Program with sei() hangs after programming due to USB interrupt not cleared

[ferfebles]

It seems that the bootloader doesn't clears the USB interrupts after programming. So, the program hangs just after enabling global interrupts.

It works after reseting or power cycling the board.

It works too if you clear the USB interrupts before enabling global interrupts.

Tested with a fantastic A-Star 32U4 Micro with the next code:

#define F_CPU 16000000
#include <avr/io.h>
#include <avr/interrupt.h>

ISR(TIMER1_OVF_vect) {      // timer1 overflow
  PORTC ^= (1 << PC7);      // toggle yellow led
}

int main(void)
{
  // If next line is commented out, the program doesn't
  // work after programming. You have to reset or power
  // cycle the board.
  // Tested with a Pololu A-Star 32U4 Micro
  USBCON = 0;               // Disable USB interrupts

  DDRC |= (1 << DDC7);      // Yellow led as output
  TCCR1B = (1 << CS12);     // 256 prescaler
  TIMSK1 = (1 << TOIE1);    // Enable overflow interrupt
  sei();                    // Enable global interrupts

  while (1) {}
}

[kevin-pololu]

I suspect this normally isn't an issue if you program the A-Star from the Arduino IDE because the sketch itself uses USB (so it can appear as a COM port to the computer). Since you aren't using Arduino, the problem is probably caused by the USB interrupt trying to run an interrupt handler that isn't defined in your program. We'll keep this issue open and look at fixing it in case we make a new version of the bootloader, but for now, it looks like you've found an appropriate workaround by clearing USBCON.

Have you checked whether this problem also occurs with the stock Caterina bootloader (e.g. on an Arduino Leonardo or Arduino Micro)?

[ferfebles]

I have no other Arduino board, so I cannot check with the stock Caterina bootloader. But there is an old thread in AVR freaks that gave me the clue to solve my problem (http://www.avrfreaks.net/forum/sei-problem), so I think that it happened with other bootloaders.

The workaround is easy, and I understand the problems of fixing and testing code like this. But perhaps it could be added as a comment to the Pololu A-Star 32U4 User Guide.

Thanks for your little board, it's being great fun to use it!

[tekstop]

I am facing the same issue with Arduino Leonardo. I am trying to create a library for Simulink for the new robot and have run into this issue. What would be a workaround for this? Note, as you mentioned, this seems to work fine with the Arduino IDE.

[ferfebles]

What worked for me was

USBCON = 0;  // Disable USB interrupts

as you can see in the code example before.

[tekstop]

Since the code is auto generated, the above workaround isn't feasible for me. Is there any other workaround? @kevin-pololu

[kevin-pololu]

Hi, @tekstop. I think your only options would be one of the following:

• Disable the USB interrupt at the beginning of the program with USBCON = 0
• Define your own minimal USB interrupt handler
• Modify the bootloader to disable the USB interrupt before running the sketch

I have not tried the second and third options, so I am not certain they would work or are practical. The first two options would require you to be able to customize the code generator or edit its output, and the third would require the use of an AVR ISP (in-system programmer) to load the modified bootloader onto the Leonardo.

[tekstop]

Hi @kevin-pololu, thanks for your quick reply! Where can I find the bootloader to modify?

[tekstop]

nvm found it! Thanks for your help! I will give it a try and let you know whether that works!

[NicoHood]

The running USB clock is a known problem of the leonardo bootloader. However this board uses a special bootloader which causes problems for me. It does not work at all with the current IDE. See this: https://github.com/arduino/Arduino/issues/3910

Also the brown out detection at 4.5V keeps me from using the board on an usb hub which normally should work fine. Its in specs, makes somehow sense of course, but is not productive for daddeling.