Change in Scan Request(device address) done when advertisement is received is not reflected immediately, but reflected for next

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

cross mob
Anonymous
Not applicable

Hi Team,
I need your kind support on the following.
I have configured my Cypress BLE module as observer.
My module will listen to the broadcasters advertisements and send scan requests and receives scan response perfectly. All this is working properly.
But the actual problem here is when I receive advertisement, I am trying to modify the device address i.e. scan Request, it is changing and reflecting for the next advertisement received, not immediately. Why is this happening? Is there a way to avoid to this? How this problem can be solved?
when I receive an advertisement, I need to change scan request(device address) and broadcaster should receive this instantly and not for the next advertisement.
Can you kindly provide your support for the same. Hope I am clear in my explanation.
Thanks, Regards,

   

Kumar

0 Likes
38 Replies
Anonymous
Not applicable

Why do you expect/want it to change t he device address immediately? The scan requests might have already been sent out before you changed the address; The address/configuration settings generally can only be changed at the intervals when the BLE radio is not active, otherwise you would get corruption of radio packets being sent out while data configuration is being changed. I'm not sure you can change it "immediately", but you should be able to change it before sending out the next scan request. It might involve stopping scanning, changing the settings, then re-enabling the scanning in order for it to work.

   

Is the issue how fast the device address is changing? Is it a problem with the device address not changing at all? 

0 Likes
Anonymous
Not applicable

Hi Pratt,

   

Thanks for your immediate response.

   

My application is like that when I receive advertisement, I need to change scan request(device address) and send.

   

As I told clearly, scan request is changing, but it is lagging one iteration. I receive ADV1 - I send SCAN REQ1

   

I receive ADV2 - I send SCAN REQ2.

   

But the receiver(device) of scan requests receive SCAN REQ1 for ADV2 and Scan REQ2 for ADV3.

   

One iteration is lagging. 

   

Basically, as soon as I receive ADV, in the application event handler, CYBLE_EVT_GAPC_SCAN_PROGRESS_RESULT, I change Scan Request, but the change reflects when the next ADV is received.

   

So Basically I understand before, the event handler is rasied, radio alreadysent scan Request. Kindly confirm my understanding.

   

Is there a way to solve this problem? Can you please confirm. Is there any work around for the same.

   

Thanks,Regards.

0 Likes
Anonymous
Not applicable

Hello Kumar,

   

Hmmmmm, it could be that you need to call cyble_processevents() to finish/fully update the scan request response, and it isn't being called in-time for the next advertisement.

   

If the BLE stack is processing the ADV2 already when you are trying to change the SCAN REQ2, then I wouldn't see a feasible way to change the scan request sent out.

   

If the advertisement hasn't be received by the hardware, then there should be a method/way to somehow change the scan request parameters before the next advertisement packet.

   

The event CYBLE_EVT_GAP_SCAN_REQ_RECVD might be helpful in determining if the software is handling your scan request parameter changes before you are getting the next advertisement packet. (Enabled by CyBle_SetAppEventMask())

   

(Sorry for not understanding what exactly you were asking in your original post 🙂

0 Likes
Anonymous
Not applicable

Hi Pratt,

Thanks for your immediate response. Hope you are doing excellent. I was on forced emergency vacation for a month and back now.

Unfortunately we could not conclude last time and come to a common agreement, can we do it now please.

Basically, as soon as I receive ADV, in the application event handler, CYBLE_EVT_GAPC_SCAN_PROGRESS_RESULT, I change Scan Request, but the change reflects when the next ADV is received.

   

So Basically I understand before, the event handler is rasied, radio already sent scan Request. Kindly confirm my understanding.

   

Is there a way to solve this problem? Can you please confirm. Is there any work around for the same.

Can you Kindly provide your support and close this with the common agreement.

Thanks,Regards

Kumar.

0 Likes
Anonymous
Not applicable

Hello Kumar,

Welcome back

There are several reasons that I can see for why it is behaving this way:

1. The hardware radio is already started/starting sending out the next scan request.

2. The cypress binary is written to check/change the scan request after it sends a scan request, and thus it will always lag by one iteration as you are seeing. (Would need cypress to confirm this)

3. Based on timing/other things the scan request data might not be getting updated/handled before the next advertisement comes through. (Cyble_Process_Events)

If the cause is reason 1, there is no solution.

If the cause is reason 2, then Cypress would need to help you work through it.

If the cause is reason 3, then you would need to change the code you are running to try to speed up processing time. Basically, you would need to shorten the time from the GAPC_SCAN_PROGRESS_RESULT event finishing to the CyBle_Process_Events() finishing. Even then, you might not be able to make the code short enough to get it working.

Ideally, you would have your application/code allow for a slight delay of the one or two advertisements before the scan request data changes. Otherwise, you will be constantly worrying about the timing getting slowed down or disrupted in some way causing a fatal program flow disruption. The simplest solution I would do is to program your code to allow a lag of one advertisement, as everything else is working

Good Luck,

EPratt

0 Likes
Anonymous
Not applicable

Hi Pratt,

Thanks for your immediate response. Thanks for the explanation.As you concluded nothing can be done here, we need to accept it as Cypress BLE  System behavior and need to handle in application code.

Another important question for you is, how and when there is a chance of BLE stack getting freezed or becoming unresponsive?

When do you see BLE stack becoming unresponsive? what causes this behavior? Have you observed this any time in your testing. Rest of the system will be fine and running, only BLE stack becoming unresponsive? Kindly suggest.

Thanks,Regards,

Kumar.

0 Likes
Anonymous
Not applicable

Hi Pratt,

Can you kindly provide your thoughts/suggestions on the following before you go for weekend.

Another important question for you is, how and when there is a chance of BLE stack getting freezed or becoming unresponsive?

When do you see BLE stack becoming unresponsive? what causes this behavior? Have you observed this any time in your testing. Rest of the system will be fine and running, only BLE stack becoming unresponsive? Kindly suggest.

Thanks,Regards,

Kumar.

0 Likes
Anonymous
Not applicable

Hello Kumar,

Sorry I didn't see this before I headed out for the weekend

The BLE stack will become unresponsive or "freeze" when you call the API functions incorrectly. Afaik, it will not be locking up or causing issues if you are using the API functions in the correct order/sequence as defined by the documentation. I've seen it mess up when I was first playing with the APIs, but now that I understand more or less how it works, it hasn't given me issues.

Epratt

0 Likes
Anonymous
Not applicable

Hi Pratt,

Good Morning. Hope you had an excellent weekend. Thanks for your immediate response.

I am running only observer code in my device, some times I see BLE stack freezes or becomes unresponsive. This happens some times after 4 to 5 days. This happens some times less than an hour also. Rest of the device works perfectly fine. Only BLE stack gets freezed. If I restart BLE stack, it works fine again.

Lots of devices are sending Advertisements around my device, lots of interference, too many advertisements from too many devices will this be a problem? why BLE stack is getting freezed?

If APIs are not called correctly, it should not work for 5 days properly right? and after restart of BLE stack it should not work properly right?

What can go wrong here? Can you please help on this.

Thanks ,Regards,

Kumar.

0 Likes
Anonymous
Not applicable

Hi Pratt,

Can you kindly help me to get out of the above mentioned critical issue as soon as possible. It has become highly critical, because the nature of issue is random.

Kindly provide support on the same.

Thanks, Regards,

Kumar.

0 Likes
Anonymous
Not applicable

So, if I understand correctly: You are only running in observer mode, and you never call any other BLE APIs after starting the BLE stack?

Possibly, if you aren't calling the CyBle_ProcessEvents() quickly enough, the BLE stack could be running into a timeout issue with handling the incoming advertisements. Try to call the CyBle_ProcessEvents() at least once on each iteration through main?

If you are receiving alot of advertisements, then you will need to be handling all of the advertisements, but if you handle them quickly enough I wouldn't see it as an issue.

If your device is working for several days of getting dozens of advertisements per minute, then the software for calling the APIs and code would be less likely to be the source of the issues

On the other hand, something like the radio/chip overheating or running into a limit with the handling of the advertisements might be the cause.

Things I would test/try: Call CyBle_ProcessEvents() after calling BLE APIs and during the main() loop to ensure the BLE events are handled quickly and frequently.

There could be issues with code that doesn't run often, or an issue that compounds and thus doesn't show up right away. But, that would involve looking through the application code: I would expect you don't want to post your code on the internet...

If you are restarting the BLE stack to fix the issue, then the problem is most likely in one of two places: Cypress' BLE radio code, or your application code.

0 Likes
Anonymous
Not applicable

Hi Pratt,

Good Morning. Thanks for your immediate response.

I am afraid on resetting the BLE stack, when it is getting freezed, it is solving the issue. I am not resetting any other part of the code.

So issue cannot be in my application code.

I guess issue has to be in BLE radio code or  running into a limit with the handling of the advertisements? Is there any limit like that? I am receiving currently 10 to 15 advertisements every second. will this be a problem. If radio is overheating on restart how it will solve the problem.

I don't expect it as hardware issue, it should be software issue only.

My for loop just has this

for(;;)

    {

       CyBle_ProcessEvents();  

       // Check if time of packet received is greater than 60 seconds, reset BLE stack

    }

Also If a desired advertisement is received, I will change the device address in the event handler.

Can you elaborate on this? what is BLE stack running into a timeout issue? what is the minimum/maximum time out for BLE stack. I am calling CyBle_ProcessEvents();    on every iteration in main. SO here where is the chance of BLE stack getting freezed?  what are the conditions for it to get freezed if we know then we can easily understand what is the problem. Please elaborate on this.

if you aren't calling the CyBle_ProcessEvents() quickly enough, the BLE stack could be running into a timeout issue with handling the incoming advertisements. Try to call the CyBle_ProcessEvents() at least once on each iteration through main?

Please let me know how to solve this?

Thanks, Regards,

Kumar.

0 Likes
Anonymous
Not applicable

My for loop just has this

for(;;)

    {

       CyBle_ProcessEvents(); 

       // Check if time of packet received is greater than 60 seconds, reset BLE stack

    }

  • Based on you saying this is what your code does, then you shouldn't be having issues with the CyBle_ProcessEvents() being handled quickly enough.
  • Like you said, resetting the BLE radio fixes your issue, so there must be something software (not hardware) related causing the problem.
  • 10-15 advertisements per second should be fine (that's about 200 ms to process each on average) I was thinking you would say a number like 500 or something
  1. Have you tried running the device with a debugger connected to see what the state/variables are set to when it "freezes"?
  2. If you can post your complete project, it would help for us to see the configuration settings, otherwise you could ask Cypress to look at the project themselves, and give you tips/pointers on your code.
  3. Have you tried running one of the example observer projects? If the example one works fine, then it will be a difference between your project and the example project
  4. Depending on what your code for the event handler for the BLE radio is doing, that could be a source of the issue?
0 Likes
Anonymous
Not applicable

Hi Pratt,

1. Have you tried running the device with a debugger connected to see what the state/variables are set to when it "freezes"?

what variables I can check. can you suggest please? I can only see the void ApplicationEventHandler(uint32 event, void *eventparam) event type I guess, any thing else apart from this?

2.Please find the screen shot for the project settings attached. I don't think or observer code there are any big settings than this.

3. I have not run example project yet. But nature if the issue is random and at times complex to reproduce, but the more number of advertisements targeted to the device ie @100milli seconds, chance of getting freeze is more.

4.Depending on what your code for the event handler for the BLE radio is doing, that could be a source of the issue?

can you elaborate on this? how it will effect feezing?

under this CYBLE_EVT_GAPC_SCAN_PROGRESS_RESULT, I am calling RTC_GetUnixTime() to note time of received event and CyBle_SetDeviceAddress(data);

5. is there a way to do reverse engineering why stack gets freezed, if you have access to BLE stack.

Thanks,Regards,

Kumar.Settings.png

0 Likes
Anonymous
Not applicable

1. Variables that get changed/use frequently by you as your program runs. Return values from the API calls. Values passed to functions, etc. I wouldn't know which ones exactly to look at, but any that you set/get from the BLE stack would be a starting point.

2. Perhaps try increasing the scan window and intervals? Having such a short window and interval time should be fine, but setting a window shorter than the interval is ideal as that would allow some time where the unit is not scanning. (This does mean that you could possibly miss some packets however)

3. If you can reproduce the issue with a simple project, or start with a simpler project and add things back in until you reproduce the issue will allow you to determine (with trial and error) which things are aggravating or causing the issue.

4. Hmmm, try moving the call to the CyBle_SetDeviceAddress() outside of the event handler into the main code? (use flags to trigger it from the event handler) That way, you aren't slowing down the event handling as much (the CyBle_ProcessEvents() behaves like a polled ISR routine)

5. In the bottom of the debugger screen, there should be a stack or calls window that contains the functions called to reach the location you have the breakpoint at. Thus, if you can figure out what state/code location your code is reaching when it crashes, then you can set a breakpoint there and view the call stack of what jumps were made to get there.

0 Likes
Anonymous
Not applicable

Hi Pratt,

1. I will try reading any variables from BLE stack and see.

2. currently I am scanning all the time, if I reduce scan interval, I will miss advertisements.

3. I will check this.

4. I will check if I do this my purpose will be solved or not.

5. application is not crashing right, only BLE stack is crashing, so how can I see call stack? not possible I guess.

Thanks, Regards,

Kumar.

0 Likes
Anonymous
Not applicable

2. Yeah, I think I set my own project to 7.5 ms for both the window and interval for scanning.

5. Yeah, unless you have a variable or location that changes or gets called only when the BLE stack crashes, then it will probably not work.

0 Likes
Anonymous
Not applicable

Hi Pratt,

Good Morning. Today I was testing and I was able to reproduce the issue, but after the stack freezes, I never get a debug print in this frunction void ApplicationEventHandler(uint32 event, void *eventparam), so I don't get much internal info  regarding variables or state of BLE stack. Do you have any suggestions.

I am afraid I am running out of ideas now, kindly help.

Thanks, Regards,

Kumar.

0 Likes
Anonymous
Not applicable

My guess would be that somehow the chip is running to here:

CY_ISR(IntDefaultHandler)

{

    /***************************************************************************

    * We must not get here. If we do, a serious problem occurs, so go into

    * an infinite loop.

    ***************************************************************************/

...

}

But, without being able to halt the chip with the debugger and see if it is running in the while(1){} loop in this function, I wouldn't know how to confirm.

If you are no longer getting the ApplicationEventHandler() events either, that's pretty much my last idea on what could be happening; that it is getting stuck in the IntDefaultHandler() function.

If you are unable to determine with the debugger whether it is reaching that function, then my advice would be to open a case with the cypress applications/technical support for helping you debug your case and find the issue.

0 Likes
Anonymous
Not applicable

Hi Pratt,

Good Morning. Thanks, this looks excellent. your idea, closer to solution. Lets see. I will try to reproduce that and try see with debugger if it reaches there and try to keep a debug print in that.

But what makes the control of the code to reach that infinite loop. why is it reaching there? what could be the reason? Is BLE stack running out of memory/heap?

What function call should I use to print the run time usage of Heap? This helps in seeing is there any memory leak? I did not find any function to print run time usage of memory?  Kindly help.

Thanks, Regards,

Kumar.

0 Likes
Anonymous
Not applicable

Hi Pratt,

What function call should I use to print the run time usage of Heap? This helps in seeing is there any memory leak? I did not find any function to print run time usage of memory?  Kindly help.

Thanks, Regards,

Kumar.

0 Likes
Anonymous
Not applicable
  • Since memory is statically compiled at runtime (there is no dynamic memory allocation), you will only get "memory leaks" if you are calling functions in a recursive way, but it is more likely to be a stack overflow in that case.
  • When I ran into my code getting to that location, it was being caused by: Unhandled interrupts or invalid BLE API usage
  • For looking at memory usage, I run the chip in debugger mode using the SWD pins to halt/pause the CPU using a Miniprog3; This allows me to single-step instructions and the like. This is also the easiest way to see the memory usage. (you will need to connect the Miniprog3 or other debugger to the SWD pins and configure them for SWD usage rather than GPIO under the project settings)
  • The BLE commands will return CYBLE_ERROR_MEMORY_ALLOCATION_FAILED  if they weren't able to use memory for their function. Otherwise, I don't see any way to view the memory without direct interaction from the debugger...
0 Likes
Anonymous
Not applicable

Hi Pratt,

Good Morning. OK Fine. what causes stack overflow in that case? probably too many advertisements?

Also, I see one more problem, some times I see time is returned wrongly by the function, RTC_GetUnixTime();

This happens some times after one day or with in one day, so randomly, after that again I need to use the function  RTC_SetUnixTime(); to correct it in runtime.

This is one more big issue, why time goes bad not sure. any idea why this happens and what can be the cause.

Apart from these three lines of code, nothing is done with respect to RTC.

    RTC_Start();

    RTC_SetPeriod(1u,32768); 

    current_time  = RTC_GetUnixTime();

RTC_SetUnixTime(); - set time correctly on the power up of the device.

What problems do you see here?

Thanks,Regards,

Kumar.

0 Likes
Anonymous
Not applicable

The wikipedia definition of stack overflow is pretty good: Stack overflow - Wikipedia

So, if you had a function

uint8 fish(uint8 test) {

     return fish(test);

}

Calling this function would cause a stack overflow...

As far as the RTC component:

You will probably want to check the low frequency clock settings page, as that page is what allows the RTC to work: It ties a WDT to the RTC clock, and uses the WDT to run the RTC clock; If you are messing up the WDT somehow, then that could be the cause.

Also, if you are writing/saving to flash in your code while the BLESS is active, that will cause things to mess up too.

0 Likes
Anonymous
Not applicable

Hi Pratt,

I do not have any recursive function as part of my application code.

Please find the clock settings page attached to the email. I have not updated desired frequency in LFCLK in the attached diagram. Will this cause a problem? kindly look at the settings and let me know.  See if the WDT settings are correct?

CySysClkWcoStart(); - does this function also require for RTC?

writing/saving to Flash when the BLE stack is active is harmful? some posts say harmful and some say no. This will affect RTC?

So the right procedure to write to Flash is void CyBle_Stop(void); write to flash  and then call again

CYBLE_API_RESULT_T CyBle_Start(CYBLE_CALLBACK_T  callbackFunc);

Please confirm. but if I don't do this, timestamp will comepletely go wrong or small inaccuracy. because I see time stamp completely go wrong.

Thanks,Regards,

Kumar.

0 Likes
Anonymous
Not applicable

Hi Pratt,

Good Morning. Hope you had a great week end and you came back fresh.

I found some critical info today, I am able to reproduce the issue, break point never hit this function CY_ISR(IntDefaultHandler).

control moves freely here

for(;;)

    {

         CyBle_ProcessEvents();

    }

break point comes here always, means BLE stack is receiving messages, but not able to pass it to application event handler.

CY_ISR(CyBLE_Bless_Interrupt)
{
    CyBLE_pf_bless_event_hdlr();

}

Please find the working/freezing of BLE stack screenshots attached to the email. I am attaching screenshots of both working and non working so that we get clue.BLE1.pngBLE2.pngBLE3.pngBLE4.pngBLE5.pngBLE6.pngBLE7.png

Can you kindly guess what might be the problem.

Thanks, Regards,

Kumar.

0 Likes
Anonymous
Not applicable

Hi Pratt,

Good Morning. Any support on the above mentioned clues please?

Kindly share your thoughts please.

Thanks, Regards,

Kumar.

0 Likes
Anonymous
Not applicable

Hi Pratt,

Good Morning. Any support on the above mentioned clues please?

Kindly share your thoughts please.

Thanks, Regards,

Kumar.

0 Likes
Anonymous
Not applicable

Hello Kumar,

Sorry; I was unavailable for the past 4-5 days for a business trip...

I'm glad you were able to determine if that the application is not going to the default Interrupt handler

Looking at your images, it seems like one of the images has an interrupt occurring while the code is handling a BLESS ProcessEvents() call, but otherwise I can't see anything that would stand out as being an issue.

(An interrupt while handling the BLESS ProcessEvents() shouldn't be causing issues if the priorities for interrupts are set up for the BLESS interrupt to have highest priority.)

The RTC component requires a WDT to operate the ticking of the clock operation itself; This means that it will behave incorrectly if you use low power mode, or don't setup the WDT that the RTC component will use. It's pretty simple to setup, so I'll assume that you are doing that correctly if you just want to go ahead and double check it is functioning correctly.

The WCO crystal is generally used for the BLE component to function. The ECO is also used by the BLE system for operation.

If you are running the BLE system with advertising or scanning, or connected to a nother device, then you will have issues with the clock and timing being messed up to do the flash writing. Generally, it is recommended to only modify the flash memory when the BLE system is "off" (not scanning, advertising, or connected) otherwise you will get incorrect functionality. It might affect the RTC, but I would suspect it would only cause incorrect RTC timing at the worst, and most likely not cause any issues at all.

Here is some code that I've used to check whether I can save the data to the flash without affecting the BLE communications and other things:

void CheckFlashReadyToSave() {

    if(cyBle_pendingFlashWrite) {

        if(!advertising  && !scanning && !DeviceConnected && Not_Busy)) { //Not_Busy is a flag to control the application, not relevant for your application

            apiresult = CyBle_StoreBondingData(0);

            if(apiresult == CYBLE_ERROR_OK) {

                //flash write finished

                FlashWriteDone = true; //flag to signal successful flash write

            }

        }

    }

    if(UpdateFlashTime && !BLEActive) { //Check if the BLE is active to start a new flash write when the flash update time comes

        UpdateFlashTime = false;

        UpdateFlashMemory(); //Starts application write data to the flash chip

    }

       

}//only writes flash if in idle radio state

0 Likes
Anonymous
Not applicable

Hi Pratt,

Thanks for the update. Thanks for the response.

so even though BLE stack is freezed, CyBLE_Bless_Interrupt is occurring means BLE stack is able to receive messages from outside world.

Please confirm here my understanding.

I have sent you two pics one is not freezed and working and another is freezed and not working. There is a clear difference between the working and non working flow.

After the interrupt occurs, it is able to move to other functions like stack task handler and stack manager process ble events functions in the working one.

In the freezed one it is not able to move. Clear clue is here. So what might be the reason. I am able to see 180 advertisements sometimes, will this be a problem.

since more advertisments are pushed in to the device, it ran out of memory?? is this a problem??

or else more advertisements are pushed but not popped out by application event handler.

what can be the cause? we need to be able to guess? If some internal BLE stack details are known it is easy to crack this problem.

Kindly provide your views.

Thanks, Regards,

Kumar

0 Likes
Anonymous
Not applicable

Hmmmm; I could see too many advertisements causing an issue if it is buffering them all and it runs out of space. Handling the events for the advertisements received from scanning would be the only solution for that situation.

The BLESS handles sending out the advertisements, so I wouldn't see that as an issue.

hima​ might have better insight into this.

The internal BLE stack is proprietary to the cypress company (afaik), so digging deeper will only work so far...

Seeing 180 advertisements is a very large number however; especially if this is with you handling/dealing with the advertisement events in your application software. Would it be possible for you to run two different test cases for your software? One in the heavy advertisement area, and one in an isolated environment?

Regards,

Epratt

0 Likes
Anonymous
Not applicable

Hi Pratt,

I am handling all the advertisements received by BLE stack, from Application event handler.

What I am thinking is since I am spending more time in Event handler, too many advertisements are piling up in the BLE stack buffer and not removed by event handler, since event handler is slow is the root cause of the problem.

But this will be a big limitation of the system right.

Can you please connect me to Hima, so that we can get his expert advice.

I guess earlier when I was not spending much time in application event handler, I did not see this issue often I guess, when I am spending more time only I am seeing this issue.

But there should be a solution for this, otherwise this will be a big drawback in the system.

Please reply.

Thanks,Regards,

Kumar.

Hmmmm; I could see too many advertisements causing an issue if it is buffering them all and it runs out of space. Handling the events for the advertisements received from scanning would be the only solution for that situation.

The BLESS handles sending out the advertisements, so I wouldn't see that as an issue.

0 Likes
Anonymous
Not applicable

If you open a support case with Cypress they will be able to help you more definitely fix the ISR taking too long and clearing up code.

I believe you can directly message Hima through the link to his profile.

Ideally, if you can reduce the event handler to only do flags in the event handler, and then do the actual processing later, that would be faster for handling the events.

0 Likes
Anonymous
Not applicable

Hi Pratt, Good Morning!!

While writing NON BLE configuration data to supervisory flash do I need to stop BLE and start again, otherwise it will affect RTC? Can you Please confirm.

Thanks, Regards, Kumar.

0 Likes
Anonymous
Not applicable

Writing to SFlash will modify the IMO to be 48 MHz while doing so, thus you should avoid doing so if your IMO clock is running at a different frequency. I don't know the RTC behaviour during a flash write, but either:

  • It will skip the RTC ticks until done writing flash
  • It will work just fine
  • It will tick at the wrong timing, causing a missed count or multiple counts
0 Likes
Anonymous
Not applicable

Hi Pratt,

Thanks for the email. How can I check that IMO clock is running at 48 MHZ?

Do I need to write any function for this? or just tick the clock IMO in the

design to 48 MHZ. that's it right. Please find the screen shot attached to

the email. Will this ensure it is running at 48 MHZ? or any function I

need to call? Please confirm.

Based on your advice(for BLE stack freeze issue), I was trying to reach

Hima by profile link, but not successful. I am not able to send message to

him, it is not allowing me.

Can you kindly help me to connect to him as soon as possible. Is there any

direct email I can contact him. Please help as soon as possible.

Thanks, Regards,

Kumar.

On Fri, Oct 13, 2017 at 6:40 PM, e.pratt_1639216 <

0 Likes
Anonymous
Not applicable

If you set the Clock for 48 MHz in the clock/design setup, then it should stay that way unless you explicitly change it.

If you can't get ahold of hima​ directly, I would suggest opening a case with the cypress support team to help you figure out why your software BLE stack is freezing.

Create_Support_Case.PNG

0 Likes
user_2457466
Level 3
Level 3
10 replies posted 5 replies posted 5 questions asked

Hi Kumar,

Did you ever get this issue fixed ?

We face the exact same issue.

best regards,

Martin

0 Likes