STM32F4 Cube lwip Examples

[phil239955_stm1_stmicro]

Posted on September 01, 2014 at 05:29

So, I've just downloaded and started playing with STM32F4 Cube's *version 1.3.0) Ethernet examples on my STM3240G-Eval.

The LwIP_HTTP_Server_Raw works, but not a single one of the others does. Some debugging shows it bombs out in the RTOS setup. I honestly can't be bothered to debug what my company would basically use as framework code. Can ST really be serious? Clearly growing business is not important. On to Freescale then. What a shame. The ST MCUs are by far the best product range, but without decent firmware support they are useless. #stm32f4-cube

[yaghiyah]

Posted on September 01, 2014 at 10:11

I have the same issue, If you look at my previous post it seems that the cube framework is still a beta, and it seems the company hasn't allocated enough resources for doing QA testing, its really unfortunate like you I am also working for a company and I was suppose to present STM and I shot myself in the foot, im thinking of evaluating NXP range of cortex chips.

I hope somebody with some experience can help or explain whats going on this cube framework cause it doesn't look very reliable or resilient to me.

[Raouf Hosni]

Posted on September 01, 2014 at 11:54

Hello phillip, reactance,

Just let me confirm that ST is engaged in the complete validation of the STM32Cube solution and the development team is well resourced for this.

All the applications provided with STM32Cube are fully validated on the supported boards and toolchains; that’s mean for STM32CubeF4, the LwIP applications are tested on STM324xG_EVAL and STM324x9I_EVAL boards, and for each board the test is done with the following toolchains EWARM (IAR), MDK-ARM (Keil) and TrueSTUDIO (Atollic). This is done by a different person than the developer of the applications.

The limitations that can’t be fixed on time for the release, are added in the release notes. And for LwIP we already reported some limitations for 2 applications w/ EWARM v7.10.

• LwIP applications for STM324x9I_EVAL and STM324xG_EVAL

• LwIP_IAP and LwIP_TFTP_Server doesn’t work correctly with EWARM v7.10, the provided projects works only with EWARM v6.7

Now coming back to your problem, we are suspecting something wrong in your setup. Could

you describe what is the issues you are seeing (what is the issue, at each level of the application it occurs, it’s systematic…) and provide us more details about your setup:

• What is the LwIP application used

• The problem is seen with LwIP application as provided in STM32CubeF4 FW V1.3.0, or did you changed anything else?

• STM3240G_EVAL board version, and revision of the onboard STM32F407 MCU

• Your development toolchain and its version

• How do you connect the board to the network

Best regards.

[phil239955_stm1_stmicro]

Posted on September 01, 2014 at 13:50

I was using a stock STM3240G-EVAL board. The debugger was the built-in ST-Link.

The software was built with MDK ARM 4.54 I worked through all of the examples in the STM32F4 Cube directory under STM32Cube_FW_F4_V1.3.0\Projects\STM324xG_EVAL\Applications\LwIP The board is connected via a switch to a DCHP controlled network (the DHCP server is Windows Server 2012). This is our dev network, and it is stable and solid. The only one of the HHTP demos in that directory that works is the LwIP_HTTP_Server_Raw demo. LwIP_HTTP_Server_Netconn_RTOS and LwIP_HTTP_Server_Socket_RTOS both bomb out in the osThreadCreate call in main (they immediately hard fault and drop to the hard fault handler). Ditto for the other RTOS based examples in that directory. The apps were simply opened in MDK-ARM and built. To debug them, they were rebuilt with optimisation level 0 to avoid any trace weirdness from that. Once I realised that the hard faulting was deep in the RTOS I gave up. I don't have the time to debug any of that. Our consumption of devices is small (about 2,000/year) so we need a solid base code set, we just don't have the resources (or experience) to debug that deep.

[Raouf Hosni]

Posted on September 01, 2014 at 17:40

You are probably using old version of STM3240G-EVAL board having STM32F407 RevA, this revision of the device doesn’t work when the prefetch is ON.

Could you try to disable the prefetch; in

stm32f4xx_hal_conf.h

file, set

PREFETCH_ENABLE

value to

0

(line 150).

In addition, you are using quite old version of MDK-ARM V4.53 while the STM32CubeF4 is tested with V5.10, we recommend that you switch to the new version to avoid any issue.

Keep us informed about your finding.

Regards.

[phil239955_stm1_stmicro]

Posted on September 02, 2014 at 05:57

Thanks - yes, that fixed the issue for both MDK-ARM 4.54 and 5.10 (I'd been using 4.54 in case the new MDK-ARM was the issue).

I owe you an apology. Thank you for the quick and accurate support. Interesting that I got an old STM3240G when I only bought it a week ago! Mouser must be sitting on old stock. Now, to try to port the project over to VisualGDB (our preferred development environment ... nothing beats the Visual Studio IDE), then turn it into a development framework. Again, thanks - Phil

[Raouf Hosni]

Posted on September 02, 2014 at 11:40

You are welcome

Enjoy using STM32 with the STM32Cube solution !!! With regards.