nRF51822 Linux Driver Source Code

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • nRF51822 Linux Driver Source Code

    Hi,
    We got two nRF51822 development kits. We are able to set them up to work on Linux environment by installing Segger's Linux drivers for nRF51822 USB-dongle.
    The problem here is, at present we are able to send and receive data to/from nRF51822 via Segger's driver from the Linux User Space only, but our requirement is to access nRF51822 from the kernel space.

    This may need Segger's nRF51822 USB-dongle Linux driver source code. How can I get the same ? Please suggest ?
    If getting source is not possible, is there a way to access the device from the kernel space (from a kernel module) ?

    Thank You.
  • Hi,

    This may need Segger's nRF51822 USB-dongle Linux driver source code. How can I get the same ?

    You won't. The J-Link software is not open-source (and this is good, since we also have to subsist on something...)

    If getting source is not possible, is there a way to access the device from the kernel space (from a kernel module) ?

    Why do you see that you are needing this?
    So far, I do not see why you would. Could you please clarify?


    Best regards
    Alex
  • Hi Alex,

    Thanks for responding.

    I have a loadable kernel module from which I want to send and receive data to/from nRF51822. So, as the device is only accessible from user space, for transmit path, I have to send my data from kernel-space to user-space via some mechanism and then to the device's UART. And for data reception, I have to receive from the device's UART in user-space and pass it on to the kernel-space.
    As the user-space is involved, it is leading me to some unpredictable latencies as user-space has lower priorities when compared to kernel-space.

    So, I want to eliminate this kernel-space to user-space and vice-versa interaction. Being able to access the device from kernel-space will resolve my problem.


    Thank You.
  • Hi,

    I get your point but unfortunately, currently this is not possible.
    Anyhow these delays should not be really a problem regarding loss of data.
    a) J-Link implements a buffer on the firmware side for read/write VCOM data
    b) The J-Link OBs on the nRF51 kits make use of hardware flow control, so no data should be lost even in case the buffers on the J-Link side get full due to delayed flush requests from the PC.


    Best regards
    Alex
  • Hi Alex,
    I completely agree with you that there wont be any kind of loss of data.
    Currently, I am trying to open the virtual UART from the kernel-space for the modularity sake (latencies will be the same as earlier, but wanted to eliminate direct user-space interaction). Yet to see if I can succeed in this approach.

    Thanks for your support throughout and btw, I like it when you said "since we also have to subsist on something...". And that's absolutely right.
  • Hi Alex,
    We observed one issue with nrf51822/Segger Linux driver; Upon Linux bootup, the device (/dev/ttyACM0) doesn't work (read unblocking) properly for the first time. But, when I plug out and plug in again, both read and write works properly. In the first time case, device open and write are successful, but read just doesn't unblock even though there is data. And the same works well for the second plug-in.

    Firs time dmesg log:

    [ 178.611363] usb 1-1.2: new high speed USB device using ehci_hcd and address 5
    [ 178.704505] usb 1-1.2: configuration #1 chosen from 1 choice
    [ 178.754109] cdc_acm 1-1.2:1.0: This device cannot do calls on its own. It is not a modem.
    [ 178.754179] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
    [ 178.754467] usbcore: registered new interface driver cdc_acm
    [ 178.754470] cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters

    Second time log:

    [ 228.263821] usb 1-1.2: new high speed USB device using ehci_hcd and address 6
    [ 228.356966] usb 1-1.2: configuration #1 chosen from 1 choice
    [ 228.357174] cdc_acm 1-1.2:1.0: This device cannot do calls on its own. It is not a modem.
    [ 228.357242] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device



    Did you by any chance come across this kind of issue ?

    Thank You.