nrf52840: Serialization

RE: nrf52840: Serialization

CheMax — Thu, 14 May 2020 15:11:51 GMT

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)

RE: nrf52840: Serialization

Hung Bui — Thu, 14 May 2020 14:40:31 GMT

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%.

RE: nrf52840: Serialization

CheMax — Thu, 14 May 2020 13:59:09 GMT

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 ...

[quote userid="2121" url="~/f/nordic-q-a/60797/nrf52840-serialization/249945"]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. [/quote]

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

[quote userid="2121" url="~/f/nordic-q-a/60797/nrf52840-serialization/249945"]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.[/quote]

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.

RE: nrf52840: Serialization

Hung Bui — Thu, 14 May 2020 12:04:34 GMT

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 ?

RE: nrf52840: Serialization

CheMax — Thu, 14 May 2020 08:31:31 GMT

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

RE: nrf52840: Serialization

CheMax — Fri, 08 May 2020 13:17:54 GMT

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.

RE: nrf52840: Serialization

Hung Bui — Fri, 08 May 2020 12:57:01 GMT

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.

RE: nrf52840: Serialization

CheMax — Thu, 07 May 2020 15:59:36 GMT

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?

RE: nrf52840: Serialization

Hung Bui — Thu, 07 May 2020 14:17:41 GMT

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.

RE: nrf52840: Serialization

CheMax — Tue, 05 May 2020 09:32:46 GMT

Hi,

1. I was able to start it by changing the accuracy settings of the clock, set 250ppm. Strange, but I don’t quite understand how this could affect. the phone was connecting stably to the server running on this board (HRS example).

Board marking (top right corner on backside) : E232940 JOVE JVE-H2 3717 94V-D

Chip: N52840 QIAAAA 1650AE

2. There was also a problem with the reset pin. For some reason, another value appeared in the memory (0x10001200: 00000015 00000015 instead of 00000012 00000012). The problem was solved by full erasing and reprogramming the chip. thanks for the command, I’ll add just in case.

Now I'm confused with the correspondence of the versions of the SDK and the driver for the PC. Is it correct to use api version 6 for sdk version 16.0.0?
Will it be compatible with soft device versions 7.x.x?

Do I understand correctly that it is better to add timeslot api directly to the connectivity chip code? I need to integrate synchronization based on your example (Wireless timer synchronization among nRF5 devices).

the launch will not be any different from a simple example?
When allocating resources, are there any restrictions (PPI channels, PPI group, Timers)?

What is worth paying attention to at the same time?

I’m afraid that so far I don’t understand the architecture of the project, I can break something ...

RE: nrf52840: Serialization

Hung Bui — Tue, 05 May 2020 08:23:58 GMT

Hi CheMax,

1. Please test the 0.9.3 board with normal central application to check if it can establish a connection. I suspect the radio part could have an issue. Could you read the laser marking on top of the board ?
2. If you do not reset the connectivity board, was there any thing running on it before ? If the application board reset when both part are in the middle of the a process (for example if the BLE stack already initialized) I do believe that would cause the connectivity board to crash. I would suggest to trigger a reset for the connectivity board before starting up. You need to send a SER_PKT_TYPE_GENERIC_CMD with SER_GENERIC_CMD_RESET opcode.

RE: nrf52840: Serialization

CheMax — Thu, 30 Apr 2020 12:58:00 GMT

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

RE: nrf52840: Serialization

Hung Bui — Thu, 30 Apr 2020 12:07:19 GMT

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.

RE: nrf52840: Serialization

CheMax — Wed, 29 Apr 2020 10:40:30 GMT

[quote userid="51855" url="~/f/nordic-q-a/60797/nrf52840-serialization"]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?[/quote]

I adapted the example for the board pca10056. It starts, connects, logs. There is some problem with starting the connectivity board, but I think I will finish the solution.