2017-03-14 06:47 PM
I have just started experimenting with ST products. I have a STM32F4 Discovery board. I bought a DP83848 PHY on Ebay and connected it to the Discovery board. I downloaded a hex file from here:[
]
I am able to ping the board and access the web page with no issues.
I then used CubeMX to create a project with nothing but LWIP and two GPIO pins. I figured I would start out simple. The goal was to see if I could get LWIP working. I generated the code and imported it into System Workbench and used STLink to program the board.
I cannot ping the board (I enabled ICMP in CubeMX) and it does not make a DHCP request. I know the request is not being made because Wireshark never sees it.
Do I have to put anything in the main() while loop for lwip to work? Do I need to make any modifications to use the DP83848? I noticed in CubeMX that in the Ethernet Settings, it states LAN8742A for the PHY. Maybe this is my issue? If so, what modifications need to be made to tell CubeMX to use the DP83848?
I have been working on this for two days and making zero progress.
2017-03-15 03:20 AM
Hello,
Welcome to our Community.
You'll probably want to review LwIP examples as you can find in the STM32CubeF4 package:STM32Cube_FW_F4_V1.15.0\Projects\STM324x9I_EVAL\Applications\LwIPLooking to the available examples and these documents can help you a lot to go further in your application:
-
for the STM32CubeMX use in the LwIP section.- STM32Cube Ethernet IAP example: it maybe helpful as it provides a full description of how to implement In-Application Programming (IAP) using Ethernet communication.- ' LwIP TCP/IP stack demonstration for STM32F4x7 microcontrollers� .-
“Developing applications on STM32Cube with LwIP TCP/IP stack'.Hope this helps you.
Imen
2017-03-15 10:55 AM
Thanks Imen. I have already read UM1718 and UM1709. I just skimmed through UM1709 as I had no need for IAP. I will review the other two and see if they can help me.
Ray
2017-03-15 03:07 PM
I have made some progress, but not much. I changed the ♯ define IS_ETH_PHY_ADDRESS(ADDRESS) in stm32f4xx_hal_eth.h from 0x20U to 0x01U to match the DP83848. Now when I start the board Wireshark sees this:
256 130.602404 0.0.0.0 255.255.255.255 DHCP 350 DHCP Discover - Transaction ID 0x5851f42d
257 130.604782 44:8a:5b:d3:4c:8b Broadcast ARP 60 Who has 172.16.1.107? Tell 172.16.1.1258 130.604782 44:8a:5b:d3:4c:8b Broadcast ARP 60 Who has 172.16.1.107? Tell 172.16.1.1172.16.1.107 was cached in the DHCP lease tables. My guess it that in some of my testing, the DHCP server did manage to see the board and assign it an IP address. The MAC address in the DHCP table is 00:80:e1:00:00:00 which is what CubeMX assigned to the board.
If I remove the 172.16.1.107 entry from the DHCP table and plug the board in, Wireshark only sees this:
347 0.000000 0.0.0.0 255.255.255.255 DHCP 350 DHCP Discover - Transaction ID 0x5851f42d
So apparently the board isn't making a DHCP request, but the server(172.16.1.1) is able to see the MAC address???
I don't know what else needs to be changed to let the stack know I am using a DP83848 instead of a LAN8742A PHY device. Can anyone tell me what else should be changed?
2017-03-17 05:01 PM
Imen,
I finally got my code running on the Discovery board. I can obtain an IP address via DHCP or set a static IP address. I am able to ping the board and it replies back.
However, I have a question. How often should I call tje MX_LWIP_Process()? If I call it in the while(1) main loop, it severely hangs the processing of the while loop. I have two LEDs that toggle every 500 msec. If MX_LWIP_Process() is in the while(1) main loop, those LEDs only blink every 4 seconds.
If I put MX_LWIP_Process() in a small delay routine inside of the while(1) main loop and call it every few milliseconds, the LEDs blink at their normal rate. I don't actually know how long the delay is, as apparently there is no way in System Workbench to time code execution. I just set a counter that counts down from 16384 to zero. The counter is decremented once each time through the while(1) main loop. If I knew how often to call the MX_LWIP_Process(), I could setup a timer to call it. Or maybe it would be better to use the SysTick timer to call it?
My next challenge will be to get a web server running and figure out how the callback functions work.
Ray
2017-03-17 06:05 PM
In your HAL_Delay interrupt, create a global variable which countdown to zero and set a flag when reaching zero. In your main loop, clear the flag and set the delay, then infinite loop on your lwip polling until the flag is set. This ensure short latency. Same bare metal scheme for button debouncing and autorepeat when pressed continuously...
2017-03-17 09:02 PM
KIC8462852 EPIC204278916 wrote:
In your main loop, clear the flag and set the delay, then infinite loop on your lwip polling until the flag is set.What value should I set delay to? If I understand correctly, HAL_Delay creates a 1ms delay? So if I set the delay to 5ms, I think that would mean it would take 5ms to respond to a ping request? Or I am not understanding what you are saying?
2017-03-18 12:27 AM
If you need to blink every second, set the downcounter to 1000.
The most effective use of an MCU is when it is used in such a way that SW delays are as inexistant as possible. In the main loop, polling on the lwip routine always unless the 1 second is downcounted by the hal delay background interrupt. Let me know if few lines of pseudo code are needed.
2017-03-18 12:56 AM
Something like this:
uint16_t Activity_Tick = 0xFFFF;
void SysTick_Handler(void)
{ HAL_IncTick();// static uint32_t ticks;
if(Activity_Tick ! = 0xFFFF) Activity_Tick--;}
//======== 8>< -----------------------
in main.c:
main() {
Init()
while(1) {
Activity_tick = 500;
while(Activity_tick !=0xFFFF) {
MX_LWIP_Process();
// any polling unrelated to a time tick
}
// reaching here every 500 msec
ToggleMyLED();
}
2017-03-18 02:06 PM
OK, that works. My ping time is 1ms avg and the LEDs toggle at 500 msec rate. I wondered what was the best way to call MX_LWIP_Process() and this is it.
Now on to trying to bring up a web server!