codeSourcery and SP5 code

[johnr]

 We've been working the last few days trying to get uTasker running on our
M52233DEMO pcb. Here's the results so far:

 Using codeSourcery 4.2.23 IDE to compile and debug

1) I had to modify the m52335evb-rom.ld file to include the _init and _fini lables
in order to compile without errors. When I ran it in the debugger it would
run for about 30 secs then stop the the following debug console message:

   Sourcery G++ Debug Sprite for ColdFire ELF (8/29/07 2:40 PM) (Suspended)   
      Thread

• (Suspended: Signal 'SIGTRAP' received. Description: SIGTRAP.) <Stack is not available: Target is not responding (timed out).>   

   

 I modified the source code to disable the WATCHDOG and added the RTC interuppt
vector. I modified the makefile to use -O2 and -mcpu=52233. It still would not run.

I tried a uTaskerV1.3.elf file that was compiled with codeSourcery 4.1.32 and
I was able to run it where it hit a breakpoint in main(). I talked to codeSourcery and
they told me to download the 4.1.23 package and try it. I did this and compiled
the code with with following warnings :

..\..\..\Hardware\M5223X\M5223X.c: In function '_SCI1_Interrupt':
..\..\..\Hardware\M5223X\M5223X.c:1359: warning: unused variable 'ucDummy'
..\..\..\Hardware\M5223X\M5223X.c: At top level:
..\..\..\Hardware\M5223X\M5223X.c:354: warning: '_sw_wdog_timeout' defined but n
ot used
..\..\..\stack\http.c: In function 'fnHTTPListener':
..\..\..\stack\http.c:560: warning: 'ucPush' may be used uninitialized in this f
unction
..\..\..\stack\http.c:559: warning: 'Len' may be used uninitialized in this func
tion
c:/program files/codesourcery4.1.32/sourcery g++/bin/../lib/gcc/m68k-elf/4.1.1/.
./../../../m68k-elf/bin/ld.exe: warning: cannot find entry symbol _start; defaul
ting to 00000000

 I didn't get that last warnnig compiling under 4.2.23. When I tried debugging this elf
with the 4.2.23 IDE it would stop immediately with the following debug console message:

Sourcery G++ Debug Sprite for ColdFire ELF (8/29/07 2:50 PM) (Suspended)   
   Thread

• (Suspended: Signal 'SIGTRAP' received. Description: Trace/breakpoint trap.)   

      1 <symbol is not available> 0x1fffffff   


 I'm stuck at this point.

 John


    
   
 

[johnr]

 I compared the map files produced by the 4.1.32 and 4.2.23 codeSourcery
packages searching for _start references and nothing looked obviously wrong, but
then I'm no expert here

[johnr]

 I tried using the m52235evb-rom.ld from SP4 instead of the updated version for CS > 4.1.32 when I compiled with CS 4.1.32. The only difference is the updated version has a _region_array label at the end of the rom section. I still get the _start label warning regardless of which version I use. I never got the  _region_array error, even using the SP4 .ld file.

 John

[mark]

Hi John

I am sorry that you are still having difficulties. I have taken the V1.3 project + SP5 and performed a standalone build with the CS compiler. Please do exactly the same and maybe you see a deviation somewhere. I have tested on the DEMO board which you are also using and have not modified any files from the delivered state (apart from the RTC correction as detailed below and in the SP5 thread).

Good luck - there must be a reason if your results are not the same and this may help identify it...



I have described a practical method of building the project for GNU from VisualStudio (which is used with the simulator). Most modern editors offer a similar method of launching a bat file and of course the same result can be obtained under DOS or by simply double clicking on Build_M5223X.bat.

1. In VS add a new configuration build (eg. name it 'simulation and GNU Coldfire build')
2. Select the new configuration as active one
3. In configuration settings add a post processing step (this will be executed after a successful VS C++ build) as follows:
cd ..\GNU_ColdFire
Build_M5223X.bat

4. Rebuild the project in VS - note that the post build step will not be executed if the VS project is already up to date, but can of course be forced by rebuilding all.
If the Build directory is empty, a full build will look like this:

Code: [Select]

m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\application.c -o Build\application.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\debug.c -o Build\debug.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\webInterface.c -o Build\webInterface.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\KeyScan.c -o Build\KeyScan.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\LCD.c -o Build\LCD.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\NetworkIndicator.c -o Build\NetworkIndicator.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes  -D _GNU -D _M5223X -g -c -Os ..\..\..\Hardware\M5223X\Startup_gnu.s -o Build\Startup_gnu.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\Hardware\M5223X\M5223X.c -o Build\M5223X.o
..\..\..\Hardware\M5223X\M5223X.c: In function '_SCI1_Interrupt':
..\..\..\Hardware\M5223X\M5223X.c:1353: warning: unused variable 'ucDummy'
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\uTasker\eth_drv.c -o Build\eth_drv.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\uTasker\iic_drv.c -o Build\iic_drv.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\uTasker\Driver.c -o Build\Driver.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\uTasker\uMalloc.c -o Build\uMalloc.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\uTasker\uTasker.c -o Build\uTasker.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\uTasker\Tty_drv.c -o Build\Tty_drv.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\uTasker\uFile.c -o Build\uFile.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\uTasker\watchdog.c -o Build\watchdog.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\uTasker\GlobalTimer.c -o Build\GlobalTimer.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\uTasker\low_power.c -o Build\low_power.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\Ethernet.c -o Build\Ethernet.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\arp.c -o Build\arp.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\dhcp.c -o Build\dhcp.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\dns.c -o Build\dns.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\ftp.c -o Build\ftp.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\http.c -o Build\http.o
..\..\..\stack\http.c: In function 'fnHTTPListener':
..\..\..\stack\http.c:560: warning: 'ucPush' may be used uninitialized in this function
..\..\..\stack\http.c:559: warning: 'Len' may be used uninitialized in this function
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\icmp.c -o Build\icmp.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\ip_utils.c -o Build\ip_utils.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\ip.c -o Build\ip.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\pop3.c -o Build\pop3.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\smtp.c -o Build\smtp.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\tcp.c -o Build\tcp.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\telnet.c -o Build\telnet.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\tftp.c -o Build\tftp.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\udp.c -o Build\udp.o
m68k-elf-gcc -mcpu=52235 -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -c -Os ..\..\..\stack\webutils.c -o Build\webutils.o
m68k-elf-gcc -mcpu=52235 -nostartfiles -Wall -Wstrict-prototypes -I..\..\uTaskerV1.3 -D _GNU -D _M5223X -g -Os -Wl,-Map=uTaskerV1.3.map -Tm52235evb-rom.ld -o uTaskerV1.3.elf Build\application.o Build\debug.o Build\webInterface.o Build\KeyScan.o Buil
d\LCD.o Build\NetworkIndicator.o Build\Startup_gnu.o Build\M5223X.o Build\eth_drv.o Build\iic_drv.o Build\Driver.o Build\uMalloc.o Build\uTasker.o Build\Tty_drv.o Build\uFile.o Build\watchdog.o Build\GlobalTimer.o Build\low_power.o Build\Ethernet.o
Build\arp.o Build\dhcp.o Build\dns.o Build\ftp.o Build\http.o Build\icmp.o Build\ip_utils.o Build\ip.o Build\pop3.o Build\smtp.o Build\tcp.o Build\telnet.o Build\tftp.o Build\udp.o Build\webutils.o
c:/programme/codesourcery/sourcery g++/bin/../lib/gcc/m68k-elf/4.1.1/../../../../m68k-elf/bin/ld.exe: warning: cannot find entry symbol _start; defaulting to 00000000
m68k-elf-objcopy --output-target=srec uTaskerV1.3.elf uTaskerV1.3.s19
m68k-elf-size   uTaskerV1.3.elf
   text    data     bss     dec     hex filename
  68288    1072     696   70056   111a8 uTaskerV1.3.elf
This is a standalone build from the supplied make file and the V1.3 project + SP5 (the only change in the original download files was to remove the SUPPORT_RTC comment from app_hw_m5223x.h (because of the RTC interrupt declaration problem which causes it otherwise to crash after 7s - first minute interrupt match) using CS 4.1.23.

Therefore this should serve as an exact reference to see whether there is a problem - it should give identical results.
The warnings are normal and I didn't really see why the compiler is complaining - I couldn't see how the variables could be used uninitialised...

5. Then download to the M52233DEMO or M52235EVB board using either CodeWarrior Flash Tool or CF Flasher 3.1.5 - as described in the uTasker tutorial.

6. If the board is left to run, it is possible to contact it using FTP at 192.168.0.3 and load the demo web pages and then control it.

7. Once the board is operating try debugging with Eclipse because there is still a possibility of the problem being with the debugger (or the Eclipse environment?). Don't forget to deactivate the watchdog (eg. connect IRQ4 to GND) otherwise stopping at a break point will cause the watchdog to fire after 2s.



I hope you solve it soon!!

[johnr]

Mark,
 I'm making some progress. I started clean and unziped the uTasker, SP4, then SP5
files. I commented out RTC_SUPPORT, disabled the WATCHDOG and set the default
network settings to use my network values  and set ethernet to use 10MZ instead of auto-neg. I downloaded the FreeScale CF flash utility and flashed in the code. When it
booted up LED1 was blinking at ~2.5hz rate, the ACT LED was blinking and the LNK LED was on. I was able to ping the address I coded in ! I think changing the auto-neg setting
got the network up.
 When I tried loading the elf into the CS 4.2.23 debugger it stopped immediately like
before with the same debug log. I sent the code to CS to see if they can figure out what is going on. Is there another USB debugger you would recommend using with this
project ?


 Thanks,
 John

[mark]

Hi John

First a small note: all service packs include all previous SPs so to make a fresh V1.3-SP5 only the V1.3 + SP5 is needed (the SP4 step can be skipped but the end result is the same).

Your results are interesting since the build (at least in SREC format) is obviously good. You possibly have an autonegotiation issue due to the known PHY silicon bug (see tutorial notes on the bugs - and happens with certain switches) since the fixed speed has it up and running.

I hope that the guys at CS can shed some light on the debugger problem - I know that the version that I have been using doesn't support flash download and so CF3.1.5 is needed before actually debugging can begin, but I understand that the newer version have full support - however I wonder whether it is more a FLASH loading problem than an ELF problem?

I have to make a confession because I have never debugged from eclipse with the Coldfire. I did try it once but didn't get very far due to USB and other problems (no chance on my laptop) but it did communication on a second PC, unfortunately I still couldn't get any debugging operating. It does however work (and very well) as confirmed by other users but I am a bit unlucky with such tools and don't always have much patience. So all my work is in fact performed in the uTasker simulator and most of the time it runs, whether compiled with CW6.3 or CS (GCC) on the target. When I get an issue (eg. it runs with CW but not with CS, or a low level driver problem) I tend to use the CW6.3 debugger - it is in fact very good... and even debugging GCC is no big issue because as long as I know where the critical routines are (from MAP file) the assembler is adequante to find the problem - the types of bugs are usually best found at assember level (eg. the CS bug with optimising where the TICK ISR  returns using RTS rather than RTE). Code level is not often required since this can be fixed in the simulator before getting on to the hardware. Debugging exceptions is great on the Coldfire because usually analysing the stack explains what has gone wrong...

Having said this I am determined also to do some real debugging with Eclipse (GDB) - once I get that urge again I will give it another try!!

As a "back up" I would certainly recommend installing CW6.3 (special edition) which you probably received with the demo board. This is 128k code limited - this is usually more than enough for most uTasker based projects - plus the file system (which is not counted as code). It works very well with the DEMO board (with integrated BDM) and its use is fully documented in the uTasker tutorials (incl. Boot loader tutorials).

Regards

Mark

[johnr]

Mark, I tried compiling the project using CS 4.2.23 and flashing it in with the
freeScale utilty and it didn't run. I notified CS of this. I'll give the CW 6.3 debugger a shot and see how it works.

 Thanks for the help,
 John

[mark]

Hi John

I expect that the new CS version still has the problem with the TICK interrupt. I have observed that the optimiser includes the OS Tick routines in the IRQ and calls it using JMP. This means that the return from the OS TICK routine (fnRtmkSystemTick()) must be correct - ie. RTE and not RTS.

In CodeSourcery G++ Lite 4.1-32 (GCC 4.1.1) it was correct using -Os (optimise for size).
In CodeSourcery 4.2-15 (or 4.2-8 Lite) it was incorrect for optimisations higher that -O2.
It may be that CS 4.2.23 is always incorrect.

What I don't understand is why this GCC error is still present since it was reported a month or so ago before the last release and I would have expected it to get better rather than worst. I am also wondering why this interrupt routine is so sensitive - it is a completely normal use of a simple subroutine call.

In any case I would stick with G++ Lite 4.1-32 since it has worked very well in all my tests until the issue has been solved by the GCC people.

Regards

Mark

[johnr]

Mark, my 30 day eval of CS ran out and they gave me no time line when they
would get the uTasker project compiled properly and the debugger running on the M52233DEMO pcb ,so I'm going to try the Code Warrior debugger.

 John