CC2642R: SPI plays the role of SLAVE, how to reduce power consumption?

Hi Nick,

Would the customer be able to provide their SPI code?  Could they also give logic analyzer or oscilloscope screenshots of the SPI communication lines which correspond to the power analysis measurements?  Are they able to replicate behavior with the spislave example or is a BLE stack project required?

Regards,
Ryan 

Hi Ryan,

The CS trigger condition is written as follows:

 The events in simple_peripheral.c are as follows:

In the above event, the call to SPI_main_flow() is as follows:

The main rule is, if the content "A" received by spi is less than 2, execute Power_shutdown. Otherwise, enter standby.

The problem is that it is also reading SPI. No other codes have been added, but why the power consumption is almost 2mA after entering standby.

And it can't come down. Please guide if there is any special instruction to execute to make the power consumption down.

In the red box, after all annotations are made, SPI does not receive data at all.
On the contrary, with the red frame, the SPI can continue to receive data normally. But it also causes the power consumption to be pulled up from uA to mA in an instant,and it is maintained and cannot be lowered. How to modify and adjust to reduce power consumption? 

Best Regards,                                                        

Nick

Hi Ryan,

CH1 of the oscilloscope is the CS pin, and CH2 is the CLK pin.

The pause picture of the oscilloscope corresponds to about 34 seconds of the power consumption machine picture (obviously rising)

The READ / WRITE of SPI are all correct, but after the power consumption increases, even if I unplug all the SPI cables, the KEEP is still at the level of 1.5mA.

Best Regards,                                                        

Nick

Thank you for what has been provided so far.  There are still several customer SPI APIs which have not been shared, such as SPI_TxdataCLear, SPI_sem_init, SPI_Init,  SPI_TimeOutInit, SPI_ReadWriteData, and SPI_Close.

In the oscilloscope reading, the CS pin is toggled without any SPI activity.  Is this condition necessary to cause the issue?  Has the customer attempted to pause operation from the debugger to determine the state of the MCU?  This should confirm whether the MCU is trapped in an error or condition loop.

There are several instructions that take place in between the CS pin going low and SPI data read/write beginning.  This may cause the slave to start later than the master and shift bits out incorrectly.  What is the SPI clock frequency set by the master?  The customer should reduce this speed and further test specific master SPI operations to further understand what conditions cause the erratic behavior.

Regards,
Ryan

Hi Ryan,

The further function are shown in the figure below:

In addition, about the question 1, customer can confirm that he has not entered an error loop, because when DEBUG, the UART will continue to throw out the received SPI packet content.
As for the CS pin, when there is no SPI activity, if customer does not add the following three declaration definitions, all subsequent SPI packets will not be successfully triggered, and no UART string will appear.

GPIO_setConfig(CONFIG_GPIO_SPI_0_SS, GPIO_CFG_IN_PU | GPIO_CFG_IN_INT_FALLING);
GPIO_setCallback(CONFIG_GPIO_SPI_0_SS, gpioButtonFxn1);
GPIO_enableInt(CONFIG_GPIO_SPI_0_SS);

About question 2, he is not sure the SPI clock frequency of MASTER, but he has measured that each HI_LO of CLK is at least greater than 24us. And his current state is not that the data he receive is unstable but after SPI communication, there are also normal execution of SPI_Close() and other lines. Why the current has not dropped? (And at the moment of keeping high power consumption, he tried to remove the four SPI I/Os, and the power consumption was still maintained, and it would not fall off)

Best Regards,                                                        

Nick

The SPI can still be enabled and thus blocking LPM.  The customer should further debug their system to ensure that SPI_transferCancel and SPI_close are both called once the CONFIG_GPIO_SPI_0_SS pin returns to a high state.  They can also enable the transferTimeout to make ensure that SPI_transfer is exited in an appropriate amount of time.

Regards,
Ryan