Debugging via USB (nRF 52833 DK)

(What I want to achieve is to be able to use the USB pins (D+/D-) for debugging on a PCB using a nRF52833 QFN40 MCU. I currently use UART through two regular I/O pins for debugging now, but I want to free those pins so that I can use them for additional I/O.)

I built and flashed the USB CDC ACM Sample Application on an nRF 52833 DK, but it doesn't seem to work entirely well.

The image above shows the response when flashing, and then rebooting (via the button on the DK). COM5 is the USB port I use for flashing to the DK, while COM4 is the additional USB port on the side of the DK, which I try to use for debugging. When I reboot, COM4 becomes unavailable, and it takes anywhere from 30 sec to 4 min before "*** Booting..." and the two following lines are printed in the COM5 window. After those lines have been printed, I can reconnect to COM4. But still nothing is displayed in the COM4 window. Occasionally, the program proceeds further, and then it looks like this:

But still no action through COM4.

I appreciate any input on how to make this work!

Parents
  • Hello

    Have you made any changes to the sample application to reflect what pins you want the uart to use?

    Best regards,

    Einar

  • Hi,

    I have not made any changes to the USB CDC ACM Sample Application. I am simply trying to make this work the way I have understood it should work, writing to and reading from terminal via USB, i.e. pins D+/D- or the USB port on the side of the nRF 52833 DK.

    (And when I get this to work, the next step is to implement USB debugging in my own custom made code. In that code I currently debug via uart, and I have also redirected the uart to the pins I wanted to use. The problem though, is that I am running out of I/O pins. So therefore I want to move debug from uart to USB to make more pins available for I/O.)

    Vidar

  • I see

    Are you using Windows 10?

    There seem to be issues with CDC ACM on Windows 10 specifically:

    https://wiki.segger.com/CDC

    Maybe try in another OS to confirm this is the issue you are seeing?

    -Einar

  • I tried to connect for debugging on a PC running Linux now, but it didn't make any difference. I didn't flash the program again, that was flashed from my Windows 10 PC, but I don't believe that should make any difference.

    I will continue testing on my Linux PC going forward, since there are known issues related to this in Windows 10.

    The program still ends with "Device suspended", as shown above. Indicating dtr was never set within this while loop:

    	LOG_INF("Wait for DTR");
    
    	while (true) {
    		uart_line_ctrl_get(dev, UART_LINE_CTRL_DTR, &dtr);
    		if (dtr) {
    			break;
    		} else {
    			/* Give CPU resources to low priority threads. */
    			k_sleep(K_MSEC(100));
    		}
    	}
    
    	LOG_INF("DTR set");

    I haven't been able to understand the code well enough to understand exactly where the operation fails, but I assume it must be within the uart_line_ctrl_get() call.

    Vidar

Reply
  • I tried to connect for debugging on a PC running Linux now, but it didn't make any difference. I didn't flash the program again, that was flashed from my Windows 10 PC, but I don't believe that should make any difference.

    I will continue testing on my Linux PC going forward, since there are known issues related to this in Windows 10.

    The program still ends with "Device suspended", as shown above. Indicating dtr was never set within this while loop:

    	LOG_INF("Wait for DTR");
    
    	while (true) {
    		uart_line_ctrl_get(dev, UART_LINE_CTRL_DTR, &dtr);
    		if (dtr) {
    			break;
    		} else {
    			/* Give CPU resources to low priority threads. */
    			k_sleep(K_MSEC(100));
    		}
    	}
    
    	LOG_INF("DTR set");

    I haven't been able to understand the code well enough to understand exactly where the operation fails, but I assume it must be within the uart_line_ctrl_get() call.

    Vidar

Children
Related