Thanks for your reply.
I tried to disable watchdog using wdog_configure(FALSE) API in APPLICATION_INIT().
It reduces frequency of device reset but reset still has occurred irregularly.
So I don't think watchdog timer is a root casue of the reset.
According to my test result, belows reduce reset frequecy.
- disabling watchdog
- reducing ble_trace functions
- less Advertsing BT devices
- changing scan mode from HCIULP_ACTIVE_SCAN to HCIULP_PASSIVE_SCAN
These are show that the reset is related with something of a overload data.
Is there any restriction or limitation or guideline for scanning performance of 20737?
I need to send scanning list to other device via UART or some other way during HIGH_SCAN in a crowded area.
So device reset is entry barrier to use this tag for me.
Plus, I guess reset is occurred by stack overflow so I checked RAM.
To check free memory in RAM, I used cfa_mm_MemFreeBytes() but this function returns always the same value, 19080 even if funtion call stack is in the different level.
And blecm_DidStackOverflow() returns always TRUE(1).
I just added #include "Thread_and_mem_mgmt.h" in the source and APP_PATCHES_AND_LIBS += Thread_and_mem_mgmt.a in the makefile.
Could you let me know there is something wrong with this usage?
The cfa_mm_MemFreeBytes() should return a zero if there is no stack overflow, and it appears from your description that you are getting a non-zero 19080.
There is some confusion about two functions.
As the explain you quoted,
// This returns the number of bytes free till the top of RAM at the point of invocation.
// This function returns 0 if a stack overflow was not detected before
// Else it detected an overflow.
The blecm_DidStackOverflow() should return zero if there is no stackoverflow.
What I wanted to say is I wonder blecm_DidStackOverflow() returns '1' even if the device works properly.
To go back to my main question,
I don't change anything from hello_client application and download the application to my 20737 tag.
And then hello_client device tried to high scan without hello_sensor advertising packet.
Then, while the client device tries to scan more than 40 devices, the reset occurs.
Did you tried to scan on environment which has more than 40 advertsing devices?
i don't have such a populated environment of more than 40 devices, usually not more than 10. On the other hand, can you repeat this in a quieter environment?
Of cause, the reset doesn't occur in a quieter environment.
I am planning to use this tag in the crowded area which has a lot of BT devices.
That's why I test in the populated environment.
Is there any performance measuring data or something regard with scanning?
i think it will be a better idea to get a local rep to discuss with you on this. I have attached a list of Distributors here and you may contact them for assistance. are you based in korea? do include me in your email to them...
Note that cfa_mm_MemFreeBytes() returns the amount of available RAM and should equal a non-zero value.
blecm_DidStackOverflow() should return zero if there is no stack overflow, true. However, it needs to be initialized first. To do so, blecm_StackCheckInit() needs to be initialized within your Application Create function.
Your problem sounds similar to one I experienced with the BCM20737 TAG board. My WICED Smart App (a modified Heart Rate Sensor) would go into one of my initialization functions at startup and right in the middle of sending bytes out on the SPI interface, the BCM would seem to just reboot itself for no particular reason.
It turns out that the operating system very badly wants to go to sleep.. and it asks permission before it goes to sleep, and then if nobody says "stay awake" it goes to sleep... only to wake up moments later and repeat the whole scenario again... and again... and again... every few seconds restarting itself.
The way to stop this is to create and register a callback function for "low power mode queries"... when the operating system wants to go to sleep it calls your function. If you return a zero it will stay awake.
When I did this the problem went away. I put a trace in my callback and found that it was being called many times per second in rapid succession. Apparently this is the only way the operating system knows your app is doing something and doesn't want to sleep yet. When you are ready to go to sleep, change your callback return value to a non-zero. ....zzzzzzzzz
This is described somewhat vaguely in one of the programming manuals. Here is my code:
UINT32 device_lpm_queriable(LowPowerModePollType type, UINT32 context)
You would also have to register the callback in your App Init code as follows:
You will need
and will also probably need to call
before registering the callback.