Not applicable
Apr 06, 2016
08:00 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 06, 2016
08:00 AM
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?
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?
- Tags:
- IFX
17 Replies
Attachments are accessible only for community members.
Not applicable
Apr 12, 2016
12:51 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 12, 2016
12:51 AM
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.
- 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.
Apr 17, 2016
11:57 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 17, 2016
11:57 PM
Maybe you can just set your project to debug mode which runs with a slightly larger code size that's all.
Not applicable
Apr 18, 2016
05:50 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 18, 2016
05:50 AM
Sorry, I do not understand your suggestion. Could you write a little bit more details?
Not applicable
Apr 18, 2016
08:04 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 18, 2016
08:04 AM
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!
Not applicable
Apr 18, 2016
11:16 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 18, 2016
11:16 PM
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.
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.
Not applicable
Apr 18, 2016
11:20 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 18, 2016
11:20 PM
@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.
Apr 18, 2016
11:21 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 18, 2016
11:21 PM
Yeah.. I see the code stop execution at the VADC handler.
Not applicable
Apr 18, 2016
11:26 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 18, 2016
11:26 PM
@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.
Apr 18, 2016
11:48 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 18, 2016
11:48 PM
Hi,
I tested your software in release mode with Optimization level set to None and everything is working good now.
I tested your software in release mode with Optimization level set to None and everything is working good now.
Not applicable
Apr 20, 2016
02:46 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 20, 2016
02:46 AM
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.
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.
Not applicable
Apr 26, 2016
02:27 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 26, 2016
02:27 AM
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.
Not applicable
May 19, 2016
06:00 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 19, 2016
06:00 AM
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?
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?
Not applicable
May 19, 2016
06:03 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 19, 2016
06:03 AM
I doubt it's lwip. I'm running lwip with -Os. Did you upgrade XMClib, too?
Not applicable
May 19, 2016
07:23 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 19, 2016
07:23 AM
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
Not applicable
May 19, 2016
07:26 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 19, 2016
07:26 AM
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.
Attachments are accessible only for community members.
Not applicable
May 25, 2016
05:42 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May 25, 2016
05:42 AM
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
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.
Not applicable
Jun 02, 2016
02:22 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 02, 2016
02:22 PM
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
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