USBD on nRF52840 dongle

RE: USBD on nRF52840 dongle

Gerry — Thu, 06 Feb 2020 22:56:25 GMT

Hi,

I finally found the cause of that problem. DTR of the terminal has to be set, see this post

Thanks for your support anyway.

RE: USBD on nRF52840 dongle

Gerry — Thu, 06 Feb 2020 21:07:29 GMT

Hi,

PuTTY was a good idea. Everything works fine with PuTTY even on the dongle. Sadly, this seems to be the only terminal it's working with. I also have an own PC-application written in c# that works fine with my application on the nRF52840 DK, but not with the USBD BLE UART example.

In the end, I will have to communicate from/to that custom PC-application to the dongle.

Do you have an idea, what could cause this problem? There must be a difference in this virtual com ports right?

RE: USBD on nRF52840 dongle

Einar Thorsrud — Thu, 06 Feb 2020 16:25:50 GMT

Hi,

It is expected that you get the same behavior using a DK and a dongle.

[quote user="gerry"]When I send some characters to the virtual comport the terminal program gets stuck. Could this be a driver issue?[/quote]

I am not sure. Is there a pattern? Always the same number of characters? Or something else?

[quote user="gerry"]I'm using Windows10 and this terminal program[/quote]

It should not matter, but could you test with PuTTY?

RE: USBD on nRF52840 dongle

Gerry — Thu, 06 Feb 2020 01:55:29 GMT

Hi,

I changed this, thanks for the input. The behavior is still the same. I now tried with the original (unchanged) example on a nRF52840 DK and I have the exact same issue. When I send some characters to the virtual comport the terminal program gets stuck. Could this be a driver issue? I also tried another USB-port and uninstalled the driver. When I plug in USB, the driver is installed autom. and shows no errors.

I'm using Windows10 and this terminal program

RE: USBD on nRF52840 dongle

Einar Thorsrud — Wed, 05 Feb 2020 09:22:16 GMT

Hi,

I was not able to reproduce the exact error you describe here. However, I tested now and did get an obvious error when sending data from the PC over the USB-UART (CDC). You have commented out the call to ble_nus_data_send() in the handling of APP_USBD_CDC_ACM_USER_EVT_RX_DONE , but you continue to check the uninitialized ret variable repeatedly. This triggers an error in my test (though it might fail differently or not at all for you, depending on what happens to be in memory).

RE: USBD on nRF52840 dongle

Gerry — Tue, 04 Feb 2020 15:44:14 GMT

Hi,

I now replaced the code for 3.0V with gpio_output_voltage_setup() in components\boards\boards.c and made a chip erase ("Erase all" in SES)

I also tried to toggle an LED in cdc_acm_user_ev_handler. This is really never fired.

After some more debugging, I found, that if I connect BLE with the Nordic UART App. and send some characters, I end up in the nus_data_handler. When app_usbd_cdc_acm_write is called there, it returns 8 = NRF_ERROR_INVALID_STATE

        // Send data through CDC ACM
        ret_code_t ret = app_usbd_cdc_acm_write(&m_app_cdc_acm,
                                                m_nus_data_array,
                                                length);
        if(ret != NRF_SUCCESS)
        {
            NRF_LOG_INFO("CDC ACM unavailable, data received: %s", m_nus_data_array);
        }

could it be a problem of the dongle? I have 2 brand new dongles here. Have you ever tried to run this on a nRF52840 dongle?

RE: USBD on nRF52840 dongle

Einar Thorsrud — Tue, 04 Feb 2020 09:37:10 GMT

Hi,

Diffing your code to the example I do not see anything obvious:

devzone.nordicsemi.com/.../main.c.diff

You disable logging and do not use the BSP (for LEDs). Then you add code for setting the REG0 voltage to 3.3 V to compensate for not calling the BSP code that does this. The BSP implementation sets 3.0 V (see gpio_output_voltage_setup() in components\boards\boards.c), but that should not matter.

How have you verified that cdc_acm_user_ev_handler is never fired when it should? Could it be a problem with optimization or similar? What happens if you try to toggle a GPIO in the event handler?

(One other thing I notice is that the way you check REGOUT0 before setting it, the device would continue to write to it and reset forever if it was for instance set to 3 V initially (last three bits 0x4 which is "100"), since only 1's are converted to 0's when writing to flash). So if you have not performed a full chip erase that might be a problem, as 3 V is used by the firmware it ships with. This does not seem relevant though since it is done at the beginning of main() and it seems the nRF enumerates correctly).

RE: USBD on nRF52840 dongle

Gerry — Fri, 31 Jan 2020 16:33:13 GMT

Hi Einar

Thanks for your support. I've attached the modified example.

devzone.nordicsemi.com/.../usbd_5F00_ble_5F00_uart.zip

RE: USBD on nRF52840 dongle

Einar Thorsrud — Fri, 31 Jan 2020 14:15:16 GMT

Hi Gerry,

It is clear that many things work since the device enumerates correctly on the PC. Can you upload your project here so that I can see what you have modified from the example? I suspect we will find an error there, though I do not have any specific ideas without knowing more.