We are using PSoC4 in a combo BLE and capsense application. To try and reduce noise we are attempting to to perform capsense activity between BLE intervals. As there is a whole mess of capsense we are doing, ie takes a lot of time, this is non trivial.
The summary of the plan is like this. Usually you have something like:
/* CyBle_ProcessEvents() allows BLE stack to process pending events */
//do your stuff
while doing "our stuff", we are interested to know how much time is remaining before BLE will want to do something. The application notes on how to enter bless deep sleep offers a solution.
uint16_t start_instant = CY_GET_REG32(CYREG_BLE_BLELL_TIM_COUNTER_L);
uint16_t adv_instant = CY_GET_REG32(CYREG_BLE_BLELL_ADV_NEXT_INSTANT);
uint16_t init_instant = CY_GET_REG32(CYREG_BLE_BLELL_INIT_NEXT_INSTANT);
uint16_t scan_instant = CY_GET_REG32(CYREG_BLE_BLELL_SCAN_NEXT_INSTANT);
uint16_t ce_instant = CY_GET_REG32(CYREG_BLE_BLELL_NEXT_CE_INSTANT);
We then choose the closest event. and continually check CYREG_BLE_BLELL_TIM_COUNTER_L to see if we are running out of time. So far so good i hope. However the trouble happens right in the beginning. The docs say that we must check if the LL is idle before reading TIM_COUNTER_L, ie CY_GET_REG32(CYREG_BLE_BLELL_CLOCK_CONFIG) >> 7) & 1.
Under some circumstances, this operation *appears* to throw a hardfault. Now I can picture this happening if some peripheral clock gets turned off and this is an illegal read, but the read works in the debugger so I can't rule out anything. Could be memory corruption, stack troubles, some fault on ISR return.
We are looking for clarification as to whether or not there is actually some circumstance that would cause said read to fault, and if so, what is the workaround.