DTM UART communication through USB port instead of Tx Rx

[Hadi Deknache]

Hi everyone!

I am currently working on a custom prototype that is using the nrf52840 chip and sdk 15, and now want to perform DTM tests on the device. Looking at the DTM example code and description, I see that the application uses 2 pins (tx,rx) in order to perform the UART communication. In my case with the custom prototype board that is not possible since we have not included these pins. Is there any other way to perform the UART communication through the USB port instead. One idea that I am currently thinking of is to implement USB CDC and use that instead, does it sound reasonable and/or are there any other easier way to do that?

Would be very thankful for any help I can get!

/Hadi

[Hadi Deknache]

UPDATE: I have started implementing USB cdc in the DTM example that is available, however, I am facing some problems. When I run my code on the board I can't see any com port appearing. So my question is: Does the USB CDC example require a Softdevice to be programmed on the device in order for the device to work with USB cdc? If so, then I assume that it won't work to integrate both cdc and DTM, since, the DTM application requires that no softdevice is present on the device. Correct me if I am wrong

[Hadi Deknache]

Thanks for the help Torbjørn, I really appreciate it. I have one question regarding the DTM tests. We are going to perform certification test soon: Radio (TX: Mod low,mid,high and carrier & RX: no beacon ) and also EMC with usb traffic, my question is whether it is possible to perform this with the DTM application only or do I also have to use the Radio application?

[Hadi Deknache]

Update 10 Sep:

I have implemented the DTM example instead in the usb cdc example, hoping that this would solve the problem... Unfortunately, the problem persisted and still does not fire the APP_USBD_CDC_ACM_USER_EVT_RX_DONE when data is sent to the DK. It seems like the problem either is that some configuration need to be changed or that there is some bug somewhere that cause the application to forget to call this specific event. The rest of the events are called directly without any problem, except the APP_USBD_CDC_ACM_USER_EVT_RX_DONE event.

Update 10 Sep 3:50 pm:

After some further investigations I finally found the cause of the "problem". The issue seem to be with the buffer of the rx when the data is received. Looking in app_usbd_cdc_acm.c in this function, cdc_acm_endpoint_ev, I notice that in the first switch case for rx:

if (NRF_USBD_EPOUT_CHECK(p_event->drv_evt.data.eptransfer.ep))
    {
        switch (p_event->drv_evt.data.eptransfer.status)
        {
            case NRF_USBD_EP_OK:
                ret = cdc_acm_rx_block_finished(p_inst);
                NRF_LOG_INFO("EPOUT_DATA: %02x done", p_event->drv_evt.data.eptransfer.ep);
                user_event_handler(p_inst, APP_USBD_CDC_ACM_USER_EVT_RX_DONE);
                return ret;
            case NRF_USBD_EP_WAITING:
            case NRF_USBD_EP_ABORTED:
                return NRF_SUCCESS;
            default:
                return NRF_ERROR_INTERNAL;
        }
    }

it checks if the buffer is filled, else it won't trigger the event. When I send 1024 bytes of data, the event was fired directly and printed out all of the data.

My question now is how do I change this in order to continuously receive the data when there is something new sent??? (See answer below!)

Never mind, found where it is initialized and seem to be when the port is opened and we execute the cdc_read function with the size of our buffer:

static char m_rx_buffer[NRF_DRV_USBD_EPSIZE * 16]; /*<--64*16 = 1024*/

app_usbd_cdc_acm_read(&m_app_cdc_acm,
                      m_rx_buffer,
                      sizeof(m_rx_buffer));

Seem that the DK is expecting to receive 1024 bytes before calling the Rx event, in earlier SDK this was no problem and would call Rx whenever there was new data in the buffer :/

Is there any way to trigger the rx done event as fast as I receive any data?

Thanks in advance!

/Hadi

[Hadi Deknache]

Hi,

Apparently since SDK 15.0 there is a new function called  app_usbd_cdc_acm_read_any, which calls the rx done whenever there is new data in the buffer. I have now changed to this function, however, my tests still fail when I run my script. I can see that the bytes are received but when the dtm application performs the tx write, nothing is received on the computer side. Also, I tried manually sending some data and seems that the application stops receiving/transmitting any data after the application have sent the last result. (See updated answer below)

I have attached the most recent code below on dtm+cdc that I am using currently.

Would really appreciate any help I could get on getting the dtm+cdc application to work

Update!

The tests now runs successfully without any problem. I had by mistake changed the rx buffer size to 1 when initializing the variable. I'll upload the code here that works with sdk 15 in case any other would need this in the future...

cdc_dtm_SDK15.zip

/Hadi

[ovrebekk]

Hi Hadi

Good to hear you found the issue, and thanks for sharing the code

I will consider the case closed then. 

Best regards
Torbjørn

[Hadi Deknache]

Hi Torbjørn

Sorry to disturb you, I have a question regarding this application that you uploaded. I have tested mine application and yours also, and it seems like it does not work and is not sending any RF signals on either low, mid or high. I have tested with the original dtm application with tx rx and can see that it works and transmits a signal on the right frequency, however, with the modified example it is not transmitting any signal at all. Did you test your application that it was working? Because I couldn't get it to transmit any signals, neither did it work on the sdk 15.0 application that I made. How did you test it if it worked?

In my application it seems like the problem is when the command is received and then building the uint16_t command, but can't figure out whether it is the cdc read that is the problem or the fifo buffer that is causing this problem.

Best regards

Hadi

[Hadi Deknache]

Hi Again,

I have managed to solved the problem now, however, I am not sure whether it is acceptable that I don't consider this wait function call now. I now concatenate the commands MSB & LSB together and then change a flag that tells that the cmd value was received directly inside the cdc rx handler. In the main function I just call the dtm_put function with the cmd value and send a response back. Is this approach acceptable?

I have attached the latest code here below, would really appreciate if you could tell me whether this approach is acceptable.

Thanks in advance

Best regards

Hadi

cdc_dtm_sdk15.0_latest.zip

[Silvano]

Hi Hadi,

I found this post because I was looking for this exact example combination. Thank you for your hard work doing it. Do you think it would be difficult to make this example work for sdk 15.3?
We you also working on the radio test example + cdc? I am also trying to find that.
I am a hardware engineering and combining these examples is very difficult for me with my basic firmware/programming skills.
If you are working on it would you be able to share it?

[Hadi Deknache]

Hi Silvano,

this is the least I could do to share my code, and I am glad that others will make use of the code.

The changes from 15.0 to 15.3 shouldn’t be that large or even no changes would be required. Usually it is larger changes between major releases but minor updates from 15.0 to 15.3 shouldn’t be that large. I remember that I looked on the 15.3 example and it was the similar code if I recall correctly, however, I did not work on 15.3 so unfortunately have no code to share.

If you want to port it to 15.3 I would suggest to copy all the attached code in my attached main.c into CDC acm example main.c in 15.3 and include dtm to sdk_config.h and the header files in the makefile.

Best regards

Hadi

[ovrebekk]

Hi Hadi

I don't think it's a problem that you omit the dtm_wait() function, if that's what you mean?

My main concern looking at the code is what would happen if you dropped a byte, as you could fall out of sync with the update sequence, but I doubt this is a common occurrence in practice. 

Best regards
Torbjørn