Hi,
I recently upgraded from Code Composer 2.21 to Code Composer 3.3. At the same time, I upgraded from DSP/BIOS 4.90.270 to DSP/BIOS 5.33.06 and from NDK 1.7.1 to NDK 2.0.0. I also upgraded my code generation tools to 6.1.11.
Before the upgrade, I have several DM642 boards which worked great as far as Ethernet is concerned (my application sends and receives UDP packets). After the upgrade, sending packets still works ok, but I can only receive a few UDP packets (the exact number depends on the size of the packets) before the socket I am receiving on starts timing out (I configure the socket with a SO_RCVTIMEO of 3 seconds), and my application does not get any more packets. If the UDP packet size is 1500 bytes (payload), I consistently receive 8 packets before the stack starts timing out. I tried using a smaller UDP packet size of 376 bytes and in that case I consistently receive 17 packets before the stack starts timing out.
The reason I tried the upgrade was to receive UDP packets larger than 3000 bytes. I saw in the NDK 2.0.0 documentation that the os.lib can be rebuilt along with some socket and NDK configuration changes to allow the stack to receive the large UDP packets. I have not rebuilt the os.lib yet, I am just trying to get the NDK 2.0.0 stack working with the prebuilt libraries that came with the NDK.
During the upgrade I ran into a few other problems related to the DSP/BIOS. The first one was a new parameter (initstackflag) added to the TSK_Attrs structure. After the upgrade, I was not explicitly initializing this parameter so the compiler initialized it to zero. This would cause all my TSKs to show "stack full" in the DSP/BIOS Kernel/Object view, even before the TSKs were started. I also had issues with the CSL function TIMER_getBiosHandle. Before the upgrade, this function returned a handle which we would then use to get the system timer period. After the upgrade, this function only returns 0xFFFFFFFF which was causing my application problems. I have instead started to use CLK_getprd(). I am wondering if there could be another change in the CSL or DSP/BIOS which is causing my ethernet problem. Or maybe I am doing something wrong in configuring the stack.
Any assistance would be greatly appreciated.
Paul Randall