NDK helloworld example on EVM6678l doesn't work without a board reset

Hello,

I've updated the NDK version to 2.22.3.20, however i've retained the same MCSDK version (2.0.5.17) now I get the following output if I try to run the helloworld example for 2nd time without a board reset

[C66xx_0] QMSS successfully initialized
CPPI successfully initialized
PA successfully initialized

TCP/IP Stack 'Hello World!' Application


TCP/IP Stack 'Hello World!' Application

PASS successfully initialized
Ethernet subsystem successfully initialized
Ethernet eventId : 48 and vectId (Interrupt) : 7
Verify_Init: Expected 16 entry count for gTxFreeQHnd queue 736, found 31 entries
Verify_Init: Expected 0 entry count for gRxQHnd= 704, found 101 entries
Verify_Init: Expected 0 entry count for Queue number = 704, found 101 entries
Verify_Init: Expected 0 entry count for Queue number = 899, found 1 entries
Verify_Init: Expected 0 entry count for Queue number = 4095, found 2 entries
Warning:Queue handler Verification failed
Registration of the EMAC Successful, waiting for link up ..
Service Status: DHCPC    : Enabled  :          : 000
Service Status: DHCPC    : Enabled  : Running  : 000
00000.000 PBM_free: Invalid Packet
Service Status: DHCPC    : Disabled :          : 000

Network Shutdown
ti.sysbios.heaps.HeapMem: line 322: assertion failure: A_invalidFree: Invalid free
xdc.runtime.Error.raise: terminating execution

Whereas I get the proper output on reset

Harsha J K said:

[C66xx_0] QMSS successfully initialized
CPPI successfully initialized
PA successfully initialized

TCP/IP Stack 'Hello World!' Application


TCP/IP Stack 'Hello World!' Application

PASS successfully initialized
Ethernet subsystem successfully initialized
Ethernet eventId : 48 and vectId (Interrupt) : 7
Registration of the EMAC Successful, waiting for link up ..
Service Status: DHCPC    : Enabled  :          : 000
Service Status: DHCPC    : Enabled  : Running  : 000
Network Added: If-1:10.251.201.104
Service Status: DHCPC    : Enabled  : Running  : 017

Can anyone tell me what is the reason for such behaviour, I suspect that since the NDK stack is not shutting down gracefully it leads to this.

Any suggestions on this?

Warm Regards,

Hi all,

One more update

After looking into the RTOS Object View I found that The StackTest thread priority has changed from 5 as per cfg file to 2 during exection.

Any suggestions?

Hi Harsha

You should be able to avoid the hardware reset if you do the following in software. After the first run and before you attempt a second run, you can do the following:

1. In the CCS Debug Perspective, select all cores and then go to Run --> Reset --> CPU Reset

2. Select Core 0, go to Run --> Reset --> System Reset

3. Select Core 0, go to Scripts --> EVMC6678L Init Functions --> Global_Default_Setup. 

Btw, just in case your Scripts menu is empty, you'll need to initialize it one-time. To do this, go to Tools --> GEL Files. A GEL files tab should open. Right click on the right side of this tab that opens and select 'Load GEL.' Browse to C:\ti\ccs_v5_x_x\ccsv5\ccs_base\emulation\boards\evmc6678l\gel and select evmc6678l.gel

On a side note, there is a newer version of MCSDK available MCSDK 2.01.02.06 at http://software-dl.ti.com/sdoemb/sdoemb_public_sw/bios_mcsdk/latest/index_FDS.html I would generally suggest sticking to version numbers of software components as provided in the MCSDK, since they have been tested to work well together, unless there is a compelling reason to update some components individually.

Hi Uday,

Thanks for your response.

Uday said:

1. In the CCS Debug Perspective, select all cores and then go to Run --> Reset --> CPU Reset

That works. But i would like to know is there any workaround to do this without any reset. 

Uday said:

3. Select Core 0, go to Scripts --> EVMC6678L Init Functions --> Global_Default_Setup. 

I have loaded the GEL script for the EVM. 

Uday said:

newer version of MCSDK available

I tried the same with the new version but no luck.

I would like to know if there is any other fix to this issue.

Harsha,

At this point in time it looks like the ability to restart NDK (and the dependent QMSS, CPPI, PA) is not possible from within the DSP program by leveraging the LLDs. Restartability of QMSS/CPPI is currently being implemented and tested and is anticipated in the near term. For NDK (and PA) restartability, we will submit an IR to address this issue. For now, you can either use the above method to do a System Reset --> Core Reset --> Init Script, or you can try and look into leveraging the Chip Support Library (CSL).

Uday,

Thanks for the response.

Hope the restart ability be fixed soon and please let me know once this is done.

Uday said:

System Reset --> Core Reset --> Init Script

This works fine.

Uday said:

leveraging the Chip Support Library (CSL).

Could you give some more insight on this ?

Warm Regards,

Uday,

I have another concern i.e., after I restart using

Uday said:

System Reset --> Core Reset --> Init Script

or Board reset and run the program again the following behaviour is observed :

Let's say I send message = "Message1" from host PC (using UDP) to the DSP I receive the message as "Message2"

If I run the program several times, this happens many a times. Very few times I am getting the correct message on the DSP.

I don't think it is to do with the reset, but something that is related to the network buffers on the DSP, I may be wrong.

Any suggestions on this would be welcome.

Hi Uday,

Is it possible to shutdown the NDK stack completely from within the DSP program ?

I need this so that I can start my application without a board reset or reset from CCS.

Waiting for your reply.