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 )

Best regards,

Chelobitchikov Maxim

[Hung Bui]

Hi CheMax, 

1. A connectivity chip is updated the same way as other firmware can be updated. The DFU updating process is handled by the bootloader, not the application. You can use the bootloader to upgrade. There is only one thing that need to be handled in the application firmware is to trigger the jump to the bootloader. 

2. It's possible, you need to modify the code to add your opcode in. I would suggest to have a look at the type SER_PKT_TYPE_GENERIC_CMD, in ble_serialization.h. There you can find that there are 2 opcodes :typedef enum
{
SER_GENERIC_CMD_RESET,
SER_GENERIC_CMD_SOFT_RESET
} ser_generic_cmd_t;

You can either add your own opcode or add your own type in. 
On the main application side, you need to prepare the packet with the correct type (or use SER_PKT_TYPE_GENERIC_CMD) and then use the opcode you define. Please follow the format in the documentation. https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/serialization_codecs.html?cp=7_1_3_43_2

4. They are configured from the application code. 

5. I don't think so. I don't see any restriction here. The connectivity firmware ser_s140_usb_hci does that job. 

[CheMax]

Hi, Thanks for your answers.

Additional questions:
1. I noticed that pDK(ver 0.9.3) as a chip's connectivity does not behave stably when creating connections. Scanning is in progress, but no connection to the board is created. If you use DK (ver 1.1.0) then there are no such problems. What could be the reason?

2. Problems with starting. If the connectivity chip was not reset before starting the chip with the application, then the initialization of the stack fails. That is, now, when I start the system, I act as follows:
    1. turn off the connectivity board (power off);
    2. I turn on the "application" board and connect to it in debug mode;
    3. turn on the connectivity board (power on);
    4. run the application code for execution.

With this algorithm, startup always occurs. If you do not de-energize the connectivity board, then the application will crash (hardfault).

[Hung Bui]

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. 

[CheMax]

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?

[Hung Bui]

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. 

[CheMax]

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.

[CheMax]

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)?

[Hung Bui]

Hi CheMax, 

I have checked with the development team. The answer is that the connectivity firmware in the SDK is not drop-in compatible with the pc_ble_driver. And you can't use the example in the SDK with the pc_ble_driver. So only the .hex provided in the pc_ble_driver should be used. 
We currently don't have a plan to providing support for api v7. 

So the only solution if you want to use API v7 is to write your own application on PC side to control the connectivity firmware from SDK v16. 

But i don't really understand if you are plugging the dongle into PC why would power consumption be an issue ? 

[CheMax]

Hi Hung,

The dongle will not only connect to the PC, but in some cases will be part of the device, the so-called "signals hub". This device may have battery power.

The issue of consumption arose due to the introduction of time synchronization based on time slots. To reduce energy consumption, it was decided to run slots before connection interval started (I described a little more in a new question regarding time slots here

Hung Bui said:

The answer is that the connectivity firmware in the SDK is not drop-in compatible with the pc_ble_driver. And you can't use the example in the SDK with the pc_ble_driver.

). But the event of the beginning of the connection interval is available only in the 7th version of the stack ...

That is, the need to switch to the new version is due not so much to consumption as to new available functionality ...

Hung Bui said:

The answer is that the connectivity firmware in the SDK is not drop-in compatible with the pc_ble_driver. And you can't use the example in the SDK with the pc_ble_driver. So only the .hex provided in the pc_ble_driver should be used.

Ummm, I didn’t understand a bit.
Does a hex-file mean a softdevice file? If so, then why is there no file here?

Hung Bui said:

So the only solution if you want to use API v7 is to write your own application on PC side to control the connectivity firmware from SDK v16.

If you look here, it turns out that the serializer is taken directly from the SDK. This follows from the description:

Content
This directory contains the common codecs for SoftDevice API version 3 to SoftDevice API version 6. The codecs are updated at regular intervals from the latest versions of the nRF5 SDK.

The SDKs are found here: https://developer.nordicsemi.com/nRF5_SDK/

So the task of the driver is only to provide support for the transport of commands / events between the stack and the application? Then, theoretically, replacing the SDK files with new ones, the driver file will continue to work. It remains only to add the required functionality at the application level?

Also, time control over time intervals will be fully implemented in the connectivity chip.

[Hung Bui]

Hi CheMax, 

The hex file of the connectivity firmware is provided inside the release .zip file you can download here: https://github.com/NordicSemiconductor/pc-ble-driver/releases

But it's true that the connectivity firmware is actually built from the \examples\connectivity example in the SDK, with the patch provided in the repo. 

So it's possible that you can implement the same patch on SDK v16 (You would need to go through to patch to see how it should be implemented in SDK v16). But we haven't tried that and i can't guarantee that it would work 100%. 

[CheMax]

ok, thanks.

In any case, we would need to transfer this code to CT. So, we will do as Master Yoda bequeathed.

I think that at this stage the questions on this topic have ended. Thanks for the help, patience and understanding)