Watchdog

Hello Dan,

Have you verified that it the code is still running?  There could be a number of reasons why there was a loss of connection, including not setting the parameter for indefinite advertising.  In your code, you should have one of the buttons do something like toggle the LED.

Thanks,

Thanks greenja,

I don't really know whether the code is still running.  I have about 20 prototypes running at various times and most of the time they behave properly.  I have LEDs, but use them only for debugging, I can't afford the power they draw.  The device that failed had been running for a couple of weeks, I don't know the exact circumstances when if failed, it was out in the field.  All I know is that a reset brought it back to life.  So I'd like to have a watchdog as a failsafe, but don't know how to interface it with the ble stack and with the power management.

Dan

Hello Dan,

My suggestion would be to bring that prototype back to your bench and do the proper testing and quality assurance.

To set up the watchdog timer, you can find the details in the User manual.  Just initialize it to an appropriate interval and then set an Osal_timer event interval less than the watchdog.int to clear it.  It would just be another event.

Thanks,

Thanks for that.

The devices have been fairly well tested already.  I've just found another one that has failed.  It's been sitting idle with no connection to it, so all that's been running would be the stack and the very basic part of TI's operating system, waiting for a connection before it runs any of my application.

Power is an issue.  The maximum watchdog timeout is one second, which means that I have to wake less than that to service the watchdog.  And that is much less than my advertising rate of every two seconds.  I was hoping to somehow integrate the watchdog with the ble stack when it advertises, but doesn't seem feasible when I'm advertising at two seconds and the watchdog needs servicing before one second.

How robust is the ble stack?  Has anyone been using it in a similar configuration where it has to advertise at a slow rate over a long period of time?

Dan

You need to determine why there was a loss of connection.  Without details of your systems, anyone would only be guessing.

What is the device connecting too? Where is it located, are there interfering frequencies or other BLE devices(cell phones) that may appear? What is the last signal strength?

What is the battery voltage? Are you running code that terminates connection on low battery voltage?

In your code (done at the time of your initial testing)  all these variables should have been in place so that at every step data is available to see what state the device is in.  That is what I meant by quality assurance.  If all that had been done on the bench, then they should be easily reimposed in the field.  If ithey are prototypes, then they are still test units. :)

Set flags at every step and monitor all factors that can cause loss of connection, battery voltage, signal strength, etc.

If the watchdog timer can't work for you, you may have to redesign your system with a battery that has more capacity.