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]

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