Hello,
I test NRF52840 with connectivity firmware with SoftDevice s132, API V3. Adapter is opened successfully and all Adverts are parsed properly. Problem is when devices are connected together, after several notifications uC hangs out and no more notifications is received.
I am using nrf52840 Develpoment kit and Intel Edison.
BR
Kaaml
Hi,
How are you interfacing with the connectivity firmware? Is there any specific reason you are using s132 with nRF52840, and not s140?
Can you post code snippets showing what you are doing, and what is happening when you stop receiving notifications?
Best regards,
Jørgen
Hi Jørgen,
We had to postpone work on hardware upgrade to nRF52840 due to work load. Yesterday, we did another try with pc-ble-driver-js 2.5 release and we get exactly the same problem as described by Kaaml before.
I've tried to investigate this further, behaviour on the application layer is as explained before,- we're receiving notifications for a while and after some time (random) application hangs.
It looks like the pc-ble-driver doesn't receive HVX events at serialization transport layer serialization_transport.cpp#L179. That's why I believe that the problem is related to the connectivity firmware, maybe something to do with events buffering before sending via USB. We're using s132 because v3 is the latest driver which pc-ble-driver-js 2.5 release supports.
I've also tried to compile source from the pc-ble-driver-js master branch together with pc-ble-driver 4.1.0 release but for some reason nRF52840 development board doesn't appear as /dev/ttyACMx after flashing connectivity_4.1.1_usb_with_s132_3.1.0. Do you have any suggestion why this happens?
-- Update:
I found out why connectivity 4.1.1 didn't work before,- I was using modified dev board (no connection to external flash). I took other board and device appear as /dev/ttyACMx now.
I compiled pc-ble-driver-js from the master branch but there is still the same issue - application hangs after receiving random number of notifications. In our application peripheral is sending 144000, in 3 tests application hang after 134640, 95328, 107280 bytes.
-- Update 2:
To confirm I tried to use UART interface instead of USB CDC by flashing standard connectivity firmware to nRF52840 dev board. The application works fine in this configuration. In our hardware we'll add option to select between UART and USBD - we will use UART initially and then switch to USBD when a fix is available.
Best regards,
Krzysztof
Hi Jørgen,
We had to postpone work on hardware upgrade to nRF52840 due to work load. Yesterday, we did another try with pc-ble-driver-js 2.5 release and we get exactly the same problem as described by Kaaml before.
I've tried to investigate this further, behaviour on the application layer is as explained before,- we're receiving notifications for a while and after some time (random) application hangs.
It looks like the pc-ble-driver doesn't receive HVX events at serialization transport layer serialization_transport.cpp#L179. That's why I believe that the problem is related to the connectivity firmware, maybe something to do with events buffering before sending via USB. We're using s132 because v3 is the latest driver which pc-ble-driver-js 2.5 release supports.
I've also tried to compile source from the pc-ble-driver-js master branch together with pc-ble-driver 4.1.0 release but for some reason nRF52840 development board doesn't appear as /dev/ttyACMx after flashing connectivity_4.1.1_usb_with_s132_3.1.0. Do you have any suggestion why this happens?
-- Update:
I found out why connectivity 4.1.1 didn't work before,- I was using modified dev board (no connection to external flash). I took other board and device appear as /dev/ttyACMx now.
I compiled pc-ble-driver-js from the master branch but there is still the same issue - application hangs after receiving random number of notifications. In our application peripheral is sending 144000, in 3 tests application hang after 134640, 95328, 107280 bytes.
-- Update 2:
To confirm I tried to use UART interface instead of USB CDC by flashing standard connectivity firmware to nRF52840 dev board. The application works fine in this configuration. In our hardware we'll add option to select between UART and USBD - we will use UART initially and then switch to USBD when a fix is available.
Best regards,
Krzysztof
