Device not working without debugger

[FredT]

I have a CodeWarrior project that was working with version 6.4, but it's now imported in V7.0 and it's not working anymore. I had a problem with the CACR mnemonic, but since I don't have cache in the MCF52235, I've remove the function that use it.

Now when I program my device and run the debugger, everything s working fine, but if I try to have the device run by itself, nothing is happening except a LED that is suppose to toggle every second is now steady ON. When in that state, I'm starting the debugger and I'm getting a "Exception vector name: Address Error". Seems I'm getting a "Illegal stack type" exception when I'm trying to print something on the UART port, but the exception try to print something too, so the loop is filling the RAM.

Also, sometime when I try to program the device, I get "Error:  System clock check failed  See Details for additional information." in the flash programmer. When it happen, I have to restart CodeWarrior.

Fred Talbot


Message Edited by FredT on 2008-01-08 02:59 PM

[Technoman64]

Check to see that the VBR (vector base address register) is being set correctly.

If the startup code copies the exception vector table to RAM then this register must be set to point to the new table in RAM.

The debugger most likely does this on startup which could expain why it runs with the debugger but not stand alone.

[FredT]

I've looked at the code and it seems like the vector is transfert to RAM and the vbr is set to the new place. Here's the code:

    register uint32_t n;
    register uint8_t *dp, *sp;

    /*
     * Copy the vector table to RAM
     */
    if (__VECTOR_RAM != VECTOR_TABLE)
    {
        for (n = 0; n < 256; n++)
            __VECTOR_RAM[n] = VECTOR_TABLE[n];
    }
    mcf5xxx_wr_vbr((uint32_t)__VECTOR_RAM);

The thing is that the n variable's value is 536891432 (0x20000000) and doesn't change in the for clause, and it location is $A1. What's that suppose to mean ?

The strange thing is that it's working with the debugger if I'm not trying to make it works alone before; if I remove and put back power on the device, and then try with the debugger, it doesn't work. I've looked at the vector table in both situation, and when it doesn't work, the vector table doesn't seems to be moved correctly from ROM to RAM.

Fred Talbot



Message Edited by FredT on 2008-01-09 09:46 AM

[FredT]

It seems to be a reset problem, because when I'm using RUN in CodeWarrior to start the device instead of turning power OFF and ON, everything is working fine. In the help file it says "Use the Run command to execute a program normally, without debugger control", so I think this isn't a application problem but a hardware reset problem, isn't it ?

Fred Talbot




Message Edited by FredT on 2008-01-09 10:13 AM

Message Edited by FredT on 2008-01-09 10:13 AM

[CompilerGuru]

Not sure.
What I would try is to check if your app is doing all the same initializations as the debugger.
The debugger initializaton are by default in
{Project}cfg\MCF52235_INTERNAL_FLASH.cfg
(see in the CF Debugger settings pref panel)
and that file contains for me

Code:

ResetHalt; Set VBR to the beginning of what will be SRAM; VBR is an absolute CPU registerwritecontrolreg 0x0801 0x20000000; Set RAMBAR1 (SRAM)writecontrolreg 0x0C05 0x20000021; Set FLASHBAR (Flash)writecontrolreg 0x0C04 0x00000061; Enable PST[3:0] signalswritemem.b 0x40100074 0x0F

So I would check if all those registers are properly initialized, just as you already did for VBR.

Daniel
 

[FredT]

Seems like the initialization is the same in the debugger and the application, but I think that the problem is that the device initialization as change when migrating from V6.4 to V7.0. I'll try to find the difference.

Something strange, I can't have more than one breakpoint when I'm using the debug. The reference manual is talking about 4 PC, 1 address and 1 data breakpoint.


Message Edited by FredT on 2008-01-10 08:58 AM

[FredT]

Here's some tests I've done:

- I load the device and I use the RUN button to start the device, and the device is running and I can remove the USB DBM interface.

- I load the device, in the CF Debbugger Setting I uncheck the "Use Target Initialization File", and then I use the RUN button to start the device, and the device is running and I can remove the USB DBM interface. I have to program the device with "Use Target Initialization File" checked, cause the programmer can't load the memory when it's unchecked

- I load the device, I turn power OFF/ON, and then use the RUN button to start the device but I doesn't work with the "Use Target Initialization File" checked or unchecked, it doesn't matter.

so I guess the problem is the initialization on power ON only. Since I've uncheck the "Use Target Initialization File", the debbuger isn't doing any initialization of the device, and I can suppose that my device initialization is good.

Am I right ?

Fred Talbot


Message Edited by FredT on 2008-01-11 08:25 AM

Message Edited by FredT on 2008-01-11 08:28 AM

[J2MEJediMaster]

Well, no. If things continue to work as long as the processor is powered, it's quite likely that the debugger set up some register that you need, and it's contents happen to stay that way. So, if your initialization code is faulty, it doesn't matter: your code doesn't touch the register, and the deugger's vaild value remains there, and the program happens to run. Once you cycle the power, the contents of the register get randomized and now that invalid value clobbers the processor from starting up properly. If the program works with the debugger but not as a stand-alone app after a power cycle, it's a initialization code problem. Check your initialization code carefully.

---Tom

[FredT]

Thank for the reply Tom, but why the debugger is giving me "Exception vector name: Address Error" when I turn power OFF/ON and then start the debugger ? If it's an initialization problem, then the debugger should reinitialize the device I guess.

I'll keep looking at my device initialization.

Fred Talbot

[Technoman64]

Did you happen to save the save Codewarrior 6.4 project that was working?

If you did then you could compare the startup code and maybe find the issue.

If not you could re-install 6.4 if not already installed and rebuild the project in a different location and compare code.

Just a thought...

[FredT]

In last resort, I have created a blank project and reimported everything one by one, and it's now working fine.

Probably an initialization problem.

Thank to all for your help.

Fred Talbot