PSoC4 CapSense sample project and CyEnterCriticalSection()

[NaMo_1534561]

Hello,

I have questions about how the sample project works. The customer used the code from the sample project to evaluate the electrostatic sensor board.

   "CE210709_CapSense_Linear_Slider_and_Buttons"

   "CE224899_PSoC4_Low_Power_CapSense_Hybrid_Sensing01"

In the process of 'PROCESS_DATA' of Switch condition statement of main.c, the customer code saves the value of buttonStatus in a static variable and controls the GPIO to notify the status to the main CPU.

[problem]:

Continuously touching the CSD sensor causes PSoC to stop responding.

(Customer refer "CE210709_CapSense_Linear_Slider_and_Buttons")

[Results of customer analysis]:

1) GPIO which notifies the sensor touch event to the main CPU is not working.

2) However, when a problem occurs, "PROCESS_DATA" is executed normally in the debugger, and the sensor touch status can be acquired accurately. (Q1)

3) Furthermore, the GPIO control function (IRQpin_Write (0)) that notifies the main CPU is also executed normally. This can also be confirmed from the fact that the intended value can be obtained with the IRQpin_Read () function. (Q1)

4) According to the oscilloscope waveform, GPIO is not working.

5) Once in this state, the GPIO remains inactive even if the sensor touch operation is performed.

6) When I2C communication from the main CPU occurs, PSoC returns to normal operation and GPIO is controlled according to the sensor touch operation.

7) If CySysPmSleep () is deleted, this problem does not occur.

Question1:

According to the customer's report, the debugger normally exits sleep (CySysPmSleep ()) and shifts to "PROCESS_DATA" processing, but isn't the sleep function invalid during the debug processing of PSoC Creator?

[Guess]:

- Isn't the CySysPmSleep () running in the "WAIT_FOR_SCAN_COMPLETE" state not returning from the sleep mode after the completion of the key scan?

- 6) Isn't the problem solved by I2C communication from the main CPU because PSoC returned from sleep mode by the interrupt by I2C communication?

[Additional analysis result]:

From the source code of "CE224899_PSoC4_Low_Power_CapSense_Hybrid_Sensing01"

Before CySysPmSleep ();

  Added interruptState = CyEnterCriticalSection ();

After CySysPmSleep ();

  Added CyExitCriticalSection (interruptState);

The above solved the problem. (See attached sheet)

Question2:

CyEnterCriticalSection () has already been done inside the CySysPmSleep () function, so the addition of this code only makes a double critical section transition.

Why does adding CyEnterCriticalSection () solve this problem?

Best Regards,

Naoaki Morimoto

[BragadeeshV · Accepted solution]

Hi NaMo_1534561​,

Let me explain what could happen when CyEnterCriticalSection() is not called before the if(CapSense_NOT_BUSY != CapSense_IsBusy()).

Let us assume that there is an active scanning happening due to a previously called Capense_Scan. The condition if(CapSense_NOT_BUSY != CapSense_IsBusy()) could return true and goes to sleep. If a CapSense scan is completed, the device comes out of sleep, ExitCriticalSection is executed and then CapSense ISR is executed. This is normal expectation.

Now, let us assume that the scan ended right after the if condition but before the  CySysPmSleep(); This causes the CapSense ISR to be executed. Later, the statement CySysPmSleep() is executed. This would cause the system to enter sleep mode and could never return since there is no CapSense ISR that can wake up the device from sleep (since it is already executed). That is why an I2C communication (caused an interrupt) and took the CPU out of sleep mode. Same goes with Debugger (sleep mode is not executed when debugger is attached).

I hope this explains why you need to check the CapSense busy status within critical sections.

Regards,

Bragadeesh

[NaMo_1534561]

Hello Bragadeesh-san,

Thank you for answer.

I will consider this content.

Best Regards,

Naoaki Morimoto