Service Pack 6 and CodeWarrior 7.0

[Richard]

Hi.

Has anyone succeeded in getting Service Pack 6 to run using CodeWarrior 7.0?

A couple of months ago, Freescale upgraded CodeWarrior to version 7.0 (see <http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=CWS-MCF-STDED-CX&fsrch=1>).  As is now usual, the "standard edition" is free, so I downloaded it and have been using it for my project, which is based on Mark's V1.3 SP5 code and its various patches.  It runs on the M52233DEMO board.

To remain current, I decided to switch my project over to SP6 and then ran into trouble.  To try to figure out what went wrong, I went back to the original V1.3 release, loaded SP6 over it, renamed its config_ref... to config.h and made two copies of the resultant directory structure.

I ran one copy using CW 6.4, using CFM_MCXF52233 to set the parameters of the Flash Programmer.  This appears to have been successful, because the program runs, and if I set a breakpoint at the beginning of fnApplication(), it gets to that breakpoint and halts.

I tried then to run the other copy using CW 7.0, using MCF_52233_INTFLASH.xml to set the parameters of the Flash Programmer.  This version can erase the FLASH and load the program.  However, when I start the debugger, it opens at .debug_frame + 0x00000000, and nothing I can do will convince it to take even one step into the program.  Single stepping does nothing.  If I start it running and then stop it, it's always at the first step.  If I set a breakpoint at the beginning of fnApplication(), it never gets there.

It must be possible to make SP6 run using CW 7.0.  Is there some magic I've missed?

Thanks,
    Richard

[mark]

Hi Richard

The biggest change in the SP6 is that the compiler setting has been changed to use "register passing". This results in better code density with no "known" side-effects.

However I haven't tested with CW7.0, although I have recently installed CW7.0 (on a reserve PC).

If you don't quickly find anything obvious with regards to a setting I suggest staying with CW6.4 for the moment. I will try to get the CW7.0 project working this evening and report back.

Regards

Mark

[mark]

Hi Richard

I have just used an M52233DEMO board to do the following test:

1. Install M5223X V1.3.0 project
2. Install M5223X SP6
3. Build using CW 7.0 (it had to convert the project to the new format and this seemed to work with the exception of not being able to find a file - it wasn't a source file so I ignored it). Using the reference config.h it compiled without errors or warnings. (M52235EVB_ROM build)
4. Deleted all FLASH on the board using the FLASH tool (setup for M52233 - same as M52235)
5. Downloaded to the target using the same tool.
6. Ran the code using CW7.0 debugging session. This worked correctly.
7. Quit the debugging session and tried to run the code standalone. Here it didn't work until I removed the USB connector from the integrated BDM. After that it also ran fine, booting itself from FLASH.

Therefore (apart from the last step) I didn't find anything which stops the project working with CW7.0.

Have you found anything at your end?

Regards

Mark

[Richard]

Hi, Mark.

I'm really puzzled.  I've tried everything I can think of, including downloading and installing a new version of CW 7.0.  I did this even though it was identical to the version I had already installed, just in case the installation program set some registry values or performed some other magic.  I also used a new M52233DEMO board.  As I said, I can successfully compile the code and erase and program the M52233 = the first 5 steps of your test.  But when I run the debugger, it opens pointing at .debug_frame + 0x00000000, and nothing I can do will convince it to take even one step into the program.  It's as though I have the wrong debugger or maybe the wrong linker.  Or maybe some parameter file or initialization values are missing and the linker or debugger is defaulting to some bizarre values.

Here is what the debugger is pointing at:

Code: [Select]

00000000: 2000            move.l   d0,d0
00000002: 8000            or.b     d0,d0
00000004: 00000008        ori.b    #0x8,d0
00000008: 46FC2700        move     #9984,sr
0000000C: 203C20000000    move.l   #536870912,d0
00000012: 068000000021    addi.l   #33,d0
00000018: 4E7B0C05        movec    d0,rambar1
0000001C: 2E7C20008000    movea.l  #536903680,a7
00000022: 203C40000000    move.l   #1073741824,d0
00000028: 068000000001    addi.l   #1,d0
0000002E: 23C040000000    move.l   d0,0x40000000 (0x40000000)
00000034: 203C00000161    move.l   #353,d0
0000003A: 4E7B0C04        movec    d0,rambar
0000003E: 4EB9000027BC    jsr      mcf52235_init (0x27bc)  ; 0x000027bc
00000044: 4EB900000420    jsr      main (0x420)            ; 0x00000420
0000004A: 4E7B0801        movec    d0,vbr
0000004E: 4E71            nop
00000050: 4E75            rts

By looking at startup.s, I see that it should be pointing at location 0x8 instead of 0x0.  If I try to set the program counter to that value, I get debugger error 104101 that says "Could not get information on program counter register by name or generic ID.  An error occurred while trying to write the register value."

Does this error when trying to change the program counter help in assessing possible problems?

I am now stuck.  I don't even know what else to try.  If I reach for straws, I wonder if it is possible that I have a file on my machine that interferes with the normal operation of CW 7.0 (but not CW 6.4, where I don't have these problems) or that I lack a crucial file that is on your machine.

Any thoughts?

Thanks,
    Richard

[mark]

Hi Richard

The code looks fine:
the first 2 long words are being disassembled (although they are not instructions, so these can be ignored) - the  first long word is the stack pointer to be loaded by default and the second the start address for the program counter 0x00000008. Therefore I expect the code to start excecuting at location 0x00000008 when it is run.

Try the following:
1. In the debugger setup enable "run to main"
2. Connect with the debugger and set a break point at the address 0x00000008
3. Quit the debugger
4. Reconnect and see whether it has tried to start and hit the break at 0x00000008. If it has, try to single step (F11) in the assembler code

Note:
Ensure that the watchdog is disabled when debugging. Either pull IRQ4 low or remove the initialisation (CONFIGURE_WATCHDOG defined as 0 in app_hw_m5223x.h) - this is valid also for CW6.4.
I just connected with the debugger and let it run and it worked. I didn't actually try stepping. Also I never had any luck with resets in CW. I always disconnect and reconnect if I want the program to restart.

Hope you can find out what is going on there!

Regards

Mark

[Richard]

Hi, Mark.

I have set WATCHDOG_DISABLED to (1), commented out M52235EVB, and defined M52233DEMO.

By step 1, I assume you mean to open the settings panel (Alt+F7) and set the debugger setting "Stop on application launch" to "User specified" and set that to "main".
I then do steps 2-4.
However, quitting and restarting the debugger doesn't get anywhere.  The red ball at 0x08 shows up as hollow.  Using the cursor and right clicking, I can enable the breakpoint.  The arrow showing the PC is at 0x00, and anything done to try to start the computer does almost nothing.  If I press F11 sometimes I can see the red square ("break") flash for an instant, but the big blue arrow (which I presume represents the contents of the program counter) remains at 00000000.  If I click the run icon, the debugger reports that it is executing, but then pressing the break icon shows that the PC is still at 0x00.

One more thing.  If I create a totally new project using CW 7.0, it starts at _startup and happily steps through its initial instructions.

Weird!

    - Richard

[Richard]

Hi, Mark.

Sorry to have been silent for the last couple of days, but other projects intruded.

I've now got SP6 and CW 7.0 working together as expected -- but I can't be sure what it is that I did that made this happen.  My best guess is that wiping out the data directory, ...\Applications\uTaskerV1.3\CodeWarrior_M5223X\uTaskerV1.3\uTaskerV1.3_Data, and then restarting CW 7.0 may have been what did the trick.  But I also spent a bit of time with a new project, staring at its startup code, trying to decide whether I needed to prepend an underscore to the start label in Startup.s; i.e., trying to decide if start or _start was the right value for the Entry point in the linker options (I decided it should be start).  Maybe my manipulation of the linker options reset something.  As you might be able to tell, I'm grasping at straws and don't know what fixed the problem.

Now, when the debugger starts, it shows .debug_frame +0x00000005 and DummyFn1.  I can single step as expected, and if I let the program run and then stop it using "break", it ends up in a reasonable place in the program, not still stuck at the top.

I don't yet have the code I wrote working as it did with SP5 and CW6.4, but now I can work on that problem.

Best regards,
    Richard