This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Question about the USB CDC ACM Example

Hi, before buying the PCA10056 kit, I have some questions about the USB CDC ACM example.

  1. I'm new to the USB CDC ACM.

At the Infocenter, it says that

This example shows how to use the CDC ACM USB class, commonly known as Virtual COM port.
The port can be opened and closed just like a traditional serial port.
Using a terminal emulator, for example putty,
send test data from the host computer to the development kit. LED 3 will blink.

COM

Does this mean that the nRF52840 can transfer or receive UART data without adding extra UART-USB ICs like FT232R?

If I use the USB CDC ACM example, can I read or write after I open the port from PuTTY just like using the UART example?

  1. When reading the sdk_config.h file, I couldn't find what pins are used for this example.

In the case of nRF52832-QFAA, the NFC1 and 2 pins were fixed to pin 11 and 12.

What about the nRF52840 and what pins are used for this example?

Is it the UART0 module used for the example, since it is enabled in the header file, and use pin 13 and 14?

Also, can I use any pins, except the power pins, to configure it as an USB related pins using PPI?

USB

  1. Currently, I believe this example uses the USB connector that is connected the J-Link MCU, the Atmel MCU.

However, when creating a custom PCB which is related to Li-PO USB charging such as the BQ25010, I won't populate the J-Link MCU.

D+-

In this case, how should I configure my schematic wirings to connect the nRF52840's pins directly to the USB connector (D+/D-) when supplying 3.3 volts to the nRF52840?

  1. If I want to send a file, a 16KB mp3 file for instance, from the desktop to the nRF52840 MCU and write that data to the flash memory, should I use the CDC ACM example, or something else?

-Best Regards, MANGO

Parents
  • Hi Mango

    1. Yes. The USB interface in the nRF52840 allows it to implement FT232 like functionality without any additional hardware.
      Since the USB interface is fully programmable it can also do a lot more, as you can see by all the different USB examples available in the SDK.
      Just keep in mind that you need to connect to the second USB connector on the nRF52840 PDK to get access to the Nordic USB interface, otherwise you are just connecting to the Segger programming chip. From your terminal program the comport should look like any other, yes, and both read and write is supported.

    2. The USB interface has dedicated pins that are separate from the standard GPIO ports, and they can not be relocated to any other pins. The reason for this is that the USB interface pins require dedicated hardware that would be expensive and impractical to duplicate on multiple pins.

    The physical UART is only used for logging in this example, and the default configuration of UART0 (which allows it to connect to the UART interface in the Segger chip) is printed on the back of the nRF52840 PDK. This is the same configuration that we have always used, even before we got USB support in the chip, and it uses the CDC ACM functionality of the Segger chip to make the UART available on the PC.

    If you want to connect the Nordic CDC interface to a physical UART you could potentially use UART1 for this, allowing you to keep using UART0 for logging and debugging purposes.

    1. The J-Link USB connector is only used for programming/debugging and logging. To connect to the CDC in the Nordic you should add a second USB connection to the USB connector on the side of the kit, closer to the Nordic chip. You can connect both at the same time, or just connect to the Nordic connector (if you don't need logging or debugging).

    Regarding the layout you should refer to the reference schematic.
    As you can see the VBUS, D+ and D- lines should just be connected directly to the connector.

    1. If you want to transfer files you should probably consider the MSC examples instead, as they make the nRF52840 enumerate as a disk drive on the PC side. By default the example is configured to use the external memory chip on the nRF52840 PDK to store the files (showcasing the new QSPI interface in the chip), but it can also be configured to store to an external SD card.

    Edit: I have attached the CDC MSC hands on examples here:
    usbd_msc_cdc_asm_hands_on.zip
    usbd_msc_cdc_asm_hands_on_solution.zip

    Best regards
    Torbjørn

  • My bad, I forgot the repo was private. I have attached the files in my original reply.
    BR, Torbjørn

  • Yes, CDC works on it's own. 
    SDK15.2 SD 6.1 with PCA10056 V1.0.0

    The only difference in porting as per your word document was:

     APP_USBD_CDC_ACM_GLOBAL_DEF(m_app_cdc_acm,
                                cdc_acm_user_ev_handler,
                                CDC_ACM_COMM_INTERFACE,
                                CDC_ACM_DATA_INTERFACE,
                                CDC_ACM_COMM_EPIN,
                                CDC_ACM_DATA_EPIN,
                                CDC_ACM_DATA_EPOUT,
                                APP_USBD_CDC_COMM_PROTOCOL_AT_V250);

    instead of:

    #define CDC_ACM_INTERFACES_CONFIG()                 \
        APP_USBD_CDC_ACM_CONFIG(CDC_ACM_COMM_INTERFACE, \
                                CDC_ACM_COMM_EPIN,      \
                                CDC_ACM_DATA_INTERFACE, \
                                CDC_ACM_DATA_EPIN,      \
                                CDC_ACM_DATA_EPOUT)
    
    
    static const uint8_t m_cdc_acm_class_descriptors[] = {
            APP_USBD_CDC_ACM_DEFAULT_DESC(CDC_ACM_COMM_INTERFACE,
                                          CDC_ACM_COMM_EPIN,
                                          CDC_ACM_DATA_INTERFACE,
                                          CDC_ACM_DATA_EPIN,
                                          CDC_ACM_DATA_EPOUT)
    };
    
    /**
     * @brief CDC_ACM class instance
     * */
    APP_USBD_CDC_ACM_GLOBAL_DEF(m_app_cdc_acm,
                                CDC_ACM_INTERFACES_CONFIG(),
                                cdc_acm_user_ev_handler,
                                m_cdc_acm_class_descriptors
    );

    Is it possible to take a look at this with the new SDK to see if i'm missing something? 
    I will try to upload a project in a few minutes.
     
    Regards,
    Jeff

  • Made a fresh project from usbd_msc included. 
    The other change I noticed is needing the inclusion of:

    // <q> APP_USBD_CDC_ACM_ENABLED  - Enabling USBD CDC ACM Class library
     
    
    #ifndef APP_USBD_CDC_ACM_ENABLED
    #define APP_USBD_CDC_ACM_ENABLED 1
    #endif
    
    // <q> APP_USBD_CDC_ACM_ZLP_ON_EPSIZE_WRITE  - Send ZLP on write with same size as endpoint
     
    
    // <i> If enabled, CDC ACM class will automatically send a zero length packet after transfer which has the same size as endpoint.
    // <i> This may limit throughput if a lot of binary data is sent, but in terminal mode operation it makes sure that the data is always displayed right after it is sent.
    
    #ifndef APP_USBD_CDC_ACM_ZLP_ON_EPSIZE_WRITE
    #define APP_USBD_CDC_ACM_ZLP_ON_EPSIZE_WRITE 1
    #endif

    Attached is the project. Note: I used Segger Embedded Studio.

    Thanks,
    Jeff
    usbd_msc_cdc.zip

  • Hi Jeff

    Are you not seeing the virtual comport at all?

    For me it shows up, but I get an error when I try to connect to it. 

    I looked through your code and tried to figure out what the problem is, but I can't see any critical difference between the original example and yours. 

    I will try to get some feedback from the developer if he has some pointers. 

    Best regards
    Torbjørn

  • Torbjørn,

    I was eventually able to get it to enumerate as a com port but with an error.
    Seemingly changing the APP_USBD_PID to 0x520D the device would allow a removable drive to show up, with no COM port. 
    But with APP_USBD_PID 0x520F it would enumerate a COM port with error: "This device cannot start. (Code 10)" and a secondary 'Other device': nRF52 USB MSC Demo that does not mount as a drive. Photo attached.

    Maybe that's a clue, but I fail to understand how the Product ID would change this behaviour unless the underlying drivers are changing this behaviour. 

    Thank you for the input, looking forward to hearing back from a developer,
    Jeff

  • Hi Jeff

    Sorry for the slow response, I was out in vacation for the last couple of weeks. 

    I tried adding the MSC class to the CDC example (rather than the opposite), but I still have similar issues. I will ask the developer to have a look at my code and see if he can spot the problem, and get back to you.  

    Best regards
    Torbjørn

Reply Children
  • Hi again

    Apparently the problem with my example was a conflict with the interfaces. By changing the interface assigned to the MSC class from 0 to 2 I was able to get it to work:

    DZ122153_190305_usbd_cdc_acm.zip

    Can you please give my example a try and see if it enumerates successfully both the comport and the MSC drives?

    There is a local git repo in the zip, so you can see the changes I have made from the original example. 

    Best regards
    Torbjørn

  • Torbjørn,

    Your thorough response is well worth the wait! :) 

    I was able to run the project you provided. It seems to show up as a COM port and USB MSC as expected. However, I had issues actually trying to use the file storage part of the application. The drive successfully mounted but I wasn't able to write files or open it the drive. 

    It may have been an issue on my side but, when I tried to implement the interface change you listed on my project previously posted, I came across the same results.

    I would be very curious if that portion works on your end.

    Thank you for your extended help,
    Jeff

  • Hi Jeff

    Thanks for the patience and the kind words ;)

    To save some time I didn't copy in all the fatfs functionality from the MSC example when I set up the project. I only copied the basic USB configuration and setup. This is probably the reason why you can't properly use the drives. 

    If you compare the main.c file to that of the usbd_msc example you will see that it runs some fatfs initialization code before the USB is initialized:

    if (fatfs_init())
    {
        fatfs_ls();
        fatfs_file_create();
    }

    Also, there are various function triggered by button presses for doing things like creating new files or listing the existing ones. 

    Please try to copy in this code from the example and see if it works as expected. If you are having issues with it just let me know, and I will take a look myself. 

    Best regards
    Torbjørn

  • Hi Torbjørn

    Hello Sir, I hope this message finds you well. Sir, I have implemented MSC and CDC functionality as per your nice instruction listed in #usbd_msc_cdc_asm_hands_on.zip. When I compile my program, it shows me the Mass storage and also virtual COM port(which I am looking for) but the problem is that when I am trying to open the virtual COM port in putty it shows me an error as you can see in an attached picture. And one other issue is that after some time, both virtual COM Port and Mass Storage got disconnected on their own. I don't know what's the problem, Any help regarding this will be very appreciated.
    I am using nRF5_SDK_17.0.2_d674dde and NRF52840.

    Regards: SamiUlHaq

  • Hi Sami

    Did you test the standard CDC only example? 

    Is this working well while the combined example is not?

    Anyway please open a new ticket on this. The devzone system is not really designed to handle multiple problems in the same ticket. 

    As long as you mention my example I am sure it will be assigned to me ;)

    Best regards
    Torbjørn

Related