Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Using Serialization on a nRF52832

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

Parents Reply Children
  • Hi,

    I have a protoype board with a Nordic nRF52 chip connected to another CPU via SPI.

    I am sending SPI data from the other CPU (configured as SPI Master), and can see the clock and data arriving at the GPIO pins of the Nordic chip, but even though the pins are configured as SPI MOSI and MISO pins, I am not getting any activity in the Nordic Serialization code indicating that data has been received - No IRQ generated and no Serialization events.

    I checked that the initialization of the Serialization is done on the Nordic device & get a couple of IRQ/Events at startup, but nothing after that.

    Can you suggest what might be wrong?  I set up the Nordic Serialization code in the same way as one of the Serialization Example projects (for SPI).

    Regards,

    Declan

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

  • 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

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

Related