The CapSense settings that's attached is correct, no reason for the firmware getting stuck. This could happen if the system enters a critical section after the CapSense scan. Since CapSense scanning is hardware based, the CapSense_1_IsBusy returns CapSense_1_NOT_BUSY when the flag is set in an ISR. Hence, please make sure that all interrupts are enabled during the scan time.
At the hardware side, please make sure that a 2.2 nF is placed at the Cmod pin that is configured in the project.
Is this issue happening again after the component is restarted (Stop and start)?
Please attach a sample firmware where this issue is reproducible.
I don't disable any interrupts and I have 2.2nF at Cmod. This problem can take several hours to produce. I have not kept running the test for a long time after stopping and starting to see if it happens again. Can this problem be caused by large changes in supply voltage like jumping from 3.7V to 3.0V? I don't have the option "Enable sensor auto-reset" enabled. Can this cause the hardware to lock up? The description says:
When enabled, the baseline is always updated and when disabled, the baseline is updated only when the difference between the baseline and raw count is less than the noise threshold.
When enabled, the feature prevents the sensors from permanently turning on when the raw count accidentally rises due to a large power supply voltage fluctuation or other spurious conditions.
Can you tell me how to detect the "raw count accidentally rises" case so I can check if this is causing the lock up? Thanks.
Although such changes in power lines are not recommended, this cannot cause the issue. Please make sure that the decoupling caps are present to filter out any noise.
Regarding the sensor auto-reset, this feature is provided to make sure that the sensors do not get stuck at a particular state, not the firmware. That is, if the sensors constantly report "Touch detected", it could be due to noise and the baseline is reset to make the sensors operational again. This does not cause the firmware to get stuck.
The raw counts can accidentally rise due to variety of external causes such as change in temperature, external noise, etc. This only results in the component giving false triggers but the firmware would still be active and running.
Thanks and regards,