Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
JeHu_3414236
Level 5
Level 5
10 likes received First like received

I am using PSoC Creator 4.2 CapSense v2.0 and sometimes the hardware will be stuck in the busy state after calling CapSense_1_ScanAllWidgets().  Calling CapSense_1_IsBusy() always returns CapSense_1_SW_STS_BUSY.  I can recover by calling CapSense_1_Stop() then CapSense_1_Start().  What conditions will cause the hardware to be stuck and how can I detect the error or prevent it?  Right now I just poll periodically with CapSense_1_IsBusy().  Is there a function that returns an error if the hardware is stuck?  I attached the capsense settings.

0 Likes
1 Solution
Hari
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi JeHu_3414236

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,

Hari

View solution in original post

0 Likes
3 Replies
Hari
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi JeHu_3414236

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.

Thanks,

Hari

0 Likes

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.

0 Likes
Hari
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi JeHu_3414236

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,

Hari

0 Likes