Lessons learned from transplanting LwIP on C6414

Aguilera

Lessons learned from transplanting LwIP on C6414 [Copy link]

Several C6414 chips are used on the Xinyan NXX board, two of which use the EMIFB interface to connect to the DM9000 chip to expand the network port, and the upper layer uses the LwIP protocol stack. Therefore, it is necessary to port the LwIP protocol stack and the DM9000 driver. I have the code verified by my boss, but it is developed in the CCS3.3 environment.

The development environment used is still CCS5.4. The main tasks that need to be done are:
1. Create a basic project and copy the entire Lwip source code to the project directory, and then delete some unnecessary files, including IPV6 and SLIP.
2. Add include and include/ipv4 in the Lwip directory to the project include path.
3. Modify the name of the project name related to cfg.h included in cc.h and main.c.
4. Since the bool type definition of general.h has been changed, true and false are changed to TRUE and FALSE
. 5. The DM9000 on the NPU is connected to CMD through A15, not the original A2. Corresponding modifications are made in the code.
6. The INT of the DM9000 on the NPU is connected to GP7, not the original GP5. Corresponding modifications are made in the code.

After making these changes, the code was compiled and tested. Many problems were encountered during the testing process.

First, read VID and PID, and the read values were all 1. No problems were found after analyzing the code, so an oscilloscope was used. Measured CMD, CS, IOR and other signals, and found that CS and IOR were normal, but CMD had no signal. Looked for CMD-related codes in the code, and finally found that CMD was triggered by an address, and the address value was calculated incorrectly. After correction, PID and VID were read normally.

Then I plugged in the network cable and used the underlying driver to send a self-assembled ARP packet. I used WireShark on the PC directly connected to it to capture the packet, but it failed. I found that the light on the network port was not on, indicating that there was a problem with the underlying hardware negotiation. I read the manual carefully and found that the DM9000 chip used on this board was upgraded to DM9000C, and the registers were different from the original DM9000. For example, bit7 of the ISR register is the IO mode bit, which is bit6 in the code. I made some modifications according to the document. At the same time, I searched the Linux driver on the Internet and made modifications according to the initialization process. Finally, the initialization was completed and the light was on.

After sending and receiving ARP packets again, it was found that the data received by DM9000 was missing one byte, while the data captured by Wireshark was normal. Therefore, the problem lies in the process from DM9000 to CPU. DM9000 has an EECS input pin. When it is pulled high, the internal memory width is 8 bits, and when it is pulled low, it is 16 bits. It is suspected that this setting is abnormal. After soldering it low on the board, flying wires pulled it high and tested it, it was found that the initialization was wrong, and the read ID became all 1.

At this time, the suspicion focused on the inconsistency of the registers of the new and old chips. After spending a long time comparing and trying to configure the registers one by one, the problem was still not solved.

Finally, I thought, is there something wrong with the EMIF configuration? I checked the manual and found that the default is 8bit, but there is no configuration for EMIF in the old version of the code. I asked the original developer and learned that the old version of CCS3.3 will automatically generate configuration code in a certain folder. I copied this code and added it to the startup process, and the data sent and received were correct.

Then I started the PING test, and the directly connected machine could ping the board, but after a while the DSP reset for unknown reasons.

After removing the LwIP module, no reset phenomenon was found during long-term operation, so the problem was initially located in LwIP. After turning on the debugging print of LwIP, no obvious signs were found. After removing the receive interrupt and receive processing function alone, the system no longer restarted; after removing the send function and send interrupt alone, the system still restarted. Therefore, the problem was located in the receive direction.

Focus on several functions in the receiving direction. A semaphore is thrown in the receiving interrupt. After a process ethernetif_input waits for the semaphore, it calls low_level_input to receive a frame of data and hands it over to the upper layer for processing. After the processing is completed, if there is new data, it will be received and processed again. If not, it will be suspended and continue to wait for the interrupt.
Many modifications, deletions and debugging were made here, such as only performing semaphore operations and not actually reading data, but to no avail. Finally, when sorting out the initialization process of LwIP, it was found that only a 256-byte stack was allocated when the process was created, which was obviously too small. It was increased to 1024 bytes and ran for a long time again, and there was no problem.

I have encountered some problems caused by a small stack size before. In some cases when there is an operating system, the debugging module of SYS/BIOS will clearly print out information such as stack overflow. Another time, when I was helping others debug an algorithm, the stack was too small, causing the system to crash every time it returned from a certain function. These phenomena are relatively clear and easy to locate. But like this time, the problem occurred silently, and then suddenly appeared at an inexplicable time. This phenomenon is the most troublesome. I can only be very careful when coding to avoid digging holes for myself and future generations.