2020-10-28 10:50 AM
I had a functioning TCP/IP application I am trialing on the SPC58EC-DISP discovery board using DHCP. SPC5Studio pulled updates and is not forcing me to migrate to the latest RLA (1.8.2.20200908161300) which breaks some network code -- this was fixed. However DHCP either does not function, or will bring the interface (ETHD0) up rarely and sporadically. This was not the case with the previous RLA (1.8.1.20200626121110). The previous driver was very reliable and repeatable.
Thinking it was some fault of mine -- I created a new Ping Test demo application and with DHCP enabled it certainly fails to bring the interface up (worked a handful of times -- takes many board resets to get it to bring the interface up). If I disable DHCP the interface comes up with a static IP immediately.
To sanity check myself further -- I flashed the board with the older Ping Test demo (based on 1.8.1 rla) with DHCP turned on. It gets the IP addres and brings the interface up every time.
Watching DHCP traffic shows that the 1.8.2 RLA driver is sending the DHCP request, is getting the response, but seems to be stuck in a loop requesting the DHCP over and over (DHCP server acknowledges the device).
At this point I've come to a grinding hault due to the forced migration. I either have to figure out how to revert to RLA 1.8.1 (which SPC5 studio doesn't seem to let me chose?) or write my own FreeRTOS TCP/IP & net driver replacement using the 1.8.1 rla as a base -- which is tedious and would be nice to be avoided.
Thanks for any help.
2020-11-02 05:58 AM
You are welcome and sorry for this issue, we will reproduce your scenario and provide you the way to proceed.
Regards
2020-11-05 02:55 AM
Dear User,
testing on same your hardware, I confirm that DHCP is working on my side.
I also changed the MAC address, from SPC5Studio graphical interface, and my Linux DHCP server assigns new IP address as expected.
Tool is updated with these latest components:
SPC5-RLA_Network_Support_Feature 1.8.2.20200908161301 com.st.spc5.components.spc5rla.network.feature.feature.group
SPC5-RLA_FreeRTOS_TCPIP_Support_Feature 1.10.0.20200908161303 com.st.spc5.components.spc5rla.freertos-tcpip.feature.feature.group
I have just two points:
1) please check the version because I expect: 1.8.2.20200908161301 instead of 1.8.2.20200908161300
You can check the component from "Help" -> "Installation Details "
2) you could change the MAC address and see if your server assigns a new IP address. Maybe there is something related to your DHCP server.
Best Regards.
2020-11-13 03:14 PM
Hi GCAVA,
My DHCP server is fine as the screenshot I had posted from WireShark showed the DHCP responses from the server to the device.
That version of the RLA Network Support Feature appears to have fixed the issue -- I have working DHCP as expected with it. Only minor exception is on the first run after a ROM update by the debugger the DHCP doesn't come back with an IP -- I have to issue another reset and then it's fine. Odd, as this was never the case with the older RLA.
Thank you for looking at this!
2020-11-15 03:31 AM
Hello, happy to hear that the latest version fixed the issue.
Actually it strange the behavior you mention. I will try to do other tests but never seen on my side. If you have some wireshark pictures when it fails, this could help.
Best Regards
2020-11-22 06:02 PM
Hi GCAVA,
I'll run some more tests and grab some Wireshark captures.
On another note: the previous RLA of the TCPIP module would fail over to the assigned static IP address if it did not get a DHCP response. Is this still a function in the latest RLA?
Thanks