Reprogramming the flash on MC56F82748VLH

[jasonaguayo]

Good morning!

I am attempting to configure my MC56F82748VLH processor to reprogram it's own flash via the serial port.  Part of this process involves erasing

the existing flash program so I can write the new flash program to the chip.

So far, I can erase the entire flash with no problem.  I am running the erase code out of RAM, and I have disabled interrupts in the CPU using the SR register.  However, once I erase the flash, the code after the flash erase stops working.  I have code that spins in a while loop listening to the serial port for instructions from the PC.  The processor stops responding shortly after the flash erase concludes.

I've read through all of Chapter 20: Flash Memory Module in the reference manual; there is no mention of any such problems.  I've erased only part of the flash since thinking maybe erasing the interrupt vector table is causing some system instability.  None of these have solved the problem.

Any suggestions?

[xiangjun_rong]

Hi, Jason,

I think the following customer code is correct.

For the MC56F82748, the 32KW data flash from X:0x00_4000–0x00_BFFF are shared the same physical Flash cell with Program flash P:0x00_0000–0x00_7FFF, the on-chip data RAM from X:0x00_0000–0x00_0FFF are shared physical cell with program RAM from P:0x00_F000–0x00_FFFF. In other words, there are only 32KW flash and 4KW RAM, which have the mirror space in both program and data field.

Pls refer to Chapter 4 Memory Map in MC56F827xxRM.pdf.

If you erase all the 32K data flash, all the program flash will be erased. Furthermore, the program flash space from P:0x400~0x40F are special bytes, they are copied to flash register for example protection register and FTFA_FSEC register after Reset. Especially, the SEC bits should be 10 in binary for the FTFA_FSEC register in order to be in unsecure mode so that JTAG port is not blocked. so you have to set the last LSB in P:0x40c as 10 in binary.

In conclusion, pls check the memory map file of your application to get the program allocation, for example, what space are used for code and constant data, what space is unused, then you can page erase the unused data flash page so that you can save your data to data flash.

Pls refer to the section in MC56F827xxRM.

20.3.1 Flash Configuration Field Description

Hope it can help you.

BR

XiangJun Rong

#define FLASH_ADDRESS_START 0x00004000

#define FLASH_ERASESECTOR_CMD 0x09

targetAddress = FLASH_ADDRESS_START;

for (i = 0; i < 64; i++)

{

  FTFA_FCNFG = 0x00;

  FTFA_FCCOB0 = FLASH_ERASESECTOR_CMD;

  FTFA_FCCOB1 = ((targetAddress) >> 16) & 0xFF;

  FTFA_FCCOB2 = ((targetAddress) >> 8) & 0xFF;

  FTFA_FCCOB3 = (targetAddress) & 0xFF;

  FTFA_FCCOB4 = 0;

  FTFA_FCCOB5 = 0;

  FTFA_FCCOB6 = 0;

FTFA_FCCOB7 = 0;

  FTFA_FSTAT |= 0x70; // Clear the FPVIOL, ACCERR and RDCOLERR flag

  asm(nop); // Wait for one clock ...

  FTFA_FSTAT |= 0x80; // Clear the CCIF flag -> starts Flash execution

  while ((FTFA_FSTAT & 0x80)==0) {}; // Wait for Flash operation to complete

  targetAddress += 0x200;

  tempVal = FTFA_FSTAT;

  QSCI0_DATA = tempVal;

}

[jasonaguayo]

Xiangjun,

Thanks for the reply!  I've changed my strategy.  Rather than erasing the entire flash at once, I'm erasing it one sector at a time and writing the new code to each sector as I retrieve it from the s-record file.

However, I have a new problem.  When I reach s-record address 0x1C34, code execution fails.  Specifically, when I check the debugger, it claims to be erasing and writing the flash again and again, but I don't see new data being written to the flash memory.

Why is this particular address breaking code execution?  This isn't anywhere close to the flash configuration field registers?  I should have already overwritten those earlier.

Jason

[xiangjun_rong]

Hi, Jason,

From your description that you erase/program the word address 0x1C34, obviously, this is a program flash address rather than data flash address. I have checked the RM of Mc56F827xx, I think you have pay attention the following items:

1) the address you write to the FCCOB3~1 is a Byte address instead of HalfWord address, in other words, the actual program  address in reference manual should be left shift ONE bit, then write to the FCCOBx regs.

2)The Program flash sector size is 2KB, while the data flash size is 1KB.

As far as I know, in order to classify the Data flash and Program flash when you erase/program flash, it is required to set the bit 23 of the address when you erase/program program flash. when you program data flash, it is okay to use the data flash address directly. But I am NOT sure if the regulation adapts to MC56F827xx, if you have issue, you can have a try to set the bit 23 of Byte program address.

I am taking spring festival vacation now, I have not board on hand to have a test. If you still have issue, I think the AE team can help you.

BR

XiangJun Rong

[jasonaguayo]

Xiangjun,

I was finally able to figure out the problem.  First, the MC56F82748VLH processor has a contiguous Program/Data flash memory.  Setting bit 23 does nothing when writing to flash.  It is possible to protect sections of flash from writes/erases, but I did not have this feature enabled. 

It turns out my code wasn't actually running in RAM.  I wrote the function using a switch() statement as a state machine.  When I checked the disassembly, I found the compiler interprets switch statements as JUMP instructions, which use absolute addresses.  Thus, the code would jump from RAM back into flash memory when it changed states.  It would run correctly until the function erased the flash block from which it was running, which happened to be at 0x1C34, at which point the processor crashed.

To fix this, I changed my code to use if/else statements for the state machine, which the compiler interprets to BRANCH instructions instead of JUMPs.  This permits the code to run completely in RAM without jumping into flash memory.

Jason