Sysprogs forums › Forums › VisualGDB › STM32 USB CDC Demo is missing an interrupt handler
- This topic has 7 replies, 2 voices, and was last updated 8 years, 9 months ago by support.
-
AuthorPosts
-
March 16, 2016 at 21:46 #7786julianrParticipant
I just got a small STM32F103C8T6 development board and I am trying to get the USB CDC Demo to run. I have no experience with the STM32 processor family (or the STM32 HAL/USB library). The HAL Blinky example works fine. The USB CDC does not. When I debug it the code it always runs to “Default_Handler()”. I defined DEBUG_DEFAULT_INTERRUPT_HANDLERS and now the code stops at “USB_LP_CAN1_RX0_IRQHandler()”. I think there are some parts missing in the template code. I am using the latest version of Visual GDB (5.1 Build 660) and the STM32 BSP Package (3.5).
March 17, 2016 at 23:44 #7799supportKeymasterHi,
Yes, this looks like a bug in our example.
Please try defining the handler as follows:
extern "C" void USB_LP_CAN1_RX0_IRQHandler(void) { HAL_PCD_IRQHandler(&hpcd); }
March 20, 2016 at 13:41 #7814julianrParticipantHi,
I added the interrupt handler you proposed. Sadly the demo is still not working.
The interrupt gets triggered but the PC is not able to enumerate the USB device. The clocking should be fine (I am using the standard settings). The System is running with 72Mhz and the USB with a 1.5 prescaler which should generate the required 48Mhz.
Any Ideas what still might be wrong?
March 20, 2016 at 16:20 #7815supportKeymasterHi,
Yes. Please check that the interrupt handler gets invoked if not, check your USB configuration to see whether it’s initialized properly.
If Windows does not report the device at all (not even as “Unknown device”), the firmware is not enabling the USB functionality correctly. If it’s reported as “Unknown device”, the USB logic is enabled, but cannot handle requests from the PC, indicating either a clocking error or a crash due to something else.
You can also check where the code is running if you stop the application via Debug->Break All.
March 26, 2016 at 11:35 #7834julianrParticipantI got it to work. It was a problem with IRQ priorities. For some reason the SysTick IRQ got a lower priority than the USB IRQ wich means that the delay function was not working since the SysTick IRQ never fired to increase the delay time counter when requested inside a USB interrupt.
I fixed this by replacing the line:
#define TICK_INT_PRIORITY ((uint32_t)0x000F)
with
#define TICK_INT_PRIORITY ((uint32_t)0)
inside the stm32f1xx_hal_conf.h file. I don’t understand the original define anyway. You define a float value with hex notation (is that even possible) and then cast it into an unsigned integer? Why not define it as a integer constant in the first place?
March 26, 2016 at 18:30 #7839supportKeymasterHi,
Good to know it worked. Note that
((uint32_t)0x000F)
does not refer to a floating-point value, it simply defines a priority of 15 (0x0F).March 26, 2016 at 18:52 #7842julianrParticipantThis is very embarrassing… 😳
Of course that is standard hex notation for integer numbers. But this is what happens when you debug unknown code on a hungover Saturday morning before the first coffee…
The problem is still the same. The USB and SysTick IRQ have the same priority and this means the SysTick based wait function is not working inside the USB interrupt handler. You might want to correct this in your demo code together with the missing USB IRQ handler in the next release.
- This reply was modified 8 years, 9 months ago by julianr.
March 28, 2016 at 18:25 #7857supportKeymasterHi,
No problem. Similarly looking things are always easy to confuse. Happens to everyone.
Regarding the priority, we are somewhat hesitant to change the code that comes from ST without testing it on the real hardware, so we’ll probably simply add a big warning in the sample or the tutorial about the interrupt priorities.
-
AuthorPosts
- You must be logged in to reply to this topic.