MPC5777C C55FMC write and readback reads 0xFFFFFFFF after reset.

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

MPC5777C C55FMC write and readback reads 0xFFFFFFFF after reset.

1,005 Views
ajmerijaimin
Contributor III

I'm working with embedded flash memory C55FMC. To test if my write operation is working properly I'm performing following operations in the sequence below.

1. Read before

2. Erase

3. Write

4. Read after

I'm using trace32 debugger. I use breakpoints to halt. Then use the d.dump command to view the contents of the memory.

In step 4, I see the expected content that I write at step3. I expect the data to persist after reset. When I triggered reset using trace32, at step1, I see all 0xFFFFFFFF values after reset instead of my expected content that was written before reset.

I'm new to this controller. I'm not sure if LOCK bits are causing an issue. Please suggest. I have tried writing to different regions, 0x00000000 and 0x00F80000 but I see the same results. Below is the snippet that I have used.

void read_flash(uint32 *flash_address)
{
    uint32 data_read[4];

    for (uint8 i=0; i<4; i++)
    {
        data_read[i] = *flash_address;
        flash_address++;
    }
}

void erase_flash(uint32 *flash_address)
{
	C55FMC.LOCK0.B.LOWLOCK = 0x0;
	
    // enable erase
    C55FMC.MCR.B.ERS = 1;

    // select block, SEL0, SEL1, SEL2, or SEL3
    C55FMC.SEL0.B.LOWSEL = 1;

    // erase interlock write, 0xFFFFFFFF
    *((uint32 *) flash_address) = 0xFFFFFFFF; 

    // start internal erase sequence, MCR[EHV]
    C55FMC.MCR.B.EHV = 1;                 

    // wait for erase to complete, MCR[DONE]
    while(C55FMC.MCR.B.DONE == 0);

    // confirm if PEG == 1, MCR[PEG]
    while(C55FMC.MCR.B.PEG == 0);

    // disable erase sequence, MCR[EHV]
    C55FMC.MCR.B.EHV = 0;

    // terminate erase, MCR[ERS]
    C55FMC.MCR.B.ERS = 0;
}

void write_flash(uint32 *flash_address)
{
    C55FMC.LOCK0.B.LOWLOCK = 0x0;

    // enable programming, MCR[PGM]
    C55FMC.MCR.B.PGM = 1;

    // write first data, data interlock write
    // write additional data if any
    for (uint32 i=0xAA55AA00; i<0xAA55AA04; i++)
    {
        *flash_address = i;
        flash_address++;
    }

    // start programming sequence, MCR[EHV]
    C55FMC.MCR.B.EHV = 1;

    // wait for programming to complete, MCR[DONE]
    while(C55FMC.MCR.B.DONE == 0);

    // confirm if PEG == 1, MCR[PEG]
    while(C55FMC.MCR.B.PEG == 0);

    // disable programming sequence, MCR[EHV]
    C55FMC.MCR.B.EHV = 0;

    // disable programming, MCR[PGM]
    C55FMC.MCR.B.PGM = 0;
}

int main()
{
    HW_init();
    Interrupts_init();
    Interrupts_enable_Core0();
    
    // also tried with 0x00F80000 with corresponding LOCK bit = 0
    read_flash((uint32 *) 0x00000000);
    erase_flash((uint32 *) 0x00000000);
    write_flash((uint32 *) 0x00000000);
    read_flash((uint32 *) 0x00000000);
}
0 Kudos
7 Replies

948 Views
ajmerijaimin
Contributor III

I did try to step in at FlashInit. Nothing happens, I don't see the current line of execution. I will try to set IVPR and IVOR registers. The compiler version specified in the SSD user manual for GHS is the 6.1.4 version.

I have a few more questions, please suggest.

  1. I am able to compile the demo gpj project files that uses for the c-array driver. This is the first time I have come across a driver in the form of a C-Array. For my knowledge and understanding can you share some information about it?
  2. I'm new to MPC5777C power architecture. Using GHS how do I compile the demo project that uses s-record files? Is it more helpful for debugging?
0 Kudos

941 Views
rweiss
Contributor V

First run to the function call, then switch to ASM mode (MODE.ASM). After that you can step into the function. The C-arrays contain pre-compiled functions, so there is no HLL information. Not sure if the S-Record files can be linked, but it wouldn't make a difference anyway.

Regards,
Reinhard

0 Kudos

939 Views
ajmerijaimin
Contributor III


@rweiss I would start to debug, but just in case I want to know if GHS version could be the problem as I'm using GHS 202014 instead of GHS 6.1.4

0 Kudos

943 Views
rweiss
Contributor V

First run to the function call and then switch to ASM Mode (MODE.ASM). Then you can step in using F2.

The C-arrays contain pre-compiled function code, so there are no debug symbols, only ASM.

 

Regards,
Reinhard

0 Kudos

960 Views
ajmerijaimin
Contributor III

Hello Reinhard,

Thanks for the prompt response. I would stop observing flash memory using trace32 debugger when flash operations are in progress. What I actually did is after the programming sequence (write_flash) I put breakpoints in the read_flash function to observe if the data persists after reset. I didn't see the expected results.

I do have the v1.1.0 of SSD drivers.

I have moved the source and header files from the SSD driver to my project. I was able to solve the compilation errors and produced the hex file. but on calling pFlashInit it doesn't return. I suspect it's in some fault handler. Can you please suggest if I'm missing some settings in the Linker file or something else? I'm using GHS 202014.

Control doesn't return after calling:

 

/* Flash Init */
returnCode = pFlashInit(&ssdConfig);

 

This is my main function:
I have used breakpoints to check if pFlashInit() call was successful.

 

uint32 my_buffer[32];

void main (void)
{    
    register uint32 returnCode;
    register uint32 result;
    register uint32 dest;
    uint32 size;
    uint32 source;

    /* Hardware initialization */
    HW_init();
    Interrupts_init();
    Interrupts_enable_Core0();
	
    for (uint8 i=0; i<32; i++)
    {
        my_buffer[i]=i;
    }
	
    pgmCtxData.pReqCompletionFn = pFlashProgram;
	
    ssdConfig.c55RegBase = C55_REG_BASE;
    ssdConfig.mainArrayBase = MAIN_ARRAY_BASE;
    ssdConfig.uTestArrayBase = UTEST_ARRAY_BASE;
    ssdConfig.mainInterfaceFlag = TRUE;
    ssdConfig.programmableSize = C55_PROGRAMMABLE_SIZE;
    ssdConfig.BDMEnable = FALSE;
	
    DisableFlashControllerCache(FLASH_PFCR1, FLASH_FMC_BFEN, &pflash_pfcr1);
    DisableFlashControllerCache(FLASH_PFCR2, FLASH_FMC_BFEN, &pflash_pfcr2);
	
    returnCode = pFlashInit(&ssdConfig);

    if (C55_OK != returnCode)
    {
        while(1);
    }
	
    dest = BLOCK_START_ADDRS[2];
    size = 32;
    source = (uint32) my_buffer;
    result = App_FlashProgram(&ssdConfig, FALSE, dest, size, source, &pgmCtxData);
    if (C55_OK != returnCode)
    {
       while(1);
    }

    //PIT0_init();	// set to generate 1sec interval
    //PIT2_init();

    while(1);
}

 

 

 

 

0 Kudos

951 Views
rweiss
Contributor V

Hi Ajmerijaimin,

I would suggest to step into FlashInit and find out why it fails. Your application should set up IVPR and IVOR registers, so you can set breakpoints to the program and data exceptions. The exception registers (SRR, DEAR, ESR, MCSR/AR) will tell you what the problem was. A data exception will be most likely, but as MPC5777C supporty both BookE and VLE instruction sets, also doucle check if the used library files match the compiler configuration.

Regards,
Reinhard

 

0 Kudos

993 Views
rweiss
Contributor V

Hi Ajmerijaimin,

don't observe FLASH memory with the debugger while any FLASH programming or erase operation is in progress. Spectulative FLASH accesses are not allowed during FLASH operations, it leads to undefined behavior.

By the way, I would recommend to use the MPC5700 C55FG Flash Standard Software Driver rathern than own implementations.

Regards,
Reinhard

0 Kudos