Using Serialization on a nRF52832

[Declan Traill]

Dear Nordic,

I have located the Serialization example project (using SPI) for the Connectivity board, but I cannot find an example project for the Application CPU board.

The Application board can be another type of CPU (i.e. not Nordic), so my question is: To support Serialization on a non-Nordic CPU, which Nordic files need to be included in the software build for that non-Nordic CPU? 

I have looked at the porting instructions but it does not seem to be what I am looking for. I looked at the Serialization files in the code from the SDK, and I think that the following list of files (below) is what is needed - can you inform me if this is correct? 

The main files seem to be ser_phy.c and ser_hal_transport.c, with the others being included.

I think that the s/w interface for Serialization for a non-Nordic CPU is the file ser_phy.c, is that correct?

Can you provide a code example of Serialization being initialized and used on a non-Nordic CPU?

nRF5_SDK_14.2.0_17b948a\components\serialization\common\transport\ser_hal_transport.c
nRF5_SDK_14.2.0_17b948a\components\serialization\common\ser_config.h
nRF5_SDK_14.2.0_17b948a\components\serialization\common\transport\ser_phy\ser_phy.c
nRF5_SDK_14.2.0_17b948a\components\serialization\common\transport\ser_phy\ser_phy.h
nRF5_SDK_14.2.0_17b948a\components\serialization\common\transport\ser_hal_transport.h
nRF5_SDK_14.2.0_17b948a\components\device\nrf.h
nRF5_SDK_14.2.0_17b948a\components\softdevice\s132\headers\nrf_error.h
nRF5_SDK_14.2.0_17b948a\components\libraries\util\app_error.h
nRF5_SDK_14.2.0_17b948a\components\libraries\util\sdk_errors.h
nRF5_SDK_14.2.0_17b948a\components\libraries\util\nordic_common.h
nRF5_SDK_14.2.0_17b948a\components\libraries\util\app_error_weak.h

Regards,

Declan Traill

[Jørgen Holmefjord]

Hi,

There are multiple application side examples for serialization. They are located within other example directories. Please have a look at this page for an overview of which examples include serialization examples.

Unfortunately, I'm not aware of any examples of non-Nordic serialization, but maybe you can get some inspiration from this thread? The serialization PHYs are described on this page. The Porting serialization libraries should describe the rest of what you need to implement this on another chip.

Best regards,
Jørgen

[Jørgen Holmefjord]

This document might be of interest. It is for nRF51 series, and old serializers, but should have som useful information. You would most likely need all files found in components\serialization\application\ and components\serialization\common\. You will have to adapt the files to work with the application CPU and libraries.

SPI_REQ and SPI_RDY are simply GPIOs (like SPI_CS).

[Declan Traill]

Found the problem - I had disabled the call to event_handler() during board bring-up so that the code on the Nordic would continue running without the SPI link to the other CPU being present.

[Jørgen Holmefjord]

Good to hear that you found a solution!

[Declan Traill]

Hi Jørgen,

  I have some serialization communications happening between my two CPUs (Nordic and NXP) via SPI,
  but it seems to be different depending which CPU starts up first, and the comms seems to grind to a halt quite promptly and then
  no message can be sent (get repeated NRF_ERROR_NO_MEM errors).
 
  If I start up the Nordic CPU first, then a large amount of data (65535 bytes) gets streamed from the Nordic CPU coon after it starts up.
  I get state sequence SER_PHY_STATE_TX_ZERO_HEADER, SER_PHY_STATE_RX_HEADER, SER_PHY_STATE_MEMORY_REQUEST, then lots of SER_PHY_STATE_RX_PAYLOAD packets.
 
  If I start up the NXP CPU first, I get SER_PHY_EVT_GPIO_REQ (while in SER_PHY_STATE_MEMORY_REQUEST state), then nothing.
  If I then try to send a command, such as sd_ble_gap_scan_start, I get HAL_TRANSP_TX_STATE_TX_ALLOCATED, HAL_TRANSP_TX_STATE_TRANSMITTING, SER_PHY_EVT_TX_API_CALL, then nothing (and nothing seems to happen at the Nordic end).
 
  What is the startup sequence supposed to look like?
  Which CPU should start up first, and what messages are exchanged at the start?
  Is there any required sequence of commands that should be sent after startup?

    Further to these questions, could you confirm that: the SPI RDY Line is Active High and should have an internall Pull-Down, and the SPI REQ Line is Active Low and should have an internal Pull-Up?

Are there any SPI requirements for pre_delay, post_delay, frame_delay or transfer_delay that should be set on the NXP side?

 
Regards,

Declan

[Jørgen Holmefjord]

Which function call is returning NRF_ERROR_NO_MEM? Both SPI RDY and SPI REQ lines should be active low, and use pullups. In the serialization application examples in the SDK, the connectivity chip is reset after transport is initialized. I would recommend that you do something similar, to ensure the connectivity board is in the correct state when you send commands.

[Declan Traill]

Hi Jørgen,

Ok, thanks - I have SPI communications happening & am getting Advertising Report Events being sent from the Nordic to the NXP. The problem was that the REQ & RDY line state changes were not generating interrupts properly.


Regards,

Declan