MPC5644A:Erase and write flash don't work in flash debug mode but work in ram debug mode

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MPC5644A:Erase and write flash don't work in flash debug mode but work in ram debug mode

Jump to solution
2,268 Views
haitaoliu
Contributor I

Hi,

I want make a bootloader program. I use Codewarrior 10.6, and my CPU is MPC5644A.

1. I build ‘RAM’ for project and debug it, the project works well , no errors, I can erase and write.

2. I build 'FLASH' for project and debug it, the project stop work and go to trap1.

3. I found where the CPU stoped,it's a while loop when wait the 'flash->MCR.B.DONE' bit to 1. As long as CPU enters this cycle, it will go to the trap 1. But there is no error when build 'RAM' and debug.

4. At the while loop, I set a breakpoint and step into (F5), there is no errors.

My flash.lcf:

MEMORY

{

    /* FLASH: 0x00000000 - 0x0003FFFFF */

    /* Fixed location required for RCHW and program entry point*/

    resetvector:           org = 0x00000000,   len = 0x00000008

    init:                  org = 0x00000010,   len = 0x00000FF0

    exception_handlers: org = 0x00001000,   len = 0x0001000

    internal_flash:        org = 0x00002000,   len = 0x00006000

    boot_flash:               org = 0x00008000,   len = 0x00008000 /**not use, I only used the internal_flash**/

    other_flash:           org = 0x00010000,   len = 0x003E0000

 

    /* SRAM: 0x40000000 - 0x40002FFFF */

    /*boot_ram:                 org = 0x40000000,   len = 0x00008000*/

    internal_ram:           org = 0x40000000,   len = 0x00020000

    heap  :                org = 0x40020000,   len = 0x00008000

    stack :                org = 0x40028000,   len = 0x00008000

}

 

/* This will ensure the rchw and reset vector are not stripped by the linker */

FORCEACTIVE { "bam_rchw" "bam_resetvector"}

 

SECTIONS

{

    .__bam_bootarea LOAD (ADDR(resetvector)): {} > resetvector

 

    /* Section used for initialization code: __ppc_eabi_init.c,

     MPC56xx_HWInit.c, MPC56xx_init_*.c and the entry point (__startup).

     */

    GROUP  : {

        .init LOAD (ADDR(init)) : {}

        .init_vle (VLECODE) LOAD (_e_init) : {

            *(.init)

            *(.init_vle)

        }

    } > init

 

   /* Note: _e_ prefix enables load after END of that specified section */

   GROUP : {

        .intc_hw_branch_table (VLECODE) LOAD (ADDR(exception_handlers)) ALIGN (0x10) : {}

 

        .ivor_branch_table (VLECODE) LOAD (_e_intc_hw_branch_table) ALIGN (0x10) : {}

        /* ISR handlers code. */

        .__exception_handlers (VLECODE) LOAD (_e_ivor_branch_table) : {}

   } > exception_handlers

 

    GROUP  : {

      .text : {}

      .text_vle (VLECODE) : {

            *(.text)

            *(.text_vle)

       }

    

       .rodata (CONST) : {

            *(.rdata)

            *(.rodata)

        }

    

       .ctors : {}

       .dtors : {}

       extab : {}

       extabindex : {}

    } > internal_flash

 

 

    GROUP : {

        /* Used in INTC SW mode to store the interrupt handlers array. Should be aligned to 4K. */

       .__uninitialized_intc_handlertable ALIGN(0x1000) : {}

       .data   : {}

       .sdata  : {}

       .sbss   : {}

       .sdata2 : {}

       .sbss2  : {}

       .bss    : {}

    } > internal_ram

}

 

the place where CPU stops:

/****************************

*EraseBlock() is called by the function of EraseMem()

*****************************/

flasherr_t EraseBlock(volatile struct FLASH_tag *flash, uint32_t addr)

{

  flasherr_t err;

  uint32_t cnt=0;

 

  err=AddrCheck(addr);

  if(err != ERR_OK) return err;

 

  flash->MCR.B.ERS=1;

 

  if((addr>=0x00100000) && (addr < 0x00400000))

    {

      flash->HSR.R=GetFlashBlock(addr);

    }

  else

    {

      flash->LMSR.R=GetFlashBlock(addr);

    }

 

  SetInt32U(addr,0xFFFFFFFF);

 

  flash->MCR.B.EHV=1;

 

/********************************************

* When build 'FLASH' for project and debug, CPU will go to trap 1 while entering while loop.

* But it work well when build 'RAM' for project and debug

* When build ‘FLASH’ for project and debug, I set a breakpoint here and step into(F5), there is no error and CPU doesn't go to trap 1.

*****************************************/

  while(0 == flash->MCR.B.DONE)

    {

      if(cnt++ > MAX_LOOP_CNT)

        {

          flash->MCR.B.EHV=0;

          flash->MCR.B.PGM=0;

          return ERR_OPERATION_TIMEOUT;

        }

    }

/*********************************************

* Here, when step into, I resume(F8), CPU is working properly, no error.

**********************************************/

 

  flash->MCR.B.EHV=0;

  flash->MCR.B.ERS=0;

 

  if((addr>=0x00100000) && (addr < 0x00400000))

    {

      flash->HSR.R=0;

    }

  else

    {

      flash->LMSR.R=0;

    }

 

  if(flash->MCR.B.PEG == 0) return ERR_OPERATION_FAILE;

 

  return ERR_OK;

}

 

How to solve the program?

Thanks!

Original Attachment has been moved to: BootTest.rar

Labels (1)
0 Kudos
Reply
1 Solution
1,688 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

Read-While-Write is supported only between partitions. See the Table 12-1 in:

http://www.freescale.com/files/32bit/doc/ref_manual/MPC5644ARM.pdf

It is not possible to access the partition that is currently being programmed or erased. I guess that this is the root cause when reading your description. The code must run from another partition or from RAM and also make sure that you do not read data from this partition during programming.

Best Regards,

Lukas

View solution in original post

0 Kudos
Reply
2 Replies
1,689 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

Read-While-Write is supported only between partitions. See the Table 12-1 in:

http://www.freescale.com/files/32bit/doc/ref_manual/MPC5644ARM.pdf

It is not possible to access the partition that is currently being programmed or erased. I guess that this is the root cause when reading your description. The code must run from another partition or from RAM and also make sure that you do not read data from this partition during programming.

Best Regards,

Lukas

0 Kudos
Reply
1,688 Views
haitaoliu
Contributor I

Hi,

I mistake partition for block, this may be the problem. I should run the code from RAM.

Thank you Lukas! You helped me a lot!

0 Kudos
Reply