cancel
Showing results for 
Search instead for 
Did you mean: 

CubeF4: ADC interrupt corruptes USB FS CDC on STM32F405

Posted on August 12, 2014 at 11:42

I have implemented USB FS CDC on STM32F405 (OLIMEX H405 prototype board) using CubeMX.

A LED indicates (hUsbDevice_0->dev_state == USBD_STATE_CONFIGURED) and a communication with VCP on PC works in both directions.

Now I have added a handling of ADC1 (single channel, continous conversion, no DMA, interrupt) using CubeMX again.

I use Priority Grouping 4 and set the interrupt priority 0 for SysTick, 1 for ADC and 2 for USB.

There is currently nothing in the ADC handler except HAL_NVIC_ClearPendingIRQ(ADC_IRQn) and the interrupt is fired (debugger).

If I do not disable the ADC interrupt (to comment __HAL_ADC_ENABLE_IT(hadc, ADC_IT_EOC) in HAL_ADC_Start_IT(...)) the LED is not getting and USB communication cannot work.

The board is still seen in the Windows Device Manager as enumerated without a problem (no yellow exclamation mark).

Any opinion or advice welcome.

#cubemx-stm32f405-adc-usb-cdc
3 REPLIES 3
jwoolston
Associate II
Posted on August 13, 2014 at 17:45

This may or may not be your problem, but typically USB is not forgiving when it comes to using a debugger. Each frame has expected latency and timing and the debugger essentially always screws that up. The only way to effectively debug with the USB active is with either serial or ITM logging output. If you are not worried about the USB packets failing, then you can use the normal debugger, but if you need the USB to function while you are doing things, its best to avoid it.

Posted on August 13, 2014 at 21:01

Thank you for an opinion. Yes, USB cannot be debugged on-the-fly.

It is not this case - of course, I let the code running freely but USB did not configure itself.

jwoolston
Associate II
Posted on August 13, 2014 at 21:07

No problem. I only bring it up because you mentioned the debugger in reference to knowing your interrupt fired. Hopefully someone else can provide greater insight.