BDM - flash programmer failure

ValentinG — Mon, 24 Oct 2011 21:50:33 GMT

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

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?

Re: BAD - flash programmer failure

ValentinG — Tue, 25 Oct 2011 15:35:13 GMT

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

topic BDM - flash programmer failure in ColdFire/68K Microcontrollers and Processors

BDM - flash programmer failure

Re: BAD - flash programmer failure