Attempting to reset CC9215 module with customizeRestart(), I have got error "watchdog has expired. target detached".

Hello according to the API reference manual the only platforms supported are listed below:

Category: BSP Customization Hooks
This function restarts the application. The kernel, TCP/IP stack, and the application are restarted. The application is not reloaded from flash and the H/W initialization is skipped. The results are unpredictable if the application’s image in RAM has been overwritten.


THIS CODE MUST BE CUSTOMIZED FOR YOUR BOARD. The implementation below is for NET+OS development boards only.

You may need to reinitialize hardware on your board before restarting the application.

Include file
#include “nareset.h”

Library dependencies
Platforms supported
NS9360 Rev A, NS9750 Rev A, ConnectCore 9C
void customizeRestart(void);
See also

I am trying to reset CC9215 module. Did you find any solution to this problem?

OK lets talk turkey here.

customizeRestart calls customizeReset.
customizeReset calls NAReset

Description of NAReset:

“This function performs a hard reset of the NET+ARM development board. The function does not attempt to gracefully shutdown application or the kernel.”

It definitely sets up the watchdog.

It is probably something you do NOT want to do while in the debugger.

What (exactly) are you trying to do and in what environment (debug, production, other…)

I am trying to restart a CC9215 board when different situations happen.

For example, sometimes I am getting a timeout when trying to read a socket.
The only solution to this problem is to shut down and turn on the board.

Instead of doing that, I would like the system to automatically restart.

I am using Net OS 7.5.

Hmmmm. If you are getting a timeout on a socket, are you using a select? If not, you should be. A select would allow you to timeout on waiting for something to happen and then try again. Resetting a board because a socket timed out is a real sledgehammer approach.

Again are you doing this attached to a debugger (such as the jlink) or in production mode?

Yes I am using Select.

Yes I am using Jlink.

When I get the timeout on reading the socket 3 times in a row I was thinking of restarting the board.

I need to understand the following. When the socket in question times out, are you sure that there was actually something to read or was there nothing to read? If there was nothing to read then I would expect the select, FD_ISSET and all that stuff to timeout. Also is your timeout reasonably long enough for the rat eat which the sending programs sends messages?

Also to go back to the original point, if you perform a reset on the board, I would expect the debugger to disconnect.

I am sure there was something to read.

I am sure the timeout is long enough, I have used really long timeouts to be sure this is not the problem.

Sometimes the program timeouts, but after trying again, it reads normally.

The problem is that some other times, once a timeout happens, it will keep happening and the only solution is to restart the board.

Thanks for your time.