TJA1103 with Automative Ethernet Camera

[Wobaffet]

Hello,

We're trying to utilize an 100Mb/s 100BASE-T1 (BroadR-Reach) camera with TJA1103 right next to i.MX8MP on our custom board. I believe we've configured the PHY so that we can see some activity on the network however we can't provide an IP to the camera. Logs of the communication between camera and phy are attached. We're on 5.15 kernel with NXP BSP. Could you please advise? Are there any kind of application note for this purpose? What are we missing? Are there any specific configurations/protocols for an automotive case?

Here are some camera specs:

Protocols: RTP over UDP (RFC6184), ISO17215-2014, AVB (IEEE1722), VLAN. 
IP Address: DHCPv4 or static IPv4 address. 
Camera IPv4 address  (192.168.40.90) (When DHCP mode is disabled without setting the IP address) 
DHCP mode 1 
Stream destination IP 192.168.40.220 
Stream destination port 5004 
Stream ID 258 
VLAN ID 2

Thanks!

[PavelL]

Hello @Wobaffet ,

Thank you for sharing the tcpdump logs - they are very helpful. It appears that the issue is not related to the TJA1103 itself; and no special configuration/protocols are required.

The camera repeatedly sends DHCP DISCOVER frames, a DHCP server responds with DHCP OFFER. However, we do not see the DHCP handshake completing: there are no DHCP REQUEST messages from the camera and no DHCP ACK from the server. Instead, the pattern repeats as DISCOVER → OFFER → (no follow-up) → DISCOVER → OFFER.

This strongly suggests the PHY or link is not the primary blocker. The issue is that the camera is not proceeding to DHCP REQUEST, which typically happens when the client does not receive the OFFER correctly or rejects it for some reason. 

Recommendations

1) Verify DHCP server settings (especially lease time)

In both logs, the DHCP OFFER contains Lease-Time = 4294967295 (0xFFFFFFFF). Some embedded DHCP clients reject unusual lease values or specific option combinations, which can result in exactly the behavior we see (repeated DISCOVER with no REQUEST). So, try configure a “normal” lease time (e.g., 10 minutes or 1 hour) and retest. 

2) Avoid multiple DHCP servers responding

Your logs show two different DHCP server identities in different captures (server 192.168.40.220 in one case and 192.168.40.1 in another). I would expect only one DHCP server.

3) Check VLAN tagging in the overall setup

Some automotive cameras operate on a specific VLAN. If frames are VLAN-tagged but the Linux interface is not configured for that VLAN, control traffic can behave unexpectedly. The provided logs focus on DHCP only and do not show VLAN fields explicitly, so this needs verification with a VLAN-aware capture/filter. Please try:

tcpdump -eni eth0 -vvv vlan and '(udp port 67 or udp port 68)'

Best regards,

Pavel