Hi,
I'm working on a project using an LPC2388 with RTX and using the TCPnet stack for communication with a windows tablet. I recently added a bootloader which resulted in the main application being shifted in FLASH to 0x2000.
Currently I'm seeing a Prefect Abort error about 4 seconds after the program starts. R14 points to address 0x642D625C which I seems wrong since it's in reserved address space. I know it has something to with shifting the main application in memory, because I don't see an error when shifting it back to 0x0.
The error only happens before I establish a TCP connection and the really strange thing is that it only happens with certain machines. I run the device on one machine and it will crash but I connect to another computer with the same device and firmware and it runs fine. Only thing I can think that is different is the ethernet traffic over the link. could it be that TCPnet can't handle certain packets? Does TCPnet need to have a different configuration when shifted in memory? Does the PHY driver need to be shifted in memory too?
Very strange error...
So I moved my main application back to 0x0 in memory and ran it again while looking at the packet traffic (using debug version of TCPnet). It seems there are some pretty large packets (1160 bytes) being sent by the host computer over the connection to the ARM. Comparing it to the packet traffic when it crashes (when placed at 0x2000) it seems like the packets it handles before crashing are all smaller that 100 bytes. I'm wondering if this is connected somehow.
Just loaded up a working system and monitored the packets. Didn't see any packets over 200 bytes. Tried to ping it with a packet size of 1160 bytes (what I was seeing from the non-working setup) and it crashed too! One think to mention is that the ARM boards are being connected to a windows 8 system by ethernet through a ethernet-to-USB converter. Fo now though I'm going to try to disable IPv6 and see if I still see the problem.
So I'm still seeing the problem after disabling IPV6 since there are some pretty large IP packets coming over the connection as well (1126 bytes). Not sure what I can do at this point. Already submitted a support request directly to Keil since on the surface this seems like a bug within TCPnet.