This topic discusses several common questions when trying to debug TI's NDK (Network Developer's Kit) in C64 and C64+ DSP Processors. Important! With the recent release of NDK 2.0 and its new set of features, this page will be continuously updated. Please stay tuned. Q: Licensing and availabilityPlease check this updated page for information on licensing and availability. Q: How is NDK delivered? Does each board have a specific release? Or is there a common version of NDK for all the boards?Please check this updated page for information about NDK releases. Q: Why doesn't my pre-production DM648 EVM work with NDK?NDK example code works on DM648 production boards with the NDK and drivers provided in the DVSDK. However pre-production boards have some special requirements:
static Uint8 bMacAddr[] = {0x00,0x0e,0x99,0x02,0xaa,0x25};
-d"INPUT_CLOCK_FREQUENCY_62_5MHZ"or -d"INPUT_CLOCK_FREQUENCY_125MHZ" Q: Why does the DHCP client seems to give up after a certain period of time if the Ethernet cable is disconnected when the NDK boots up?If the Ethernet cable is not connected when the board is booted, the DHCP client service attempts to obtain an address for a certain period of time (around two minutes) and then shuts down. Starting with releases 1.8 and newer, NDK incorporates a DHCP reset function in <client.c> that periodically checks for new servers in case a DHCP is not found right from the start. Basically it creates a task The output then becomes: TCP/IP Stack Example Client Using MAC Address: 00-0e-99-02-70-04 Service Status: DHCPC The updated <client.c> is available in the example code supplied with the Network Support Packages. Together with NDK evaluation releases, they can be downloaded from the NDK Update Advisor. Updating the NDK is not mandatory, since <client.c> file can be used by release 1.7. Q: Why can't I debug the EMAC and PHY device drivers in the NDK example projects?This is because the hardware initialization routines are inside the HAL libraries. For example, the DM6437 EMAC device driver is the library <hal_eth_dm64lc.lib>. Only assembly step-by-step debugging is allowed (more on this below). However, all NDK examples have callback routines from the device driver that help verify if it is working properly. In the case of DM6437, the file <evmdm6437init.c> contains two callback functions:
If device driver source code debugging is really needed, this is possible by including the HAL and low-level source files into the CCS project (typically installed under %NDK_INSTALL_DIR%/packages/ti/ndk/src/hal/<name_of_the_board>). The build process will overload the device driver function calls when using the libraries. For additional details about the files that comprise the device driver source code please check this page. Q: What happens during NDK startup? What is the sequence of events?Taking as an example the NDK for the DM6437, the sequence of events at startup is below:
TCP/IP Stack Example Client
Using MAC Address: 00-01-02-03-04-05 (or whatever number is configured)
Service Status: DHCPC : Enabled : : 000 Service Status: Telnet : Enabled : : 000 Service Status: HTTP : Enabled : : 000 (and so on)
Service Status: DHCPC : Enabled : Running : 000
Link Status: 100Mb/s Full Duplex on PHY 1 (or whatever speed and PHY you are using)
Network Added: If-1:192.168.0.2 (or whatever interface and IP address are configured)
For additional details please see section 3.3 of the NDK User's Guide (spru523). Q: Why does the Kernel Object Viewer show a "daemon Stack Full" warning? (fixed in NDK 1.92)The Kernel Object Viewer performs this verification by checking if the pattern 0xBEBEBEBE exists at the end of each task stack. However, since the memory used by the daemon task is not initialized to this value when the program loads, the KOV reports that the stack is full. If you want to test if this is happening in your system, before loading your software you can fill the DSP memory: go to menu Edit -> Memory -> Fill. Be careful not to fill the entire memory space, since the process may take a while to complete. A more efficient workaround is to use the linker command file to fill this memory for you by adding the command fill = 0xBEBEBEBE after the .SDRAM$heap section. First, locate this section in the linker command file generated automatically by the DSP/BIOS; copy its declaration to the <client.cmd> file; add the command fill = 0xBEBEBEBE after its definition; finally, wrap this declaration with the SECTIONS {} command (see below an example extracted from the client project): SECTIONS { .SDRAM$heap: { SDRAM$B = .; _SDRAM_base = .; SDRAM$L = 0x20000; _SDRAM_length = 0x20000; . += 0x20000; } > SDRAM fill = 0xBEBEBEBE } You will get some linker warnings about redefining sections, but you can disregard them for this test. Please keep in mind that this is a workaround to make the instrumentation tools work properly with the NDK 1.8. Q: Does NDK support Jumbo Packets?New for NDK 2.0!!! Support for Jumbo packets is now available - the only development board that currently supports it the mezzanine card of the C6455 EVM. Please check the NDK 2.0 Release Notes for additional information on how to enable support. Legacy releases do not support Jumbo Packets. Q: C6455 EVM has a Gigabit EMAC. Does the hardware support Jumbo Packets?The EMAC peripheral in C6455 Mezzanine card supports packets up to 65536 bytes (16-bit). This board has a Broadcom BCM5464 external PHY connected in RGMII mode. The EMAC on this device has an internal memory buffer that can hold up to 8 kB, but L2 memory can also be used. Please see section 2.2 of the EMAC peripheral User's Guide for C6455 (spru975). Apart from this, the SW Operation of Gigabit Ethernet Media Access Controller on TMS320C645x DSP (spraa90) describes in detail the support of jumbo packets on the C6455. It has an entire description of the system and sections 6.3 and 6.4 contain considerations about the available buffer sizes and even PHY limitations. Q: Does DM648 EVM support Gigabit Ethernet? What about Jumbo Packets?Yes, the DM648 EVM has a PHY device that supports Gigabit Ethernet speeds, and the NDK device driver provides support for Gigabit Ethernet links. However, the hardware does not support Jumbo Frames (typically around 9000 bytes but can assume any value), since the DM648 EMAC peripheral has a limitation to receive frames up to 2047 bytes (headers included). This is still above the standard value of 1518 bytes. Even so, all NDK releases can transmit regular sized packets faster than 100 Mbps. For additional information please refer to the 3 Port Switch Ethernet Subsystem User's Guide (spruf57). Q: What are the numbers shown in the Service report messages for the DHCP?The DHCP Client returns a status message at startup. Typically the code 017 is printed at the end of a successful address assignment to NDK. A typical startup sequence is: TCP/IP Stack Example Client Using MAC Address: 08-00-28-34-10-67 Service Status: DHCPC From time to time it is common that code 019 is displayed, after the IP lease time defined by the DHCP server expires and is automatically renewed. NDK then prints the following message at the stdout window: Service Status: DHCPC These running codes are defined in the header file <dhcpif.h>: // Running Codes (State codes are all less than 0x10) #define DHCPCODE_IPADD 0x11 // Client has added an address #define DHCPCODE_IPREMOVE 0x12 // IP address removed and CFG erased #define DHCPCODE_IPRENEW 0x13 // IP renewed, DHCP config space reset Sometimes errors occur and NDK prints out the following message: TCP/IP Stack Example Client Using MAC Address: 00-0e-99-02-71-57 Service Status: DHCPC In the case above, the DHCP server is off line and does not acknowledge the IP request. Please see below the error codes defined for the DHCP client defined in <dhcp.h>: // Errors enum DhcpErrors { DHCP_NOERROR=0, DHCP_ERR_ISSET, DHCP_ERR_NAK, DHCP_ERR_OFFER, DHCP_ERR_RECV, DHCP_ERR_REQUEST, DHCP_ERR_SELECT, DHCP_ERR_SEND, DHCP_ERR_END }; Q: Why does the http server responds with the message "HTTP Error 400 - Bad request" when I try to access it using Internet Explorer? (fixed in release 1.93)This issue happens if you performed a recent upgrade to Windows Vista, or recently updated your Windows XP with Microsoft .NET 3.0 or with Internet Explorer 7.0. This issue started to happen because the .NET Frameworks 3.0 added several types of documents that the Internet Explorer browser can accept in a connection. More technically, when the browser sends an http GET command to receive a web page and its contents (like pictures, scripts, etc) it contains some fields that exceed the length of 256 chars. These fields are of type Accept: and are specified in the following registry key: If you look at this registry entry you will see several document types like application/msword, image/jpeg and others. .NET Frameworks 3.0 added other document types like application/xaml+xml that exceed the limit of the embedded web server in the NDK, causing the malfunction. The short-term workaround in this case is to reduce the number of documents in an Accept: line by deleting the new types, the definitive fix is already included in NDK 1.93 Depending on the version, there are patches for previous releases. Q: I checked the troubleshooting section in the User's Guide but NDK still cannot communicate properly. Is this a priority issue between my application and the NDK?Could be. Anytime anything is done with the NDK in an infinite (or extended) loop in an application, care is needed. The NDK is designed to operate in one of two different scheduling modes, and with two different corresponding event notification modes. The least intrusive of these is to run the network scheduler (the thread that runs the stack) at the lowest priority, and to poll for network events. As shipped, the NDK runs the scheduler at a low priority, and uses interrupts for events. However, the interrupts only set flags so that the scheduler thread knows there is work to do -- the TCP/IP stack itself will not preempt a higher priority task. Just to illustrate, if you write an application that just spins on In summary, the priority of your application tasks and NDK will influence communications and (maybe) break the stack. To check if the system is running out of resources due to the application priority, you can experiment the following workaround: There is a call near the top of the stack initialization function that looks as follows: rc = NC_SystemOpen( NC_PRIORITY_LOW, NC_OPMODE_INTERRUPT ); Try changing it to rc = NC_SystemOpen( NC_PRIORITY_HIGH, NC_OPMODE_INTERRUPT ); This way you should have communications partially or fully restored in your system. If your application breaks due to NDK scheduler preemptions, you should then start optimizing your application to meet the real-time goals. In other words, the system must guarantee a precise execution of NDK’s heartbeat. Despite the fact that PRDs operate at some of the highest priority levels in a BIOS system, their operation may be clogged by other PRDs, SWIs or even Hardware Interrupts. Also, they can be starved by asynchronous execution conflicts. This problem comes from the fact that CPU usage is actually an average amount per a given time span, but each thread uses 100% of CPU while running leaving no room for other activities. To illustrate, the picture shows a system with two threads running: one video thread that runs for 10ms every 30ms and the NDK PRD thread that runs every 100ms for, say, 20ms. The two threads will clash at roughly every 300ms. The NDK stack will not necessarily crash, but delays should definitely be expected. This can be solved by reducing the priority of the video processing task - obviously paying attention to other side effects that this may cause. Q: Does NDK support zero-copy transfers?Zero-copy receive transfers are supported in NDK through the functions For additional information, please check section 3.3.2 of NDK Q: Does the NDK only support Ethernet connections? What about the serial port of my DM642 EVM?The NDK supports the DM642 serial port through the examples provided by its NSP. Please check the directory %NDK_INSTALL_DIR%\packages\ti\ndk\example\serial that contains a Serial Client Project and a Router Project. The Serial Client Project is very similar to the Ethernet version of Client Project. The Router Project is a bridge that links between the Ethernet and the serial ports of the DM642 EVM. The serial device driver source code is provided in the NSP and is configured by default to 115200 8N1 with no handshake. In order to make it work with hardware handshake, please see question 18 below. These settings are enabled in line the function // Setup the serial port driver llSerialConfig( 1, 115200, HAL_SERIAL_MODE_8N1, HAL_SERIAL_FLOWCTRL_NONE ); Please see additional details in sections 2.4 and 2.5 of the NDK User's Guide (spru523). Q: I want to sniff the network traffic using RAW packets just like Ethereal or Wireshark. Is this possible?No. However, the RAW packet interface changed. Updated for NDK 2.00! For NDK 2.00 there is a new API as part of the Raw Ethernet Module that communicates directly to the Ethernet driver, skipping the TCP and IP protocol layers. Please see section A.17 of the NDK Programmer's Guide spru524. However its functionality is very similar to the previous RAW interface. After RAW sockets can still send and receive ICMP packets, though. For an example on how to do it please check the file <conping.c> that is part of the client example project. Its location is usually at: C:\CCStudio_v3.3\ndk_1_93\packages\ti\ndk\example\tools\common\console The main reason this was done is due to the memory and processing constraints of an embedded system. Whenever you capture raw traffic using a network sniffer, the incoming data quickly mounts to several MB. A typical load (30%) on a 100Mbps network can yield 1MB of data in just a few seconds! Q: Does the NDK have a hard limitation on the number of sockets?No, the NDK does not have a hard limit on the number of sockets. However, memory is the main constraint when designing an application. To allow deterministic behavior, sockets allocate and deallocate fixed-size buffers dynamically from the packet buffer manager (PBM). The PBM has a limited size that depends on the number of buffers configured in the file <pbm.c>. That, in turn depends on the amount of heap memory available. Therefore, if the application has a fairly large amount of sockets open and communicating at a given time, any attempts to communicate may return the error code 55 (ENOBUFS or No buffer space available). The solution is to increase the buffer manager. For additional details on how to do this please see section 5.3 of NDK User's Guide (spru523). You will have to rebuild <os.lib> using the <makelib.bat> script provided with NDK. Lastly, the error above may also appear due to scheduler starvation caused by real-time constraints. Please see question 13 above. Q: I want to use the serial port on my DM642 EVM but the hardware handshake does not seem to work. Is this a driver issue?Yes. The serial and router examples included in the NSP for DM642 EVM provide support for hardware handshake in the serial port. By default this feature is disabled, but it can be controlled via the flags However, when using the The programming sequence Set Xoff1, Xon1 to VALUE1, VALUE2 at page 32 of the TL16C752B USART datasheet shows exactly how the sequence should be performed. A footnote at page 23 of the same datasheet mentions that, in order to write to the configuration bits of the automatic hardware handshake (Xon/Xoff), the register LCR must be set to 0xBF. This was overlooked by the current implementation of the device driver source file <ti752.c> located in the folder %NDK_INSTALL_PATH%\packages\ti\ndk\src\hal\evmdm642\ser_ti752\. Therefore the changes should be: static void spInitialize( SDINFO *pi ) { uint baudsetting; uint temp; // added to enable hardware handshake functionality (...) if( pi->FlowCtrl == HAL_SERIAL_FLOWCTRL_HARDWARE ) { temp = SREG(pi,UART_LCR); // added to enable hardware handshake functionality SREG(pi, UART_LCR) = 0xBF; // added to enable hardware handshake functionality SREG(pi,UART_EFR) = TL16C752_EFR_ENHANCE | TL16C752_EFR_RTSFLOW | TL16C752_EFR_CTSFLOW; SREG(pi,UART_LCR) = temp; // added to enable hardware handshake functionality SREG(pi,UART_MCR) = TL16C752_MCR_IRQEN | TL16C752_MCR_DTR; } (...) Once modified, the device driver can be rebuilt using the script <makehal_evmdm642.bat> provided in the NDK installation. Q: Is C672x family of devices supported?For a list of all devices and boards supported by NDK please see question 5 of the NDK licensing page. But the C672x was never supported by any NDK release; therefore, any attempts to do the porting are totally up to you. Please read on for some useful advice:
Again, please keep in mind these are only suggestions to start the porting. Q: Does the NDK store network statistics that I could use?Yes, the NDK stores a full set of statistics that can be helpful to debug network traffic and other conditions. The telnet console command test shows several statistics for IP, TCP, UDP, ICMP and NAT by accessing specific global variables contained in the NDK core stack. Therefore these variables can also be used in other parts of your code, and usage examples can be found in the file <constat.c> typically located at the directory: C:\CCStudio_v3.3\ndk_1_92\packages\ti\ndk\example\tools\common\console If needed, statistics for IGMP can also be obtained by using the following internal global variables:
To use these variables you must declared in your source file as: extern UINT32 _IGMPOutResponse, _IGMPInResponse, _IGMPInQuery, _IGMPInQueryGroup, _IGMPInDiscard; Note: The internal variables above are valid up to NDK 1.94 but you should be aware they may change without notice. Q: I copied the device drivers supplied in my DM648 EVM board to NDK 1.93 or 1.94. Why am I getting build errors?If the errors you are seeing are similar to: "C:/CCStudio_v3.3/ndk_1_93/packages/ti/ndk/src/hal/evmdm648/ethss_dm648/cpsw3g_ioctl.h", line 250: error: declaration is incompatible with "uint llPacketIoctl(uint, uint, void *)" (declared at line 52 of "C:\CCStudio_v3.3\ndk_1_93\packages\ti\ndk\inc\hal/hal.h") 1 error detected in the compilation of "conSwitchCtl.c". >> Compilation failure NDK releases 1.93 and newer contain a definition for the function At <hal.h>: _extern uint llPacketIoctl( uint dev, uint cmd, void *arg); At <cpsw3g_ioctl.h>: extern void llPacketIoctl(Uint32 dev, Uint32 cmd, void *param); To fix this you can comment out the second definition above without any loss of functionality. Q: I migrated from a previous version of NDK to 1.94. Why I am getting a relocation error when I try to use the multicast APIs?If the errors you are seeing are similar to: [Linking...] "C:\CCStudio_v3.3\C6000\cgt6018\bin\cl6x" -@"Custom.lkf" <Linking> undefined first referenced symbol in file --------- ---------------- _IGMPJoinHostGroup C:\\CCStudio_v3.3\\ndk_1_94\\packages\\ti\\ndk\\example\\network\\multicast\\host\\dsk6455\\debug\\host-multicast.obj >> error: relocation overflow occurred at address 0x00000050 in >> section '.text' of input file 'C:\\CCStudio_v3.3\\ndk_1_94\\packages\\ti\\ndk\\example\\network\\multicast\\host\\dsk6455\\debug\\host-multicast.obj'. The 32-bit PC-relative displacement -2203960 at this location is too large to fit into the 21-bit PC-Relative field; the destination address is too far away from the instruction. You may need to add a mask to the assembly instruction or use other target specific assembly features if you really only need the lowest 21 bits of this symbol. Please see the section on Relocation in the Assembly User's Guide. >> error: symbol referencing errors - 'C:/CCStudio_v3.3/ndk_1_94/packages/ti/ndk/example/network/multicast/host/dsk6455/bin/host-multicast.out' not built >> Compilation failure Build Complete, 3 Errors, 0 Warnings, 0 Remarks. As stated in section 3.5 (page 68) the NDK 1.94 Programmer's Guide (SPRU524E), the APIs Please see the usage example below: char *MulticastAddr = "224.1.2.3"; // Multicast group address struct ip_mreq mc_group; // Socket configuration structure for the multicast group membership SOCKET recv = INVALID_SOCKET; // Receiver socket Note: you only need to join the multicast group on the receiving sockets. The APIs could not be maintained in NDK 1.94 since they replicated the incoming multicast packets to all sockets in the system, clogging bandwidth. Q: How to properly use the SMA connectors on my DM648EVM board?If you intend to use the SMA connectors without a PHY then you must perform the two modifications below:
use_SMA_on_port0 = TRUE; use_SMA_on_port1 = TRUE;
pi->TxOn = 0; Notes:
Q: The NDK User's Guide (SPRU523) talks about example projects inside the example directory, but I can only find C source files. Are there any ready-to-run examples supplied with NDK?The example directory supplied with NDK core stack contains only the source files common to all boards and platforms. The directory looks similar to: The complete examples tailored for each board (including a CCS pjt and the BIOS configuration file) are supplied with the NSP or PSP. Once installed, the example directory then becomes: Note: Additional details are mentioned in question 5 of the NDK Licensing and Availability page at this wiki. Q: I just started development using the NDK. Is there a document to help me?The NDK Starter Guide (spraax4) and its companion labs covers the basics of NDK and includes a step-by-step tutorial on how to develop an application using NDK. Q: I downloaded the NDK 1.94 NSP but there are missing libraries and build errors right from the start!If you are opening any of the example projects and sees a message box that mentions missing either <hal_eth_c6455.lib> or <hal_eth_dm642.lib> libraries, you must convert the project to use NIMU device driver architecture. Additional information on how to do this is provided in the device driver's documentation: please see section 1.2 of the NSP User's Guide for your platform: C6455 or DM642. See below if you want to keep using the legacy llPacket device driver architecture. Q: The NDK I am using is release 1.92 and was included in the CD that came with my board. What do I need to update it to NDK 1.94?This applies to the SDKs supplied with the development boards for DM6437, DM648, C6424 and C6452. The device drivers for NDK 1.92 provided in the SDK or DVSDK are compatible with NDK 1.94 and use the legacy llPacket device driver architecture. Therefore you can simply copy the HAL libraries from the previous version (typically located at %NDK_INSTALL_DIR%\packages\ti\ndk\lib\hal\) or download the PSP package. Please check question 6 of the NDK Licensing and Availability page for additional details on how to download and install the device drivers included in the PSP package. Q: How do I improve the security of my network application?Some of the default settings of the NDK stack do allow for easy detection of the system on the network, for example using ping commands. This is often used in TI EVM applications to detect the presence of an EVM from the host application. However in real applications it might not be desirable to have the network stack answer such messages. It may also protect the stack from security attacks using a flood of messages as it can be configured to ignore messages and not respond at all. That causes less stack process loading too.
See sections 4.4.10 and A 12.2 of the NDK 1.94 Programmer's Guide for more details. Q: I wonder if I could extract some additional performance from NDK. Are there any tips to make sure my system is performing at top notch?Despite the difficulty in answering this general question, performance improvements can frequently be obtained by doing simple things in the general configuration:
You can create a memory section for any of them and point to a specific memory region: SECTIONS { .far:NDK_PACKETMEM {} > IRAM .far:NDK_MMBUFFER {} > IRAM .far:NDK_OBJMEM {} > IRAM } For details on size requirements please see section 3.1.3 of NDK User's Guide. Q: I am using the big endian libraries of NDK 1.94 and I am having trouble in communicating with the network. This does not seem to happen with the little endian versions.Yes, this is a known issue of NDK 1.94. Please download NDK 1.94.01 from the Update Advisor page. Q: I would like to know benchmark results for my boards; where can I find them?Please check the NDK benchmarks page. Pay special attention to the note in red at that page. Q: Can a processor handle multiple PHY
|
|