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

[CheMax]

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

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