TMS320F280049: Flash API Operate Question

Hi,

Bolt Hsieh said:

If we place the Flash API program in Flash Bank0 and perform Program & Erase operations on Flash Bank1, will this affect the data in Flash Bank0, impact the ECC of Flash Bank0, or affect the data in the last sector(=15) of Flash Bank0?

No this will not have any impact on BANK0.

Bolt Hsieh said:

Additionally, if we place the Flash API program in sectors 1 to 3 of Flash Bank0 and then perform Program & Erase operations on sectors 4 to 15 of Flash Bank0, what occasional or inevitable issues might occur?

You can't do read and wirte operation on same banks. For this approach you have to copy your code from sector 1 to 3 into RAM and execute your code from RAM. You can refer our flash api example "flashapi_ex1_program_autoecc" located in C200ware. Also refer http://www.ti.com/lit/pdf/spnu628 document for more details.

Regards,

Rajeshwary

Hi Rajeshwary,

Thanks for your response.

If I use the function Fapi_issueProgrammingCommand() with the Fapi_AutoEccGeneration method:

1. After a Flash Erase, if I write 0xFFFF (Can the FMC recognize that the updated value is the same as the erased state and skip the write?), can I later modify it to 0x0000?
2. If an address has already been programmed with a non-0xFFFF value (e.g., 0x1234), what happens if I continuously write the same value (0x1234)? Will an error occur, or can the FMC recognize that the intended update is the same and skip the write?

Best Regards

Bolt

Bolt Hsieh said:

After a Flash Erase, if I write 0xFFFF (Can the FMC recognize that the updated value is the same as the erased state and skip the write?), can I later modify it to 0x0000?

No, you cannot, it will trigger an Ecc error.

Bolt Hsieh said:

If an address has already been programmed with a non-0xFFFF value (e.g., 0x1234), what happens if I continuously write the same value (0x1234)? Will an error occur, or can the FMC recognize that the intended update is the same and skip the write?

The ECC is calculated for 64-bit aligned address and the corresponding 64-bit data. Any data not supplied (within a given 64-bit aligned memory) is treated as 0xFFFF. So this scenaria can also trigger ECC error if you are not writing same value to all the corresponding address.

Regards,

Rajeshwary

Hi Rajeshwary,

Thanks for your resopnse.

If I always use the Fapi_issueProgrammingCommand() function with the Fapi_AutoEccGeneration method,

the Flash API program executes in Flash Bank0. The operation steps follow the Flash API description: Erase → Program → CheckFSM → GetFSMStatus → doVerify.

When executing the Flash API to update data in Flash, we mask other interrupt insertions and pause the Watchdog Timeout.

However, when I attempt to update the values within the address range 0x91000~0x9111F in Flash Bank1 Sector1, I occasionally find that after the update, the ECC values for this entire range are incorrect. Specifically, the 68 ECC values starting from 0x1082200 contain data but are incorrect.

In what scenarios could a Flash Program operation occasionally result in a mismatch between the written values and their ECC?

Best Regards

Bolt

Bolt Hsieh said:

In what scenarios could a Flash Program operation occasionally result in a mismatch between the written values and their ECC?

Are you trying to update same data or some different data? ECC values changes based on data values.

Regards,

Rajeshwary

Hi Rajeshwary,

Whenever I need to write new data, I first erase the entire sector. However, after writing the data to this sector and rebooting the F280049, it jumps to NMI_ISR. Upon investigation, it was identified as an ECC mismatch across the entire region.

When using the AutoECC Flash operation method, I am unable to reproduce the issue where the entire range (0x91000~0x9111F) is written incorrectly. At most, I observe up to 12 words of errors, after which the FMC state machine or data verification process detects an error and reports it.

The operation steps follow the Flash API description: Erase → Program → CheckFSM → GetFSMStatus → doVerify.

Therefore, I would like to ask: follow the upon describtion of flash API step,  under what circumstances could an entire region be written incorrectly without triggering an error during the writing process?

Best Regards

Bolt

Bolt Hsieh said:

At most, I observe up to 12 words of errors, after which the FMC state machine or data verification process detects an error and reports it.

Does it fails during doVerify after 12words?

Regards,

Rajeshwary

Hi Rajeshwary,

I am currently encountering an issue where, after using the Flash API from Flash Bank0 to write to a specific sector in Flash Bank1, a power cycle occasionally results in an ECC verification failure for the entire written address range of that sector.
However, the writing procedure follows the correct steps as specified in the Flash API.

I am unable to consistently reproduce the issue where the ECC verification fails for the entire flash sector.
Using the special write method below, I can only get up to 12 words to fail writing before further writes become impossible.

Test Steps:

1. Use AutoEcc to write 4 words of 0xFFFF.
2. Use DataOnly to write another 4 words (e.g., 0x1234) without executing Fapi_doVerify().
3. Repeat steps 1 and 2 four times.
4. After the fourth iteration of step 2, the FMC state machine check fails. As a result, I can write only 12 words that do not match ECC before encountering an issue.

Question:

Following the correct Flash API steps, under what circumstances could an entire region be written incorrectly without triggering an error during the writing process?

Best Regards

Bolt

Hi,

Normally, SECDED-single errors are corrected and double errors are detected by the FSM that triggers ECC errors.

Regards,

Rajeshwary