TMS320F28379D: Flash Operations Problem

alikaan

Part Number: TMS320F28379D

Hi,

When text is written and deleted consecutively 15-16 times to the microchip's flash, CCS disconnects from the debug screen. I need to cut off the power and re-power the board after that.

Also flash operations example is working for just one time. I need to write/erase several times continuously.

Any suggestion?

over 2 years ago

0 MatthewPate over 2 years ago

TI__Guru* 81560 points

Can you give some more details on how you are programming the flash, is it though CCS load or the CPU running code calling the flash API? As to the operations example, this is just a collection of the different flash commands to show usage, there should not be any reason the flash program/erase functions can't be called more times.

I believe in this example we are disabling the watchdog timer, so there should not be any risk of it timing out, but you could make sure this is the case that the watchdog disable function is getting called at the top of the example. There are ways to keep the WD enabled if that is important, but you have to use a callback function to service the WD in between the different flash operations.

Best,

Matthew

0 halit derda over 2 years ago in reply to MatthewPate

Prodigy 10 points

Hi Matthew,

We have a issue about flash programming via Flash Api Fapi library.

In our case, we need to write, read and some times erase our application related variables to some nonvolatile memory like external eeprom but in our case we are using MCU's internal flash sector N instead of external eeprom for that purpose ( our mcu c2000 f28379d ).

These read, write and erase cases not just one time situations, especially whenever application need to record or update some application related variables, this flash programming part of code needs to execute, for example we have 32bit x 255 variables and need to record all these varables every 1 sec continuously.

In code watchdog disabled all the time, we are not using watchdog. Our code is a little bit complex we have several interrupt routines thats are executing in both flash and ram sections. Also our flash read write erase part of code not executing on ram (.TI.ramfuncs) , its runs on flash. I see several post for ram and flash part execution cause problems for this fapi function related code execution. I try to put this fapi related code to both flash and ram, but didnt effect our examples very much, still we are recording our values and after 20 25 times recording, a problem rises and in debug mode, debug disconnecting then reconnect to our board some variables writed to flash but somes are not and some times all the variables 0XFF. This issue a little bit random. Also i tried to run stand alone without debugging, result is same.

Also writing to sector N there is some sort of sequence, we are not writing to sector N without erasing this sector before writing. Is that true, we need to erase before every writing?

Also our system clock 200Mhz , we are configuring flash api 200Mhz or 206Mhz %3 percent rule but not working, we configure fapi inint 120Mhz, its working at the above problematic case. Why isnt working 200Mhz?

I shared flash programming part of code:

In .cmd file:

We added,

BufferDataSection : > RAMD1, PAGE = 1, ALIGN(8)

In flash programming library part of code:

#define WORDS_IN_FLASH_BUFFER 0xFF // Programming data buffer, words

#pragma DATA_SECTION(FlashBuffer,"BufferDataSection") ;

unsigned int FlashBuffer[WORDS_IN_FLASH_BUFFER + 1];

unsigned long int *FlashBuffer32 = (uint32 *)FlashBuffer;

unsigned int FlashReadBuffer[50];

t_Flash_Operation_RWE_s Flash_Operation_RWE_Object;

void FlashEraseOperation()

{

uint32 u32Index = 0;

uint16 i = 0;

Fapi_StatusType oReturnCheck;

volatile Fapi_FlashStatusType oFlashStatus;

Fapi_FlashStatusWordType oFlashStatusWord;

// *

// * Erase Flas Sector

// *

EALLOW;

DcsmCommonRegs.FLSEM.all = 0xA501;

EDIS;

InitFlash();

// Disable ECC.

EALLOW;

Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0x0;

// This function is required to initialize the Flash API based on System

// frequency before any other Flash API operation can be performed

oReturnCheck = Fapi_initializeAPI(F021_CPU0_BASE_ADDRESS, 120);

// Fapi_setActiveFlashBank function sets the Flash bank and FMC for further

// Flash operations to be performed on the bank

oReturnCheck = Fapi_setActiveFlashBank(Fapi_FlashBank0);

// Erase Sector N

oReturnCheck = Fapi_issueAsyncCommandWithAddress(

Fapi_EraseSector, (uint32 *) Bzero_SectorN_start);

// Wait until FSM is done with erase sector operation

while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady)

{

}

// Verify that SectorL is erased. The Erase step itself does a

// verify as it goes. This verify is a 2nd verification that can be done.

/* oReturnCheck = Fapi_doBlankCheck((uint32 *) Bzero_SectorN_start,

Bzero_16KSector_u32length,

&oFlashStatusWord); */

// Enable ECC.

Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0xA;

// Release flash semaphore.

DcsmCommonRegs.FLSEM.all = 0xA500;

EDIS;

}

void FlashReadOperation()

{

Fapi_doMarginReadByByte((uint16_t *)Bzero_SectorN_start, FlashReadBuffer, 27, Fapi_NormalRead);

// Variables Readed...

}

void FlashWriteOperation()

{

uint32 u32Index = 0;

uint16 i = 0;

Fapi_StatusType oReturnCheck;

volatile Fapi_FlashStatusType oFlashStatus;

Fapi_FlashStatusWordType oFlashStatusWord;

//*

//* Write variables to Flash Sector

//*

EALLOW;

DcsmCommonRegs.FLSEM.all = 0xA501;

EDIS;

InitFlash();

// Disable ECC.

EALLOW;

Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0x0;

// This function is required to initialize the Flash API based on System

// frequency before any other Flash API operation can be performed

oReturnCheck = Fapi_initializeAPI(F021_CPU0_BASE_ADDRESS, 120);

// Fapi_setActiveFlashBank function sets the Flash bank and FMC for further

// Flash operations to be performed on the bank

oReturnCheck = Fapi_setActiveFlashBank(Fapi_FlashBank0);

// Wait until FSM is done with erase sector operation.

while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady)

{

}

FlashBuffer[0] = 0 ;

FlashBuffer[1] = 0 ;

FlashBuffer[2] = 0 ;

FlashBuffer[3] = (Uint16)(variable) ;

FlashBuffer[4] = (Uint16)(variable) ;

FlashBuffer[5] = (Uint16)(variable) ;

FlashBuffer[6] = (Uint16)(variable) ;

FlashBuffer[7] = (Uint16)(variable) ;

FlashBuffer[8] = (Uint16)(variable) ;

FlashBuffer[9] = (Uint16)(variable) ;

FlashBuffer[10] = (Uint16)(variable) ;

FlashBuffer[11] = (Uint16)(variable) ;

FlashBuffer[12] = (Uint16)(variable) ;

FlashBuffer[13] = (Uint16)(variable) ;

FlashBuffer[14] = (Uint16)(variable) ;

FlashBuffer[15] = (Uint16)(variable) ;

FlashBuffer[16] = (Uint16)(variable) ;

FlashBuffer[17] = (Uint16)(variable) ;

FlashBuffer[18] = (Uint16)(variable) ;

FlashBuffer[19] = (Uint16)(variable) ;

FlashBuffer[20] = (Uint16)(variable) ;

FlashBuffer[21] = (Uint16)(variable) ;

FlashBuffer[22] = (Uint16)(variable) ;

FlashBuffer[23] = (Uint16)(variable) ;

FlashBuffer[24] = (Uint16)(variable) ;

FlashBuffer[25] = (Uint16)(variable) ;

FlashBuffer[26] = (Uint16)(variable) ;

for ( i = 0, u32Index = Bzero_SectorN_start; ( u32Index < (Bzero_SectorN_start + WORDS_IN_FLASH_BUFFER) ) && (oReturnCheck == Fapi_Status_Success) ; i += 8, u32Index += 8 )

{

//Fapi_issueProgrammingCommandForEccAddresses();

oReturnCheck = Fapi_issueProgrammingCommand( (uint32 *)u32Index , FlashBuffer + i , 8 , 0 , 0 , Fapi_AutoEccGeneration );

// Wait until FSM is done with program operation.

while(Fapi_checkFsmForReady() == Fapi_Status_FsmBusy)

{

}

// Read FMSTAT register contents to know the status of FSM after

// program command for any debug.

//oFlashStatus = Fapi_getFsmStatus();

// Verify the values programmed. The Program step itself does a verify

// as it goes. This verify is a 2nd verification that can be done.

/* oReturnCheck = Fapi_doVerify((uint32 *) u32Index, 4,

FlashBuffer32 + (i / 2),

&oFlashStatusWord); */

}

// Enable ECC.

Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0xA;

// Release flash semaphore.

DcsmCommonRegs.FLSEM.all = 0xA500;

EDIS;

}

void FlashOperations(void)

{

switch ( Flash_Operation_RWE_Object.Flash_Operation_States )

{

case FLASH_OPERATION_DUMMY_STATE:

// pass

break;

case FLASH_OPERATION_ERASE_STATE:

FlashEraseOperation();

Flash_Operation_RWE_Object.Flash_Operation_States = FLASH_OPERATION_DUMMY_STATE;

break;

case FLASH_OPERATION_READ_STATE:

FlashReadOperation();

Flash_Operation_RWE_Object.Flash_Operation_States = FLASH_OPERATION_DUMMY_STATE;

break;

case FLASH_OPERATION_WRITE_STATE:

FlashEraseOperation();

FlashWriteOperation();

Flash_Operation_RWE_Object.Flash_Operation_States = FLASH_OPERATION_DUMMY_STATE;

break;

default:

// pass

break;

}

This function FlashOperations() running in main when ver states triggered for writing, reading or erasing.

Any ideas welcome?

0 MatthewPate over 2 years ago in reply to halit derda

TI__Guru* 81560 points

The flash API must run from RAM or a different flash bank. On this device for CPU1, that would mean the API must be in RAM. If you were programming CPU2 with CPU1 then you could keep the API in CPU1's flash when programming CPU2s flash. CPU2 cannot program CPU1's flash, so that is why we must place in RAM.

This is because of the contruction of the flash, during programming operations other sectors may be impacted. The prefetch buffer might be helping us out here, but again this is not recommended and I would advise to place all API in RAM for proper device operation.

In terms of the frequency, the margin you mention is with regard to using the internal oscillator as the clock source, since it has a tolerance variation that would cause the device to operate outside the upper spec limit, if you locked in for 200MHz assuming 10MHz source. Flash operations are time based, meaning there are finite delays that are used, so there is no advantage in running 200MHz vs 120MHz for this operation.

In terms of CCS disconnecting, there are certain security settings (DCSM) that are held in OTP sectors. If these are being read during flash programming it might cause some connection issues, if security is active and the code is executing from secure region it will block the emulator connection. You might look in your code if security is being activated, etc.

Best,

Matthew

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28379D: Flash Operations Problem