11 Replies Latest reply on Jun 22, 2015 4:51 PM by gdepaula

    Too many debug log causes the device reset

      SDK: WICED-Smart-SDK-2.2.0

      Tag: 920737.

      app: hello-client.



      I am faced with the Tag-reset issue during high scan using the hello-client application.

      When I try high scan, hello_client_advertisement_report() calls blecen_leAdvReportCb() and a number of TRACE messages(embedded in Blecen stack) are displayed and the tag reset itself.

      I remove blecen_leAdvReportCb() as a comment, and then the device reset doesn't occur.

      But I add my own logs using ble_trace about 20 lines at 2 sec intervals without blecen_leAdvReportCb() but it also occurs reset during high scan.

      Actually, there are so many BT devices(up to 30) in my area and advertising report is called so many times.

      Therefore, In my opinion, too many logs cause a device reset.


      I thought it happened by watchdogs so I tried to disable wathdog and kick but it was no use.

      - disabling watchdog(adding GLOBAL_DEFINES += WICED_DISABLE_WATCHDOG in the makefile)

      - adding wdog_restart() between logs per lines.


      Do you have any idea about this problem?(incresing trace buffer, or other way to disable watchdog, disable stack logs except for my app's log, or something)




        • 1. Re: Too many debug log causes the device reset

          This thread described how to disable the watchdog (use with care): Increasing/Disabling the watchdog timer

          • 2. Re: Too many debug log causes the device reset

            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?




            • 3. Re: Too many debug log causes the device reset

              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.


              • 4. Re: Too many debug log causes the device reset

                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.

                UINT32 cfa_mm_MemFreeBytes(void);

                // This function returns 0 if a stack overflow was not detected before

                // Else it detected an overflow.

                UINT8 blecm_DidStackOverflow(void);


                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?

                • 5. Re: Too many debug log causes the device reset

                  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?

                  • 6. Re: Too many debug log causes the device reset

                    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?




                    • 7. Re: Too many debug log causes the device reset

                      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...

                      • 8. Re: Too many debug log causes the device reset

                        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.



                        • 9. Re: Too many debug log causes the device reset

                          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)


                             return 0;


                          You would also have to register the callback in your App Init code as follows:




                          devlpm_registerForLowPowerQueries(device_lpm_queriable, 0);


                          • 10. Re: Too many debug log causes the device reset

                            Very helpful post userc_7511


                            We really appreciate the help.

                            • 11. Re: Too many debug log causes the device reset



                              You will need

                              #include <devicelpm.h>


                              and will also probably need to call



                              before registering the callback.