PA LNA in a serialized application

[Romain]

Hi,

I am currently working with two nrf52 boards in a serialized configuration. I wanted to add the PA and LNA pin toogle on the connectivity chip. As the gpio can't be configured from the application chip, I did a little work around to allow the application to ask the connectivity to enable PA and LNA pins : I added the following code in the connectity application (in conn_mw_ble.c, in the function conn_mw_ble_opt_set()):

if(opt_id == BLE_COMMON_OPT_PA_LNA){
    sd_err_code = pa_lna_init(19,20);
}else{
    sd_err_code = sd_ble_opt_set(opt_id, p_opt);
}

With pa_lna_init(), the function you gave in an other forum post.

And I used it as follow on the application chip :

gap_params_init();
advertising_init();
services_init();
sensor_simulator_init();
conn_params_init();

// Start execution.
NRF_LOG_INFO("Heart Rate Sensor Start!\r\n");
sd_ble_opt_set(BLE_COMMON_OPT_PA_LNA, NULL);

This configuration works perfectly with the SPI 5W serialization, but stop after the call to sd_ble_opt_set(BLE_COMMON_OPT_PA_LNA, &opt) in the standart SPI serialization (6 wires).

Does anybody have an idea of the differences between the normal SPI and the 5W SPI which could lead to this behavior ?

Regards,

Romain

[Ole Bauck]

The main difference is the lack of a RDY signal line on the 5W SPI, but I don't see how that is causing problems.

If you have not changed pa_lna_init(..) it is not returning any value, so sd_err_code may be something other than 0 as it is not initialized (it will be whatever is on the stack). You should change pa_lna_init(..) to return the error code returned from the sd_ble_opt_set(..) function.

[Romain]

Thank you for your answer. I forgot to tell you that I already made the change for the return value of pa_lna_init. The 5W spi implementation works perfectly with it. In the standart spi implementation, the call to sd_ble_opt_set(BLE_COMMON_OPT_PA_LNA, &opt);, in the function pa_lna_init(..) makes the connectivity chip to stop and the call never returns. I don't see why the differences between the 5W spi and the standart spi could lead to this problem. Do you have any example with PA and LNA pin activated on the connectivity chip in a serialized application using the standart spi transport ?

Regards,

Romain

[vincenttardy]

Hello,

I am facing to the same issue. When I use serialization configuration with SPI 5W, everything is OK but when I use the SPI 6W configuration, the application doesn't work anymore. It seems that the NRF52 connectivity board is KO. Could you please provide us an example in order to fix this issue? Thanks

[Ole Bauck]

The problem is probably with the PPI channel used. SPI 6W serialization use channel 0 for the READY signal:

#define SER_PHY_SPI_PPI_RDY_CH                  0

Which is the same used in the pa_lna_init(..) function in the blogpost. Change the PPI channel used for the RDY line or the PPI channels used in pa_lna_init(..).

EDIT:

You should also not use the same GPIOTE channel. Channel 0 is used for the READY signal in SPI 6W serialization:

#define SER_PHY_SPI_GPIOTE_RDY_CH               0

Which is the same used in the pa_lna_init(..) function in the blogpost.

[Romain]

Thank you for your answer. I used the SDK API to alloc a ppi channel in pa_lna_init(...). The problem was that the serialization use a predefined channel for the READY signal. This ppi channel isn't tracked by the ppi module and this same ppi channel is re-allocated when using the API functions.