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

[CheMax]

CheMax said:

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?

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.

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