CYBLE_EVT_GAPP_ADVERTISEMENT_START_STOP called over and over

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.
Anonymous
Not applicable

Hi,

   

According to the documentation for the block, the CYBLE_EVT_GAPP_ADVERTISEMENT_START_STOP event should be called when advertisement starts or stops. But if I run my code with the debugger on my CY8CKIT-042-BLE board, a breakpoint in the event is triggered over and over, with almost no time in between. Can anyone please tell me why this is happening ?

   

I'm using the attached code on a PRoC BLE module. At this point, there isn't much of my code left. The only thing on my TopDesign schematic is the BLE block (v2.00).

0 Likes
1 Solution
Anonymous
Not applicable

I did a quick test on your code and I can see the issue. But If you remove the breakpoint when it hits -> Run -> And again place a breakpoint, then it does not hit it again. 

   

So I feel that the EVT is being called only once, but due to some debugger aberration you see the multiple hits on same breakpoint. 

   

You can test it by placing a LED toggle code inside this event and observe how much toggling occurs.

View solution in original post

0 Likes
5 Replies
Anonymous
Not applicable

I did a quick test on your code and I can see the issue. But If you remove the breakpoint when it hits -> Run -> And again place a breakpoint, then it does not hit it again. 

   

So I feel that the EVT is being called only once, but due to some debugger aberration you see the multiple hits on same breakpoint. 

   

You can test it by placing a LED toggle code inside this event and observe how much toggling occurs.

0 Likes
Anonymous
Not applicable

Hi Roit,

   

Thanks for your response. It looks like this is correct. 

Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

With enabled interrupts debugging can turn out to be complicated. The situation is:

   
        
  1. You stop at a breakpoint and watch debugging results
  2.     
  3. During that time an interrupt occurs, but is not served because the processor is halted
  4.     
  5. At resume, the pending interrupt becomes active and gets served.
  6.     
  7. The return point for the interrupt handler is the instruction where you set the breakpoint to.
  8.     
  9. The program breaks again at the same point, sometimes looking as if nothing has happened.
  10.    
   

Remember: A breakpoint stops the CPU execution, but does not stop any hardware from running as there are counters, timers, radios, DMA etc.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Thanks for your insight Bob. That makes a lot of sense. I guess for some of this stuff I need to go back to debugging with LEDs 😉

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

A first solution might be to disable interrupts when you reached a brekpoint, there is a button for this function.

   

You may even use the USB-UART connection which is supported by the KitProg module of your PRoC BLE. Only the right io-pins have to be connected to an UART component. Shows some more than an LED.

   

 

   

Bob

0 Likes