• State Verified Answer
  • Replies 14 replies
  • Subscribers 74 subscribers
  • Views 2377 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 248656
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf52840: Serialization

CheMax

Hello. Nordic team.

Once again I had questions, this time related to serialization. 

While the preparation of the driver is on the PC side, I am studying the examples described in the documentation. At the moment, I have the following questions:

  1. In the examples, I did not find mention of updating the firmware of the "Connectivity" chip. Can I use the standard bootloader to upgrade?
  2. Adding custom events and commands is possible? How to do it correctly (an example will suffice)?
  3. There is no example "BLE Heart Rate Collector Example" for the board pca10056. Since the kit pca10040 is not at hand, is it possible to change the project for working with pca10056 or is there an example already fixed?
  4. Do you need preliminary configuration of the project for the connectivity chip (MTU, DLE, max connection count)? Or can all this be configured in the application code?
  5. Replacing the transport level with USB CDC is possible, as I understand it. Based on what example can a transport level be replaced with USB CDC. Are there any restrictions?

While waiting for an answer, I will continue independent research on this issue. Perhaps the list will be supplemented (or shortened if I find an answer earlier Wink)

Best regards,

Chelobitchikov Maxim

  • 0 in reply to CheMax

    Hi CheMax, 

    1. If it worked by increasing the accuracy tolerance, there could be a chance that the issue is with the crystal on board. The draw back of increasing tolerance is that you would draw more current. But I don't think it's a big issue in development. 

    2. The pc_ble_driver doesn't support API v.7.x yet, so it's better to use SDK v15.x if you plan to use it with pc_ble_driver. 
    If you plan to use timeslot, it's possible to implement it directly in to the connectivity chip's code. The timeslot would work transparently to the application so you don't need to modify the controller side. So no different. When you are in timeslot you can access the TIMER0, RADIO. The PPI channels and groups that are dedicated for the softdevice is not possible to access even when in timeslot, but you can access any other PPI. 

  • 0 in reply to Hung Bui

    Hi Hung.

    1. I thought about increasing consumption, but I suppose that the supplement will not be too large. Although tomorrow I will probably take measurements of consumption.

    2. OK, I understood. It's a pity of course, since I already started working with version 16.0.0 (s140: v7.0.1) ...

    But is the version of the soft device not backward compatible in this case? According to the "s140_nrf52_7.0.1_migration-document", the changes are not so significant at the application level.

    s140_nrf52_7.0.1
This section describes how to use the new features of s140_nrf52_7.0.1 when migrating from s140_nrf52_6.1.1. The s140_nrf52_7.0.1 has changed the API compared to s140_nrf52_6.1.1 which requires 
applications to be recompiled. 

Required changes
The application can no longer use the option  . The advertiser will always use improved scheduling. This was previously defined as  . BLE_COMMON_OPT_ADV_SCHED_CFG ADV_SCHED_CFG_IMPROVED
The macros  , and  NRF_SOC_APP_PPI_CHANNELS_SD_DISABLED_MSK, NRF_SOC_APP_PPI_CHANNELS_SD_ENABLED_MSK, NRF_SOC_APP_PPI_GROUPS_SD_DISABLED_MSK NRF_SOC_APP_PPI_GRO
are removed. The application can use the macros   and   to deduce the PPI channels  UPS_SD_ENABLED_MSK  NRF_SOC_SD_PPI_CHANNELS_SD_ENABLED_MSK NRF_SOC_SD_PPI_GROUPS_SD_ENABLED_MSK
and groups available to the application.


    Is there a plan to release a new version of the driver for the PC this year? If I remember correctly, then in one of the topics there was mentioned the expected update of SDK.

    If I still need to use version 15.3, will I need to use the patch described here?

  • +1 in reply to CheMax

    Hi Chemax, 

    I'm not sure when the new release will come. But the goal of course is to have the api version to get to v7. 

    There isn't a big jump from API v6 to API v7, but since we haven't tested running pc-ble-driver on v7 it's not recommended. 

    If you use SDK v15.3 you still need to apply the patch, it's for improving stabilization and optimize the code for the USB connection on the dongle/DK. 

  • 0 in reply to Hung Bui

    Hi Hung,

    Thanks. then I will be back at 15.3 for this project. I apply patch with SmartGIT )

    I just finished measuring current here and am a little surprised. Average current in connected state without synchronization: 0.2 mA. The average current in the connected state with a synchronization of 11.4 mA. 

    But for this issue, apparently we need to create a separate topic.

  • 0 in reply to Hung Bui

    Hi Hung,

    So, I conducted several more experiments on the implementation of timeslots API in this projects. Since binding to connection events (sd_ble_gap_conn_evt_trigger_start(m_conn_handle, &trigger_params);) that are available only in version 7.0.0 turned out to be effective in reducing consumption, I would like to receive a more detailed answer:

    1. Is it possible to use the serializer on the pc_ble_driver (sd_api_v6) side with the S140_7.x.x stack in connectivity chip with restrictions?

    2. if not, can you name the approximate date of waiting for support (at least a quarter / year)?

Related
Terms of service