2022-06-18 07:58 AM
I am trying to do UDP on Discovery STM32H735G-DK.
1) MX Pinout configuration tool seems not compatible with the examples: if I open the example LwIP_UDP_Echo_Server in the configurator, LwIP remains disabled in the MX pin configurator.
Q1: Is there any way to create/update the .IOC from the example so it can be used as a base to start working from using the MX tool?
2) If I generate with MX a basic configuration, even disabling all hardware peripherals, the tool keeps nagging “partly disable conflict with�? even with peripheral ADC I disabled.
Q2: How should I understand conflicts between 2 hardware parts where 1 is disabled? For the moment it seems a contradiction to me.
3) If I try to correct beforementioned conflicts, I the tool is unwilling to let me change configuration: (Eth CHR, red, cannot be selected for PA0_C, so how to correct the alleged conflict? (right click on BGA pin PAO_C => ETH_CRS unselectable, remains red! even with other peripherials disabled.)
Q3: How can I change PA0_C so it is connected with ETH_CRS to solve (if needed) the before mentioned conflict.
If one enables lwIP and RTOS together, code generated does not compile:
multiple definition of `errno'
./Middlewares/Third_Party/LwIP/system/OS/sys_arch.o:
c:\st\stm32cubeide_1.8.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: c:/st/stm32cubeide_1.8.0/stm32cubeide/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127/tools/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libc_nano.a(lib_a-reent.o):(.bss.errno+0x0): multiple definition of `errno'; ./Middlewares/Third_Party/LwIP/system/OS/sys_arch.o:C:/Users/Johi/STM32CubeIDE/workspace_H735-G-DK-2/test-naked/Debug/../Middlewares/Third_Party/LwIP/system/OS/sys_arch.c:45: first defined here
ð Solved this by commenting out #define LWIP_PROVIDE_ERRNO in cc.h (but I think if I regenerate with MX this will be overwritten), so is this the right way to go.
ð If I recompile, again a myriad of errors:
../Middlewares/Third_Party/LwIP/src/api/err.c:50:3: error: 'ENOMEM' undeclared here (not in a function)
../Middlewares/Third_Party/LwIP/src/api/err.c:51:3: error: 'ENOBUFS' undeclared here (not in a function)
../Middlewares/Third_Party/LwIP/src/api/err.c:52:3: error: 'EWOULDBLOCK' undeclared here (not in a function); did you mean 'ERR_WOULDBLOCK'?
../Middlewares/Third_Party/LwIP/src/api/err.c:53:3: error: 'EHOSTUNREACH' undeclared here (not in a function)
../Middlewares/Third_Party/LwIP/src/api/err.c:54:3: error: 'EINPROGRESS' undeclared here (not in a function); did you mean 'ERR_INPROGRESS'?
../Middlewares/Third_Party/LwIP/src/api/err.c:55:3: error: 'EINVAL' undeclared here (not in a function)
../Middlewares/Third_Party/LwIP/src/api/err.c:57:3: error: 'EADDRINUSE' undeclared here (not in a function)
../Middlewares/Third_Party/LwIP/src/api/err.c:58:3: error: 'EALREADY' undeclared here (not in a function); did you mean 'ERR_ALREADY'?
../Middlewares/Third_Party/LwIP/src/api/err.c:59:3: error: 'EISCONN' undeclared here (not in a function)
../Middlewares/Third_Party/LwIP/src/api/err.c:60:3: error: 'ENOTCONN' undeclared here (not in a function)
../Middlewares/Third_Party/LwIP/src/api/err.c:62:3: error: 'ECONNABORTED' undeclared here (not in a function)
../Middlewares/Third_Party/LwIP/src/api/err.c:63:3: error: 'ECONNRESET' undeclared here (not in a function)
../Middlewares/Third_Party/LwIP/src/api/err.c:65:3: error: 'EIO' undeclared here (not in a function)
make: *** [Middlewares/Third_Party/LwIP/src/api/subdir.mk:43: Middlewares/Third_Party/LwIP/src/api/err.o] Error 1
make: *** Waiting for unfinished jobs....
../Middlewares/Third_Party/LwIP/src/api/if_api.c:74:13: error: 'ENXIO' undeclared (first use in this function)
../Middlewares/Third_Party/LwIP/src/include/lwip/priv/sockets_priv.h:95:40: error: 'errno' undeclared (first use in this function)
Q3: Since LwIP (as per documentation) is compatible with RTOS, it should be possible to get rid of these errors. However if I do manually and reconfigure I am afraid my code will be overwritten.
Q4: I am quite positively impressed Using Cube-MX for my Nucleo boards, but experiences mentioned above give me the feeling that once things really get serous MX is maybe not the right approach? Is my feeling correct and if so are there other tools (possibly not free) that are more apropriate?
Or should I use the eclipse part and forget about MX with all its true advantages certainly for those that are not very experienced as I am? (Maybe generate the framework once and correct the bugs and take it manually from ther.)
2022-06-18 07:20 PM
SMT32H735 is a relatively new chip and its support by CubeMX is not quite mature.
The best you can do is start from one of LwIP examples here . They build without errors.
Then create a CubeMX (or IDE) project with all other components.
Carefully merge the results.
This can be hard for a beginner, but this is the way.
2022-06-19 03:45 AM
Thank you for the answer, the LwIP examples, I was able to compile and run without issues even before I explored the MX path that led to my post.
I found an interesting article: https://st.force.com/community/s/article/How-to-create-project-for-STM32H7-with-Ethernet-and-LwIP-stack-working that covers the topic for CubeMx be it for a H750.
Now in order to properly debug I started with a clean config with MX, but first wanted to setup SWD on the H735. Did the same as with my H7A3 Nucleo that works for months, but the H735 refuses to trace. Any idea ideas or is it again the topic related to compatibility? Are there any ways to debug SWD if not working as expected? Breakpoints debugging works properly.
- MX DEBUG settings: Trace Asynchronous Sw.
- ITM_SendChar(ch) is called via _io_putchar(int) properly (verified via breakpoint)
- SWV ITM Data Console : enable port 0 + trace started (red ball button).
- GDB SWD activated, Core clock 192MHZ (=SYSCLCK) and max SWO clock set at 2000.
- MX-Debug pins config: PB3 JTDO/TRACESWO / PA14 JTCK/SWCLK / PA13 JTMS/SWDIO
- No MX conflicts on Debug pins, but RCC partly disabled conflict with Trace Asynchronous software SW? (the H7A3 config gives the same message)
2022-06-19 06:05 AM
Hi,
H750 is similar to H753/743 which is older, more stable part, (almost*) well supported by the Cube.
I don't have H735, IIRC these newer H7 have a subtle difference in ITM (half or double clock?). Latest CubeIDE debugger should already handle it.
But the latest CubeIDE v.1.9.0 debugger has other issues that could break it.
Try roll back to v. 1.8
2022-06-19 07:39 AM
Hi Pavel A.
Thanks for the tip, I found a document https://www.st.com/content/ccc/resource/training/technical/product_training/group0/8a/bf/62/da/24/f0/49/7b/STM32H7-System-Debug_DBG/files/STM32H7-System-Debug_DBG.pdf/_jcr_content/translations/en.STM32H7-System-Debug_DBG.pdf where debugging STM32H7 is presented. There I saw (see below) AHB-AP used to link the Jtag/Serial wire port. So based on your info I used 96 and not the 192. And it worked. I do not know if my analysis is correct but with 96 SWD works so thanks a lot!
2022-07-02 02:50 AM
In line with your advice: this is the way.
I loaded the Lw_IP_HTTP_server and am trying to expand it.
- added C++ capabilities (menu option new ... )
- added Wawi.cpp file
- Wawi.cpp includes WawiGeneral.h
- WawiGeneral.h includes stm32f7xx_hal.h
=> ../Application/User/WawiGeneral.h:11:10: fatal error: stm32f7xx_hal.h: No such file or directory
Paths and symbols should be ok? (IMHO)
+ apply & close.
That is a copy from the C settings:
File exist in the forementioned directory:
I also tried to add the absolute path:
=> Same problem.
What am I not seeing here?