You are here

Hard fault on BLELL register read | Cypress Semiconductor

Hard fault on BLELL register read

Summary: 2 Replies, Latest post by jonpry_1596711 on 29 Mar 2016 02:19 PM PDT
Verified Answers: 0
Last post
Log in to post new comments.
jonpry_1596711's picture
5 posts


   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.


Jon Pry











BMAH's picture
Cypress Employee
189 posts

Hi Jon,

Are you testing on your custom board or the -042 BLE Kit? Can you share your project?

jonpry_1596711's picture
5 posts

This is a custom board. I'd rather not post the project. I did make a little progress though. Inside of CYBLE_Stack.h in the function description for CyBLE_EnterLPM() it states that "the CPU will not be able to access the BLESS registers while the BLESS is in deep sleep mode".

I was able to get things working by calling CyBLE_ExitLPM() inside of our main loop. Presumably what happens is that some non bless interrupt wakes us up from deepsleep, i'm guessing RTC but there are other interrupt sources, and then CyBLE_ProcessEvents() ends up being a no-op. So we end up back in our processing loop with BLESS in deepsleep which of course doesn't work. I think this is a little weird, for a couple of reasons. For one, I cannot find anything in the TRM that explains why BLESS is not accessible. Second, it is costing us an unknown but potentially small amount of power to keep BLESS powered just to read its counter.

I suspect we can live with the power drain, but it would be good to know if there is something lower power we can turn on to make BLESS readable.



Log in to post new comments.