Compiler/CC2640R2F: CC2640 crash

A total of 120 patches in small batches were tested on 20 patches. CC2640 did not sleep. Touching 24M crystal by hand would not kill the machine, but touching it 2-3 times during sleep would kill the machine. There are 3 pieces without 12 pf welded in 20 pieces.

It's still not clear why you are touching the xtal in the first place? 

We found that the button didn't wake up it.I'll sort out the code and send it out later.

There was also a device that did reset program after key wake-up, the device immediately crashed, and no reason was found. The reason why we wake up to do initialization interface is that Bluetooth sometimes can not be connected, reset can be done, so we initialized after key wake-up, remove the reset operation, and then the device will not crash, and actively connect Blue through APP. It takes two teeth to succeed.

On Saturdays, we tested charging and discharging, and the equipment was normal.After work, we turn off our equipment and go to sleep. We can't turn it on on Monday. Normal after reduction.We tested four of them, and one of them showed this phenomenon.

  Based on the low-power development data of CC2640R2F, devices need to enter the low-power interface without calling the system layer or protocol stack. They only need to define the POWER_SAVING macro definition in the compiler attributes. Then the application layer only needs to close the functions of timer, broadcasting, connection and so on. The system layer or protocol stack will work according to the application layer. Whether there is something to deal with to decide whether to enter the low power consumption, if the application layer does not have anything to deal with, it will enter the low power consumption, or even deep dormancy. The system layer or protocol stack detection part is the original processing in the sdk. This part has not been modified, it is all the original processing of the official.           

 In the actual development process, when the key press enters the low power consumption, the application layer will stop all the things being processed, and then the system layer or protocol stack will detect the automatic entry of low power consumption. After triggering the button, the application layer closes the code (application layer code, because the system layer or protocol stack has not changed, is SDK native, so the native code is not screenshot). The screenshot is as follows:

2. Wake-up from low power consumption:           

  From the low power state wake-up, there is no application layer processing. This is the original processing in the sdk. What the application layer does is configure a key to trigger the external interrupt. It is described in the SDK document. The external interrupt can wake up the device from the low power state. The configuration of the external interruption of the key and the code of what the system does after waking up by the key and triggering the key by the application layer are as follows:

Original           

PIN_setConfig (RFInPinHandle, PINCC26XX_BM_WAKEUP, RF_KEY | (PINCC26XX_WAKEUP_POSEDGE));           

Change to:           

PIN_setConfig (RFInPinHandle, PINCC26XX_BM_WAKEUP, RF_KEY | (PINCC26XX_IRQ_BOTHEDGES));          

Is that the change? Or PINCC26XX_BM_WAKEUP needs to be changed, because the header file of pin is defined as follows:

If PINCC26XX_BM_WAKEUP is not changed, will it affect to use PINCC26XX_IRQ_BOTHEDGES alone?