Why the SPIRIT1 (SPSGRF 868 module) enters in MC_STATUS ERROR when I send to it via SPI the command to enter in LOCK status during the "WMBus_PhyInit(MODE, TYPE)" undebuggable initialization function?

[mikmary]

Hello,

I'm working with a custom board mounting the SPSGRF-868 RF 868MHz module, which embeds the SPIRIT1 transceiver.

I communicate with it via SPI, using a microcontroller STM32L151.

My board is based on the STEVAL-IDS001V4M evaluation board architecture, which mounts the same RF module and the same MCU.

I upload on the board a firmware based on the W-MBus projects developed by the ST which can be found in the STSW-CONNECT009 packet.

I use the IAR-ARM IDE as required by the ST project.

I DON'T have access to the W-MBus library source files, I can just see the function declarations in the header files.

My firmware in practice configures the transceiver and the boards using the configuration functions developed by ST, to which I cannot access during debug.

The device is a concentrator, in WMbus mode T1, channel 1, frame format A.

Here is the initialization code, which shows the library functions that I use as in the examples.

 /* Initialization of the link Layer first */

 WMBus_LinkInit(m_field, a_field, DEVICE_TYPE, WMBUS_FRAME_FORMAT);

 //DEVICE_TYPE: it can be set in user_config.h

 //WMBUS_FRAME_FORMAT: format A/B, it can be set in user_config.h

 /* Set output power*/

 WMBus_PhySetAttr(WMBUS_PHY_OP_POWER, TX_OUTPUT_POWER);

 WMBus_PhySetAttr(WMBUS_PHY_RF_OFFSET, SpiritManagementGetOffset());

 //WMBUS_PHY_OP_POWER: type WMBUS_PHY_ATTR_t (wmbus_phy.h)

 //TX_OUTPUT_POWER: can be set in user_config.h

 //WMBUS_PHY_RF_OFFSET: type WMBUS_PHY_ATTR_t (wmbus_phy.h)

 //SpiritManagementGetOffset(): the parameter is set in board_init(), and here is retrieved

 WMBus_PhySetAttr(WMBUS_PHY_PREAMBLE_LEN, 16);

 WMBus_PhySetAttr(WMBUS_PHY_POSTAMBLE_LEN, 2);

 /* Initialization of the physical Layer */

 WMBus_PhyInit(DEVICE_WMBUS_MODE, DEVICE_TYPE);

 //DEVICE_WMBUS_MODE: mode of wmbus to be used, it can be set in user_config.h

 //DEVICE_TYPE: it can be set in user_config.h

Then the device receives W-Mbus packets sent by some known meters, decodes them and sends them via UART to another board.

The firmware is tested using the evaluation board STEVAL-IDS001V4M and works correctly whithout any trouble.

When I try to upload the exactly same firmware to my custom board (using the ST-Link V2.0 as done during the evaluation phase) the behavior changes.

The microcontroller seems to do the initialization of the transceiver as before, but then it get stuck when it tries to get the idle RSSI using the piece of code here after (written by ST).

 //expansion of the macro WMBUS_PHY_COMPUTE_RSSI_THR(10, 10);

 int32_t rssi=0;

 for(uint32_t i=0;i<10;i++){

   rssi+=(int32_t)WMBus_PhyGetIdleRssi();

 }

 WMBus_PhySetAttr(WMBUS_PHY_RX_RSSI_THRESHOLD, rssi/20);

The last line is never reached and the loop get stuck to the first try of "WMBus_PhyGetIdleRssi()".

My board is recognised by the "SdkEvalIdentification()" as it was the STEVAL-IDS001V4M board and I don't find any other places where it could be seen as a different hardware and thus setting differently some parameters in automatically.

As I cannot enter with the DEBUG inside the library source code, I tried investigate the case using a logic analyzer.

I sniffed the SPI to check firstly that the connection was correctly set. It is.

After the Shutdown pin is released, the MCU sends the command "read status register" to the SPIRIT1 (0x01 0xC0) and the transceiver anwers "READY" (0x52 0x07) exactly as stated in the datasheet.

The communication for the initialization goes on and on whithout any problem, writing and reading the internal registers of the SPIRIT1 as expected. The devices changes status to STANDBY when the command is sent and then again to READY at the subsequent command without any problem.

The trouble shows during the function "WMBus_PhyInit(T1_MODE, OTHER)", when the device is set as a concentrator in the 868MHz band.

The logic analizer shows a different behavior on the SPI between the custom board and the evaluation one even if the firmware is exactly the same (I cannot go with the DEBUG inside this function).

Firstly the register ANA_FUNC_CONF[0] (0x01) is set in order to work with a 24MHz clock (as in the evaluation board).

The command to write the registers CHSPACE, IF_OFFSET_DIG, FC_OFFSET[1] and FC_OFFSET[0] (from 0xC0 to 0xF0) is then sent. And here is the problem:

As stated in the datasheet the first register should be set to 0xDC when the clock is 24MHz, instead for my board is set to 0x01. It means a channel spacing set for a clock of about 32kHz, which is not the case (the SPSGRF module embeds a 50MHz clock connected to the embedded SPIRIT1, and the clock was just set to 24MHz inside the ANA_FUNC_CONF[0] register).

The 3 subsequent registers are all set to 0x00 which is basically meaningless.

At that point after a while the command to send the SPIRIT1 to LOCK state is sent (0x80 0x66).

The SPIRIT1 instead of answering after a short while with the state "LOCK", goes in an unexisting state and answers to the status register read (0x01 0xc0) with "0x52 0x27".

The firmware at this point is stuck to asking the status register and listening to "0x52 0x27" forever.

The SPIRIT1 doesn't answer to any other command.

The firmware uses all initialization functions written by ST, and I did't change any default configuration for the clock settings of the SPSGRF chip.

Where the problem could be generated?

Where is the point when the device could be wrongly recognised and then set?

Why the device cannot enter in LOCK state and just all get stuck?

There is some way I can access to the library source code?

Thanks to anyone who can help.

[SCast.2081]

Did you get any results yet? I have also a situation where the SPIRIT1 keeps responding "0x52 0x27"... ?