Skip to main content
RBoer
RBoer
Associate II
August 9, 2019
Question

F103 USB HID works when not debugging (swd)

  • August 9, 2019
  • 3 replies
  • 1451 views

Hello,

​

I'm trying a really simple HID mouse-moving example (https://notes.iopush.net/stm32-custom-usb-hid-step-by-step-2/) and if I connect my bluepill via usb to the computer (macOS), as expected, it connects and the mousecursor slowly drifts to the right. All fine.

​

​Now I'd like to set some breakpoints to follow the program flow and understand better what is happening, but when I run from the debugger (CubeIDE + stlink v2, via SWD) the bluepill doesn't connect with the PC. It goes through the mainloop with dev_state being a few times USBD_STATE_DEFAULT (the else part) and after that always through USBD_STATE_SUSPENDED.

​

The mainloop does something like this:

	counters[hUsbDeviceFS.dev_state]++;
 
	if (hUsbDeviceFS.dev_state == USBD_STATE_CONFIGURED)
	{
	 mouseHID.x = 10;
	 USBD_HID_SendReport(&hUsbDeviceFS, &mouseHID, sizeof(struct mouseHID_t));
	 HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13,GPIO_PIN_RESET);
	 HAL_Delay(100);
	}
	else if (hUsbDeviceFS.dev_state == USBD_STATE_SUSPENDED){
	 HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13); //Toggle the state of pin PC9
	 HAL_Delay(10);
	}
	else if (hUsbDeviceFS.dev_state == USBD_STATE_ADDRESSED){
	 HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13); //Toggle the state of pin PC9
	 HAL_Delay(100);
	}
	else {
	 HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13); //Toggle the state of pin PC9
	 HAL_Delay(50);
	}

​

I found a post which looks like it's the same issue (https://community.st.com/s/question/0D50X00009XkXyVSAV/usb-cdc-dont-work-in-debug?t=1565295850752 and https://hackaday.io/project/19799/logs) but calling "USB_DEVICE_MasterHardReset"-workaround doesn't seem to work (anymore?) since it gets into an endless loop in HardFault_Handler.

​

Maybe after the call to change the pin + delay, the pin has to be "restored" to whatever it was set to initially, but I can't see to find any code which does an initial configuration for GPIO_PIN_12...?

​

Any ideas, anyone?

This topic has been closed for replies.

3 replies

Tesla DeLorean
Tesla DeLorean
Guru
August 9, 2019

Don't expect to break-point code with real-time expectations. Instrument it so you can observe the flow and interactions. Use a serial port, or the SWV debug channel.

Have your Hard Fault Handler output actionable information so you can diagnose the failure.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
RBoer
RBoerAuthor
Associate II
August 10, 2019

Tried SWO and couldn't get it to work with the 405. Could see 'movement' on the oscilloscope (which stopped when breaking) so something definitely was being transmitted. Assumed I had to enter the "core clock" but that didn't work, so tried all Mhz which were listed there, none worked - but some of them were spewing garbage-output (results were wrong - but consistently wrong, which reminded me a lot of serial communication on wrong baudrates)...

​

Tried with my 411RE nucleo and worked instantly on 16Mhz... Tried a few 'random' other values and (as expected) got garbage.

So then started at 1Mhz and tried in 1 Mhz increments with the F405 board and voila, at 51Mhz-53 Mhz it worked... interesting...

​

Determined the difference and that made me realize the HSE-clock in the clock settings was 25Mhz... while my board only has an 8Mhz crystal..:flushed_face:

So entered that, fixed the other clock settings, that resulted in a 72Mhz core clock. Use that in the stlink-swo viewer and that matched perfectly.

​

With the new settings, tried running the "move the mouse a bit" program and that worked fine now ( even when running with a debugger attached... nice!)...

That was my original goal, using the f103 to home in on why it wasn't working.

​

Fun things, the question of this post remains unanswered... :D I'm still wondering why the F103 doesn't connect to usb (even if not triggering breakpoints) when running with a debugger attached?

RBoer
RBoerAuthor
Associate II
August 9, 2019

By default there is a breakpoint on startup in main. I found where to disable that (debug-as/debug configurations/startup-tab/set breakpoint at: main) so it runs in the debugger without ever hitting a single breakpoint which could disturb program flow. It still does not connect, so "something" is different with attached debugger.

​

I understand that the moment a breakpoint is hit, the realtime behaviour is going to change (and likely break the program flow / cause usb-disconnects shortly after that - which is fine); My expectation was to set a breakpoint in e.g. the if-statement with "USBD_STATE_CONFIGURED" so that I can see if it was entered (at all) and look at some variables.

Background is that I'm trying to get this to work on an F405 and I'd like to get a first impression of which interrupts are at all triggered by doing a few runs, and seeing if those hit - at all - on the F405).

​

SWV sounds interesting, going to look into that this weekend. Wanted to keep it super-simple, but if this generally doesn't work, then I guess I can indeed log some more details on program flow, via serial or swv.

Pavel A.
Pavel A.
August 10, 2019

>  but when I run from the debugger (CubeIDE + stlink v2, via SWD) the bluepill doesn't connect with the PC.

The host computer expects that USB device responds to various requests quickly, else it will fail the device.

So if you break into debugger in the middle of enumeration, it won't end good. Let it run at full sped, at least until end of enumeration.

I don't have a MAC but heartily recommend Windows 10. It displays device status very good and often provides helpful clues what it does not like.

-- pa

Terms & ConditionsAccessibility statement