C6455 ndk send() error 35

Dear guys,

I meet a problem when using the C6455 chip to run a Gigabit network project (based on ndk 2.0).

For some reason, I change the DSP/BIOS CLK to 100us(0.1ms) and set NDK prdNdk period 1000 ticks (0.1*10000ms), while in helloWorld.pjt example, I see the DSP/BIOS CLK is 1ms and prdNdk period is 100 ticks. Does this matter?

The C6455 chip will process one image about every 25ms. There are mainly three tasks in my project. Task A is of priority 10, and runs about 5ms continously during every 25-ms period. Task B is of priority 8, and runs about 4ms continously during every 25-ms period. The NDK Task TestStack is of priority 5, and it sends image data to an image server. From the server we can see the load of the Gigabit network is about 19%, so I think the speed is enough.

Also, there are some HWIs in the project. HWI A occurs about every 17us 960 times during every 25-ms period, and HWI B occurs about 2us just after every HWI A. There are some other HWIs whose intervals are longer. All of the HWI ISRs last a little time, not longer than 2us from my analysis.

The problem is that after running some hours, the project may meet error: NDK's send() function returns "-1" and fdError() returns "#35". The TCP SENDTIMEOUT option is set 5s which is enough in my opinion.

Where is the reason, the tasks of higher priorities or the frequent HWIs?

Thanks in advance! Wish your help.

_____________________________________ Start a New Thread

Francis-

> I meet a problem when using the C6455 chip to run a Gigabit network
> project (based on ndk 2.0).
>
> For some reason, I change the DSP/BIOS CLK to 100us(0.1ms) and set
> NDK prdNdk period 1000 ticks (0.1*10000ms), while in helloWorld.pjt
> example, I see the DSP/BIOS CLK is 1ms and prdNdk period is 100 ticks.
> Does this matter?

It sounds like you're saying that your current CLK tick and NDK tick settings are 100
usec and 100 msec, and it seems to work Ok, but you're asking whether there is some
reason the helloWorld settings (reversed from yours) are better.

If that's correct, then I suggest to look up docs about overhead used for NDK timer
tick processing. BIOS clock tick overhead is well documented, and the tradeoffs of
reducing to 100 usec tick (increased overhead) are well-understood. Perhaps the NDK
documentation discusses this...

> The C6455 chip will process one image about every 25ms. There are
> mainly three tasks in my project. Task A is of priority 10, and runs
> about 5ms continously during every 25-ms period. Task B is of priority 8,
> and runs about 4ms continously during every 25-ms period. The NDK Task
> TestStack is of priority 5, and it sends image data to an image server.
> From the server we can see the load of the Gigabit network is about 19%,
> so I think the speed is enough.
>
> Also, there are some HWIs in the project. HWI A occurs about every 17us
> 960 times during every 25-ms period, and HWI B occurs about 2us just
> after every HWI A. There are some other HWIs whose intervals are longer.
> All of the HWI ISRs last a little time, not longer than 2us from my
> analysis.
>
> The problem is that after running some hours, the project may meet
> error: NDK's send() function returns "-1" and fdError() returns "#35".
> The TCP SENDTIMEOUT option is set 5s which is enough in my opinion.
>
> Where is the reason, the tasks of higher priorities or the frequent HWIs?

The obvious first guess is a memory leak. Are you able to process a known, fixed
sequence of images? If so, then does the time it takes for the error to occur
(approximately) repeatable?

-Jeff

_____________________________________ Start a New Thread