unable to debug nrf52840 USB CDC ACM built on BLE client application

[RVA]

I'm facing an issue to debug nrf52840 using usb cdc acm application on top of ble client application . Same result when using Fanstel based on nrf52840 connected via usb to the host as well.

1. In most cases resetting the target force a recovery after flashing the application. - Why the target needs recovery ?
2. When running the debugger it returns with exception, 

Core registers:

Disassembly viewer:

Using Cortex-Debug extension for vscode. launch.jason as follows:

{
    "version": "0.2.0",
    "configurations": [


        {
            "name": "Cortex Debug",
            "cwd": "${workspaceRoot}",
            "executable": "${workspaceRoot}/_build/nrf52840_xxaa.out",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "jlink",
            "device": "nrf52",
            "interface": "swd",
            "serialNumber": "",
            "armToolchainPath": "/usr/local/gcc-arm-none-eabi-6-2017-q2-update/bin",
            "svdFile": "${workspaceRoot}/modules/nrfx/mdk/nrf52840.svd",
        }
    ]
}

When I use BLE client application or USB CDC ACM application, the debugger runs without any problems



Please help !

[RVA]

I'm using JLINK + Olimex ARM-JTAG 20-10 adapter , that connected to the target via SWD interface.

The Dongle target is powered by the USB, I'm not using any external power.

I'm opening the port using Putty on my Linux machine.- 

I find the port using the command " ls  /dev/ttyACM* ".

When the application is running (with no debugger) the host recognize the port with no issues,

Else, I get this error message when trying to open it. 

Do you think that my problem comes it low voltage when the debagging is activated? could you please elaborate more about it? and how could I test it? 

[Simonr]

Hi 

The issue requiring a recover before flashing the application again must be because APPROTECT is enabled, and to disable APPROTECT you must first erase the UICR entirely. which can only be done by an erase all (ERASEALL in the Control access port). In practice that is most easily done using "nrfjprog --recover". Note that this will erase entire flash content. There is (intentionally) no way around that.

As to why the COM port doesn't work while debugging the Dongle I don't have any good ideas I'm afraid, but I have asked around internally to see if someone here has any good reasoning as to why this happens.

Best regards,

Simon

[RVA]

Hello Simon,

Will appreciate your response if any idea comes up - thanks for helping!

[Susheel Nuguru]

Hi,

Hi, Simon and most of our R&D team is on vacation until 2nd of January and we are thinly staffed during these holiday season. Please expect delays in response until Simon is back from the vacation. We appreciate your patience and thank you for your understanding

[Simonr]

Hi

Just wanted to let you know that I tried to reproduce this on my end with an nRF52840 Dongle running the USB CDC ACM project, but connecting to the COM port worked fine both with and without a debugger connected to the device.

So again, could it be related to voltage levels on your dongle specifically? USB probably activates REG0 with 1.8V output, but perhaps the debugger forces the VDD voltage to 3V or something on your end. It should work anyways though, but can you check the VDD voltage level on your Dongle with and without the debugger connected?

Best regards,

Simon