This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Software instability problem of NDK2.0.0

An Gbe application based on NDK2.0.0 and DM648, we create a UDP task called udp_sendTsk() in the NDK main thread tskNdkStackTest() (i.e. the NDK starting thread). The data sending code in the udp_sendTsk() thread is as following:

 

while(1){     

      opt = sendto(s,sendBuf,1280,0,(PSA)&addrto,sizeof(addrto));

         if(opt != 1280)

{ printf("send err ! ");break;}

}

 

When the application runs for a while, DSP will be halted by calling UTL_halt(). There are some clues:

1.       We could not send UDP datagram continuously and stably if using keeping NDK with a NC_PRIORITY_LOW priority. Therefore we changed the NDK priority from NC_PRIORITY_LOW to NC_PRIORITY_HIGH by the following line:

rc = NC_SystemOpen( NC_PRIORITY_HIGH, NC_OPMODE_INTERRUPT );

2.       We analyze the DSP/BIOS->Message Log->Excution Graphic Details output:

553765   SWI: begin KNL_swi (TSK scheduler) (0xe00cef58)

553766   SWI: end   KNL_swi (TSK scheduler) (0xe00cef58) state = done

553767   SWI: begin KNL_swi (TSK scheduler) (0xe00cef58)

553768   SWI: end   KNL_swi (TSK scheduler) (0xe00cef58) state = done

553769   SWI: begin KNL_swi (TSK scheduler) (0xe00cef58)

553770   TSK: blocked tskNdkStackTest (0xe00ceddc) on <unknown handle> SEM

553771   TSK: running dynamic TSK (0xe009624c)

553772   SWI: end   KNL_swi (TSK scheduler) (0xe00cef58) state = done

553773   SWI: begin KNL_swi (TSK scheduler) (0xe00cef58)

553774   SWI: end   KNL_swi (TSK scheduler) (0xe00cef58) state = done

553775   SWI: begin KNL_swi (TSK scheduler) (0xe00cef58)

553776   SWI: end   KNL_swi (TSK scheduler) (0xe00cef58) state = done

553777   SWI: begin KNL_swi (TSK scheduler) (0xe00cef58)

553778   SWI: end   KNL_swi (TSK scheduler) (0xe00cef58) state = done

553779   SYS abort called with message '*** TSK lock NOT CALLED IN TSK CONTEXT'

       Does this indicate the UTL_Halt() failure is caused by task switching between tskNdkStackTest() and udp_sendTsk(). Since the two is NDK scheduler tasks, we can do nothing to change this architecture.

3.       If we change the data sending code as following:


while(1){     

      opt = sendto(s,sendBuf,1280,0,(PSA)&addrto,sizeof(addrto));

         if(opt != 1280)

{ printf("send err ! ");break;}

TSK_sleep(1);

}

 

The application will not enter UTL_Halt() and operate normally for a very long time (but we can not be sure it is stable forever). However “TSK_sleep(1)” will dramatically degrades the UDP sending speed and is not acceptable for our application.

 

According to the descriptions above, we think this problem is highly related to NDK internal semaphore and task switching. Is NDK itself the problem source?