Debug OTF_FS_IRQHandler problem

[farsi]

Hi,

in my STM32F4 project, I am trying to make the VCP (on Windows) work.

After initializing USB OTG with the standard line from examples:


    USBD_Init(&USB_OTG_dev, USB_OTG_FS_CORE_ID, &USR_desc, &USBD_CDC_cb, &USR_cb);

The interrupt OTG_FFS_IRQHandler fires, and I end up in the default handler.
Not sure what happens because the device remains attached. What approach could be used to debug this USB problem?

Thanks!

[farsi]

Found some help here already: http://electronics.stackexchange.com/questions/199447/stm32f4-usb-vcp-pc-receive-all-0x00

But not sure, they talk about

// Configure USB Clock Source
RCC_OTGFSCLKConfig(RCC_OTGFSCLKSource_PLLVCO_Div3);

// Enable USB Clock
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_OTG_FS, ENABLE);

[Brutte]

Hi,

in my STM32F4 project, (...)The interrupt OTG_FFS_IRQHandler fires, and I end up in the default handler.
Not sure what happens because the device remains attached.

The default_handler is a stub to redirect IRQs authors didn't bother to implement. So NVIC triggered some IRQ which jumped to default_handler. The problem is there are many IRQs that do the same so it is not possible to say straight away which IRQ source (timer, gpio, USB, uart) did that jump (jumps won't leave trace on stack).

You might provide a unique handler for each IRQ table entry, with a breakpoint inside (asm("bkpt 0x00") to catch the bait.

[farsi]

Thanks, yes, that was the route to success.
Interesting indeed that there seems no "easy" way to catch the stack and/or origin of the interrupt.

[Brutte]

Thanks, yes, that was the route to success.
Interesting indeed that there seems no "easy" way to catch the stack and/or origin of the interrupt.

IRQ vector is just a jump (being strict, an address to "jump" to), not a call so no trace.
B.T.W, the (current) IRQ number active is stored in SCB->ICSR.
 

[8:0] RO VECTACTIVE The exception number of the current executing exception. A value of 0
indicates that the processor is in Thread mode.

However, the core can be allowed to interrupt interrupts so it might get messy because the stack won't tell you the truth. That is why there is also:

[20:12] RO VECTPENDING The exception number of the highest priority pending exception. A value of 0 indicates that there is no pending exception.