BDM - flash programmer failure

[ValentinG]

Hello,

I have a very basic problem. I write a small application in a sooper loop maner, for coldfire MCF52255 using CW10. After I test the code in debug mode, using USB TapBDM, I try to install the code using Flash Programmer. I downloaded succesfuly code on the target but the application refuse to start.

There is the last part of the programmer’s report:

Downloading 0x00000418 bytes to be programmed at 0x00000000  

 Programming ....

 Program Command Succeeded   

Downloading 0x00001080 bytes to be programmed at 0x00000500  

 Programming ....

 Program Command Succeeded   

cmdwin::fl::verify

-------------------------

Verifying file D:\PrjEW_MonoBoard\Firmware_mod\MonoBoard\MCF52255_Release\MonoBoard.elf  

Auto-detection is successful.  

  File is of type Elf Format.  

Reading 0x00000418 bytes starting from address 0x00000000  

Reading 0x00001080 bytes starting from address 0x00000500  

Verify Command Succeeded

I suspected that some registres that are not initialised correctly. I think that in debug mode the bootloader make all the setting so my application can run properly.

The next step was to test as low level as posible the CPU running path. So in startup file, after the first settings I inserted one function that will toggle one led (located on PORTTI bit0).  The code refuse to execute this function eather.

Here is the _startup() function

asm __declspec(register_abi) void _startup(void)

{

      /* disable interrupts */

    move.w        #0x2700,sr

      /* Pre-init SP    */

      lea __SP_AFTER_RESET,a7;

    /* initialize memory */

    MEMORY_INIT

     /* initialize any hardware specific issues */

    /* ISPBAR, FLASHBAR, pll, SCM, exceptions */

    jsr         __initialize_hardware  

    /* this function will block the program and will blink the LED */

    jsr           signal_led_run

      …     /* other code - never arrive here*/

}

The function that toggle the led is implemented in ASM:

asm __declspec(register_abi) void signal_led_run(void)

{

      move.b  #0xff,d0

      move.b  d0,0x4010001C         /* DDRTI  output*/

__loop_led_run:

      move.b #0x01, d0

      move.b d0, 0x40100034         /* SETTI */

      nop

      nop

      move.b #0x00, d0

      move.b d0, 0x4010004C         /* CLRTI */

      bra __loop_led_run            /* loop back */

      nop

      rts  

}

I want to know if anybody had similar problems.

What may be the reason for such behaviour?

This code is very basic, can someone confirm that in this stage of initialization the controller can access external ports?

[ValentinG]

hi,

I found the problem and I will present the problem there, maybe someone will face the same problem sometime.

In my project I eliminate all the EWL libraries and all the including paths to the Freescale framework. I wanted to make my project independent of libraries saved in "MCUToolsBaseDir"(where the eclipse is installed). The problem was in the _startup function where the MEMORY_INIT  macro is placed. If this macro is not defined it will be defined with default value in startup.h

#ifndef MEMORY_INIT
/* If MEMORY_INIT is set then it performs
   minimal memory initialization (to preset SP to __SP_AFTER_RESET, etc...)
*/
#define MEMORY_INIT
#endif

because I didn't include all external *.h (#include "support_common.h" in particular), I loosed the first definition of the macro, the one that should initialize RAMBAR register. The correct macro definition is placed here:

#define MEMORY_INIT \
    /* Initialize RAMBAR: locate SRAM and validate it */ \
    move.l    %#__RAMBAR + 0x21,d0; \
    movec    d0,RAMBAR;

I discover in an empiric way that this macro should be called before any function, it have to be placed directly in the _startup function.

Regards,

Valentin