NDK shutdown/ reboot does not restore interface

Hi Michael,

I suspect that there is a Hwi after the NC_NetStop() is called which is causing the control back to NC_NetStart() and since it does not have valid arguments now fails to perform Network initialization and NDK stack doesn't come clean.

I would like to know the functionality of the below lines, part of the helloworld.cfg file :

/*
 * Enable Event Groups here and registering of ISR for specific GEM INTC is done
 * using EventCombiner_dispatchPlug() and Hwi_eventMap() APIs
 */

Ecm.eventGroupHwiNum[0] = 7;
Ecm.eventGroupHwiNum[1] = 8;
Ecm.eventGroupHwiNum[2] = 9;
Ecm.eventGroupHwiNum[3] = 10;

Is there anything that can be inferred from this?

Hi Michael,

Michael Erdahl said:

• Issue 'shutdown' command (or 'reboot')
• Observe NDK stack shutdown (or reboot) messages in CCS
• Do a pause, restart, and run

I'm curious why you are doing a pause/restart/run at this point?  Are you only doing that for the 'shutdown' case?

What happens if you do a reboot *without* doing the pause/restart/run?  Does the stack come back up?  Are you able to ping it and telnet back in?

----

Here's some data points:

I also tried some experiments with reboot and shutdown.  I did the following for both the Concerto (M3) and Freon (C674X):

• ndk_2_22_03_20
• bios_6_34_04_22
• xdctools_3_24_06_63
• Concerto EMAC driver:
  
  • TI-RTOS 1.10.00.11 (eng build)
• Freon EMAC driver:
  • nsp_1_10_01_08_eng

1. run the app
2. ping the target - success
3. telnet into the NDK - success
4. issue a reboot command - telnet connection is lost and stack reboots - success
5. ping the target - success
6. telnet into the NDK - success

I also tried:

1. run the app
2. ping the target - success
3. telnet into the NDK - success
4. issue a reboot command - telnet connection is lost and stack reboots - success
5. pause/restart/run
6. I'm still able to ping and telnet the target

I also tried:

1. run the app
2. ping the target - success
3. telnet into the NDK - success
4. issue a shutdown command - telnet connection is lost and stack shuts down - success
5. ping the target, no response - success
6. pause/restart/run
7. stack comes back
8. I'm able to ping and telnet the target

For these two boards, the behavior seems correct.  One difference, however is that my test apps are using static IP addresses.

Steve

Steve,

Thanks for the reply and your tests. 

Steven Connell said:

I'm curious why you are doing a pause/restart/run at this point?  Are you only doing that for the 'shutdown' case?

Sorry I was not clear enough on this point: I was only doing the pause/reset/run in the shutdown case. 

I ran the reboot test in both static and dhcp modes, both failed to restart the network interface.  I've instrumented my NDK/ NIMU stack and the problem currently resides in the QMSS/ CPPI configuration- I cannot get any free descriptors the second time around. 

Michael,

Michael Erdahl said:

I ran the reboot test in both static and dhcp modes, both failed to restart the network interface. 

Good data point.  This tells us that it's not related to the DHCP client.

Michael Erdahl said:

I've instrumented my NDK/ NIMU stack and the problem currently resides in the QMSS/ CPPI configuration- I cannot get any free descriptors the second time around. 

Another good data point.  I believe the QMSS/CPPI is part of the 6678 EMAC driver.  Given this, and that the problem does not happen on Concerto or Freon, I'd say that the issue you're running into is in the 6678 driver.

If so, I won't be able to help much with that.  We need to get some help from someone on the MCSDK team who knows the 6678 driver.

Steve

Hi Steve & Michael,

After running my NDK application which is nothing but modified NDK helloworld for C6678, when I terminate the debug session the PC becomes unstable and a list of log messages appear on the screen after which I would have to restart the PC. This issue occurs not always but sometimes.

What could be the possible reason for such a behaviour ?

OS : Ubuntu 12.04

CCS version : 5.3