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 !

[Simonr]

Hi

Can you share some information on what SDK version you're using? Does the application work as expected until you reset it? My guess is that there is some conflicts between the resources used by the USB CDC ACM application and the BLE client. Can you check for example if they are using any of the same timer, UART or SPI instances, causing conflicts there perhaps if you have added them twice. Are there any indications on what's happening when you build and/or flash the example project onto your board, or are these successful with any warnings/errors.

Do you also see this behavior on a Development Kit or just the Fanstel board and a custom board design? Can you share some details on what you did to combine the BLE client and USB CDC applications?

Best regards,

Simon

[RVA]

Hi Simon!

I'm using nrf SDK 15.2.0

softdevice s140_nrf52_6.1.0

The application is running as expected with no errors, means I was able to create central links and also use the usb to send some messages to the host.

I started from ble_app_uart_c (ble_central) and integrated it with usbd_ble_uart  

I never used development kit, tried it with nrf Dongle and Fanstel board based on nrf52840 SoC that include usb connection.

After flashing the application, before I open the host usb port, or activation the ble scanner I'm trying to reset the target with nrfjprog -f nrf52 --reset  --log

I'm getting this error message:

Applying system reset.

ERROR: [  nRF52] - Access protection is enabled, can't read device version.

ERROR: [  nRF52] - Unable to perform system reset. Device is readback protected.

ERROR: [  nRF52] - Try a debug reset instead if possible.

ERROR: The operation attempted is unavailable due to readback protection in

ERROR: your device. Please use --recover to unlock the device.

means that the next time I want to flash the device I must recover it.

Second,

I didn't see any conflicts with instances definition. also commented uart_init() and log_init()

so the main application looks like this :

int main(void)
{
ret_code_t ret;

UNUSED_VARIABLE(m_nus_uuid);

static const app_usbd_config_t usbd_config = {
.ev_state_proc = usbd_user_ev_handler
};

// Initialize.
//log_init();
timers_init(); // init app timers
// Init LEDS
buttons_leds_init();

app_usbd_serial_num_generate();

ret = nrf_drv_clock_init();
APP_ERROR_CHECK(ret);

//NRF_LOG_INFO("\n\nUSBD BLE UART example started.");

ret = app_usbd_init(&usbd_config);
APP_ERROR_CHECK(ret);

app_usbd_class_inst_t const * class_cdc_acm = app_usbd_cdc_acm_class_inst_get(&m_app_cdc_acm);
ret = app_usbd_class_append(class_cdc_acm);
APP_ERROR_CHECK(ret);

//uart_init();
db_discovery_init();
power_management_init();
ble_stack_init();
gatt_init();
nus_c_arr_init();
ble_conn_state_init();
scan_init();

// Start execution.
ret = app_usbd_power_events_enable();
APP_ERROR_CHECK(ret);

// Wait for usb
#if 1
while(1){
while (app_usbd_event_queue_process()){
/* Event was processed. */
};
if(usb_port_open && usb_tx_done){

nrf_delay_ms(4000);
break;
}
}
#endif

// Enable filter
ret = nrf_ble_scan_filters_enable(&m_scan, NRF_BLE_SCAN_ADDR_FILTER, true);
APP_ERROR_CHECK(ret);

// Scan
start_scan(NULL);

// Enter main loop.
for (;;)
{

       if (conn_num == dev_cnt)

        {

         

        }

        else

        {

            while(!discovery_completed){/*Do nothing*/};

            discovery_completed = false;

            scan_start();

        }

        while (app_usbd_event_queue_process())
        {
           /* Nothing to do */
        };

}

// idle_state_handle
}

[Simonr]

Hi

I think you have your answer there, the Access port protection (APPROTECT) is enabled in your application, and you have to disable it using the APPROTECT register (see nRF52840 PS here) to be able to read the flash after it has been flashed like this.

Best regards,

Simon

[RVA]

Hi,

I already tried this option - disable the APPROTECT.

Inside my main I wrote flash by

volatile uint32_t user_data  __attribute__ ((section(".uicr_customer"))) = (uint32_t)(0xFFFFFF5A);

inside of ble_app_uart_c_gcc_nrf52.ld

1. I defined the memory section

MEMORY

{

  UICR (rw) : ORIGIN = 0x10001208, LENGTH = 0x4

  FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0xda000

  RAM (rwx) :  ORIGIN = 0x2000C5B0, LENGTH = 0x33A50

}

2. and added this section of the end of the file

SECTIONS

{

  .uicr_customer : 

  {

    KEEP(*(.uicr_customer))

  } > UICR
}

For a long period it didn't worked out for me, but because you pointed me out back to this solution, I found out a scenario where I was able to activate the debugger. but couldn't open the usb port while the debugging session was active

Scenario as follows:

(This time I used JFlash app instead of using nrfjprog commands)

• erase chip
• program & verify
• Without start running the application.. go to vscode, pushed debug
• The debugger started and stopped at main as expected
• Jflash read memory was ok, UICR value OK (see green mark)
• Continued to run the application in debug mode
• Failed to open the USB port !
• Pulled out and pushed back in the USB
• Run the debugger again - and it failed (same behavior as in the first question)!
• read flash failed - see red marking at address 0x00000000 
  • despite of that UICR value remained 0xFFFFFF5A 

 

summarize the issues:

1. USB connection could not be established while the debugger is running

2. Re-Attaching the USB connection blocks somehow the application from running , and blocks the flash read. 

please advise

 

[Simonr]

Hi

What debugger are you using exactly to debug this device? Does it support the voltage(s) you're running these boards at, and does it power the boards, or is the reason they are crashing when you remove the USB that the board/dongle no longer have enough power to run? As to why the USB port fails to open I'm not sure unfortunately. How exactly are you trying to open the USB port, and what do you see in the program/terminal you open it in?

Best regards,

Simon