lwip hangs in "release" build

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
Hello

I managed to get working UDP protocol with lwip app stack (ETH_LWIP, version 4.0.4) on Relax Kit.
But when I build it as "Release" target, it does not work. So I tried to simplify the program to isolate the problem.

Just now I have only two task blinking LED and a os timer. Nothing more.

1) In debug build:
LEDs are blinking and I can to ping the Relax kit.

2)In release build:
LEDs are blinking if the Ethernet cable is disconnected from Relax kit. When I connect the cable, Relax kit does not answer to ping.
Moreover after a while (let say 5s) program crashes - LED stop blinking.

Any idea what to try next?
0 Likes
17 Replies
lock attach
Attachments are accessible only for community members.
Not applicable
I have attached some files to help to reproduce the problem:
- exported project
- exported launch configuration
- two videos.
It is possible to see that:
"Debug" build blinks LED even after connecting Ethernet cable, but
"Release" build hangs short while after Ethernet cable is connected.
0 Likes
Travis
Employee
Employee
First solution authored Welcome! 500 replies posted
Maybe you can just set your project to debug mode which runs with a slightly larger code size that's all.
0 Likes
Not applicable
Sorry, I do not understand your suggestion. Could you write a little bit more details?
0 Likes
Not applicable
I think he is suggesting that if debug works you should use that. Considering that the suggestion comes from a Infineon employee, I hope I'm wrong!
0 Likes
Not applicable
I am afraid that using debug build is not solution. It is not suitable for production.
A little bit bigger code size is maybe not problem, but as I checked on oscilloscope,
influence on speed on some construct is really dramatic.
For example for DIGITAL_IO_Toggle Output(& Output) more than ten times.
0 Likes
Not applicable
@svobodav: Yes, that is to be expected. You might try optimization level 1, which should get rid of the worst overhead. But still does not fix the original problem.
0 Likes
Travis
Employee
Employee
First solution authored Welcome! 500 replies posted
Yeah.. I see the code stop execution at the VADC handler.

2033.attach
0 Likes
Not applicable
@Travis: Are You sure Dave didn't remove your SRAM_combined section from your linker script? My controller always hangs in that interrupt when that happens.
0 Likes
Travis
Employee
Employee
First solution authored Welcome! 500 replies posted
Hi,

I tested your software in release mode with Optimization level set to None and everything is working good now.


2034.attach
0 Likes
Not applicable
Hi
I will believe that SW will run with none optimization. But the reason to use "release" build is to USE the optimization, mainly for timing reasons.
So I do not see it as a solution.
0 Likes
Not applicable
You could give updating the XMClib to the latest version a try. They fixed quite a few bugs (QA is totally overrated), including adding some volatiles to the Ethernet-DMA code.
0 Likes
Not applicable
I upgraded the project with latest APPs including ETH_LWIP (4.0.6) .
Program behaviour does not change, not working in release target.
So I tried switch-off optimization for release target. Program worked.
I tried to switch on optimization level -O1. Still worked.
I tried to switch on optimization level -O2. Stopped working.
Then I tried switch on optimization level -O1 for project and -Os for "main.c". Worked again.
Maybe it will suffice to lower optimization only for one file - probably from lwip. Any idea which one?
0 Likes
Not applicable
I doubt it's lwip. I'm running lwip with -Os. Did you upgrade XMClib, too?
0 Likes
Not applicable
morty wrote:
I doubt it's lwip. I'm running lwip with -Os. Did you upgrade XMClib, too?


Hi.
I do not use XMClib directly.
It is not upgraded with APP that is using it?
If not how it is possible to upgrade it in old project?
Vladimír
0 Likes
Not applicable
I have no idea whether it's updated or not. IMO does too much implicit magic. You can just delete it from your libraries folder and replace it with the current version manually.
0 Likes
lock attach
Attachments are accessible only for community members.
Not applicable
It seems to work now. The problem was probably old processor revision (AA) not supported by DAVE.
It was necessary:
1) Add "ENABLE_CPU_CM_001_WORKAROUND" to both C Compiler and Assembler defines
2) add statements -Xassembler --defsym -Xassembler IFX_XMC4XXX=1 to miscellaneous Assembler settings
3) replace the file HAL_CM4.S (file is enclosed)

Please read also explanation from Mr. Ferreira Torreno:
I
t seems it is related to the old sub design version. It is related to PMU_CM.001 errata: Branch from non-cacheable to cacheable address space instruction may corrupt the program execution
A workaround is activated by ENABLE_CPU_CM_001_WORKAROUND and -Xassembler --defsym -Xassembler IFX_XMC4XXX=1 for the RTOS code.
0 Likes
Not applicable
I am having the same problem if the same code is built using eclipse plus c startup code without \Handler\()_Veneer treatment. The code can run normally, and after reset it stops somewhere in the beginning part of the firmware and then restarts from the very beginning. the procedure repeats. I am also looking at the flags.

In addition, when I look at the makefile or the settings in the IDE, i see -mcpu=cortex-m3 both in debug and release mode. is this correct? shouldn't it be cortex-m4? And I cannot change it to cortex-m4 Why ? I am using Dave-4.1.2
0 Likes