• Resolved

CC3220SF-LAUNCHXL: sl_Start hangs (new)

Part Number: CC3220SF-LAUNCHXL

Hi community !

I have read all the other threads on "sl_Start hangs" and they did not help.

It has been quite hard to chase that one down because I was not able to reproduce with a very simple code. Here below the simplest version of my code that still represents what I want to achieve:

void wifi_process(void) {

	switch(state) {
	case 2:
		sl_Start(0, 0, 0);
		break;
	case 20:
		sl_WlanSetMode(ROLE_AP);
		break;
	case 21:
		sl_Stop(0);
		sl_Start(0, 0, 0);
		DEBUG_INFO("Success! :)\r\n");
		break;
	case 22:
		return;
	default:
		break;
	}
	++state;
}

The 2nd call to sl_Start hangs for about 1min and then throw a "[ERROR] - FATAL ERROR: Async event timeout detected [event opcode =0x8]".

It must be a kind of timing issue, because when having a lot of debug output (on the UART ), the issue is NOT present, when removing debug output, the issue appears...

Another way to "toggle" the issue (present / not present) is to add (enough) other processes in the forever loop! Note that if only the wifi_process() function above is present in the forever loop, everything is fine...

Now, an even more funny thing is (which I hope can give you, experts out there, a clue) : while the issue was happening consistently using the debugger, I simply loaded another program (demo example from SDK 1.6) to the chip with UniFlash. Then, WITHOUT changing anything to my code, run the debugger again, and the issue was gone !!! This does not make any sense to me, and I truly hope someone can shine some light on this issue.

Thanks a bunch !

Note that all this happens while using the debugging functionality in CCS v7.3.

SDK 1.60.0.04

Below, more code to illustrate the weirdness of the problem...

NOT working:

// Forever Loop
    for(;;) {

    	/* The SimpleLink host driver architecture mandate calling 'sl_task' in a NO-RTOS application's main loop.       */
		/* The purpose of this call, is to handle asynchronous events and get flow control information sent from the NWP.*/
		/* Every event is classified and later handled by the host driver event handlers.                                */
		sl_Task(NULL);

		/* Modules process functions */
		wifi_process();
		other_process_A();
		other_process_B();
		other_process_C();
		other_process_D();
		other_process_E();
		other_process_F();
		other_process_G();
		other_process_H();
		other_process_I();
		other_process_J();
		other_process_K();
		other_process_L();
    }

Working !

// Forever Loop
    for(;;) {

    	/* The SimpleLink host driver architecture mandate calling 'sl_task' in a NO-RTOS application's main loop.       */
		/* The purpose of this call, is to handle asynchronous events and get flow control information sent from the NWP.*/
		/* Every event is classified and later handled by the host driver event handlers.                                */
		sl_Task(NULL);

		/* Modules process functions */
		wifi_process();
//		other_process_A();
//		other_process_B();
//		other_process_C();
//		other_process_D();
//		other_process_E();
//		other_process_F();
//		other_process_G();
//		other_process_H();
//		other_process_I();
//		other_process_J();
//		other_process_K();
//		other_process_L();
    }

  • In reply to Benjamin Moore:

    Hi Vincent,

    The issue seems to be caused by these statements in the code:

    Status = sl_Stop(0);
    Status = sl_Start(0, 0, 0);

    I expect that by calling sl_Stop(0) and sl_Start(0,0,0) back to back, you are not giving the network processor enough time to enter hibernate before attempting to wake it back up. The result is that the wake-up signal from the sl_Start(0,0,0) call is missed while the device is shutting down, which causes the host driver to generate the fatal error for the  host. There is a minimum hibernate time of 10 ms for the device, which I believe this issue is related to.

    By enabling the extra debug print statements, you give the network processor enough time to shut down and so the test passes.

    You can fix the issue by increasing the value of the parameter passed to the sl_Stop(). I tested with sl_Stop(1) and it seems to be fine, though I would typically recommend something like 100 or 200 unless the shorter time is absolutely critical to the application.


    Best Regards,

    Ben M

  • In reply to Benjamin Moore:

    Hey Ben,
    Alright. Thanks for the update !
  • In reply to Benjamin Moore:

    Hey Ben,
    I have tested with a delay of 10ms and everything is working fine!
    This is great news! Thank you very much.

    Though, I would mention this in the documentation. At the moment every example uses a value of 0 for timeout when needing to restart the device.

    Thanks for your time !