The latest MDR and RTX updates seem to not receive UDP or TCP packets correctly (or at least consistently - I can get it to trigger once). The transmit functions work well, but the callback functions do not always get triggered. I have set break points on the functions and they do not trigger when I send UDP or TCP packets to the device. I have a PCB loaded with the old version of the firmware and it works consistently. However, that same code re-compiled with the latest updates does not work (for TCP/UDP reception - transmission works fine).
I have also since tried the using the example programs for the MCB2300 development PCB to see that if I re-compiled the source, if these functions worked - just to confirm that there is a problem - and they also fail or timeout.
I am using the RTX lib for use of the TCP/IP stack (and a 100ms base timer) but not the RTX kernel.
Any advice?
In playing with the firmware, it seems to be related to the hardware MAC address. I still need to do more testing, but if I change the MAC to something unique on the network... the receive callbacks of the TCP/IP RTX stack trigger. For some reason, this problem only became apparent with the update.
How does the MAC address affect the TCP/IP stack with DHCP disabled?
The MAC address MUST be unique on the network - And SHOULD be unique.
There is nothing specific about MAC addresses and DHCP. They are two totally separate things.
TCP/IP behaviour is defined based on the assumption that the local network has unique MAC addresses on all connected devices.
If there is a MAC collision, then timing can intefere greatly. The switches caches information about which ports that can access the different MAC addresses, and if the switch cache points to your device, you will get your data together with the data that was intended for the other device with the same MAC address. If the switch cache points at the other device, you will not see any data.
You really have to make sure that all IP are unique and all MAC are unique.
Might be worth you reading up on what the MAC address is there for.
Try:
en.wikipedia.org/.../MAC_address
Excellent!! Thanks!!