RM57L843: FLASH Bank 7 Does Not Erase Correctly

stomp said:

I would expect the FLASH to erase to 0xFFFFFFFF even in the instance that ECC is enabled

The thread Why my RM57L843 can't be erased by clearly? seems to explain that that isn't the case.

After the erase, what happens if you attempt to then program the 0xFFFFFFFF value along with a valid ECC?

Thanks,

I did read this and I don't think its exactly the same as the situation I am seeing.

After erase, lets just assume I program 0xF0200000 with 0xAAAA5555 I would expect to see some of the bits change from a 1 to 0. This is not the case, the memory does not change.

I am not explicitly programming a valid ECC, I am only assuming the F021 API does this on RM57. I will have to check.

Thanks again.

stomp said:

After erase, lets just assume I program 0xF0200000 with 0xAAAA5555 I would expect to see some of the bits change from a 1 to 0. This is not the case, the memory does not change.

By default when a HALCoGen project is created the cache is enabled and the MPU region for the flash is set to type NORMAL_OIWTNOWA_NONSHARED "Memory type normal outer and inner-write-through, no write allocate and non-shared".

The CPU might have therefore cached the erased flash values - see CCS/TMS570LC4357: Issue in Flash programming using F021 Flash library

[I haven't tested this myself]

Hi Chester,

I changed the MPU to NORMAL_OIWTNOWA_NONSHARED, and there was some difference. I did not try the cache flush approach yet.

I am still having a really hard time using the same F021 routines that write to Bank 7 successfully on RM48. Given its the same F021 it should work the same.

Does TI have an example on RM57 using F021 API to read and write an array from any sector in Bank 7 without cache or ECC problems?

Thanks
Stomp!

Hi Stomp,

I am forwarding your post to some of our F021 and FEE experts. They should be able to assist shortly.

Hi Stomp

I will see if I can write a simple example. Before that I want to clarify few things.

1) What is the wait State configured for Bank7.

2) After Erase you mention that few locations read 0xFFFFF7F. If you disable ECC did you still read the same?

3) You mentioned that after Erase, you performed Blank check. Did Blank check pass.To confirm that your erase was successful you can perform Read Margin1 Test.

Hi,

Thanks very much for your help.

We are on RM57L843.

1. 3 Wait states

2. To my knowledge ECC can't be disabled from RM57's FLASH.  If this is wrong please advise.

3. To do a blank check I use my own algo (which looks for 0xFFFFFFFF) and obviously does not work due to the ECC. I also use the Fapi_doBlankCheck() function, which can't work due to the ECC limitation.

I'm not sure what you mean by Read Margin1 test. Do you have a link to that?

I think the trouble I am having is related to a few things.

1. Cache. Often after I reset the device I see *SOME* of my programmed memory there, sometimes the memory contents are duplicated in adjacent memory addresses.

2. ECC.

3. Something else quite random. I notice that if I set Fapi_setActiveFlashBank(7); and then while(Fapi_checkFsmForReady() == Fapi_Status_FsmBusy); The while loop may never exit in about 3/10 program runs.

My process is like this:

1. Load the entire Bank1 Sector 1 into RAM using a basic for loop copy.
2. Modify a part of the array
3. Re-Write the array to FLASH:
   1. Fapi_setActiveFlashBank()
   2. Fapi_checkFsmForReady() 
   3. Fapi_enableEepromBankSectors()
   4. Fapi_checkFsmForReady()
   5. Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector...)
   6. Check that sector is erased
   7. Fapi_checkFsmForReady()
   8. Fapi_issueProgrammingCommand(..., 16U, (Luint8*)0U, 0U, Fapi_AutoEccGeneration);
   9. Fapi_checkFsmForReady()

I don't think I am doing anything particularly wrong, as this works well on RM48.

Thanks

Stomp!

Good information thanks!
Can you please let me know what version F021 Flash API you are currently using?
Is it 02.01.01?

Hi,

I forgot the most vital bit of information.

I have tested against both 02.00.01 and 02.01.01 versions of the F021 API.

Both versions work on RM48 LE, both versions do not work on RM57 LE.

Thanks.

Hi Stomp,

I noticed that you stated you are using 3 WS for FEE accesses. Note that FEE is a different bank type on the RM57 and requires a higher number of WS and is dependent on the frequency of HCLK. Assuming you are configuring HCLK to it's maximum 150MHz, the WS configuration of FEE should be EWAIT = 8. But perhaps this is a confusion of terminology because the normal program Flash is RWAIT = 3 WS requirement. Note the difference in the register bit field names. EEPROM WS is set in EWAIT and normal Flash in RWAIT.

Thanks Chuck,

Just to clarify I have Bank 0,1 as 3WS and Bank7 as 9WS.

//Setup flash read Mode, address wait states and data wait states
flashWREG->FRDCNTL =  (Luint32)0x00000000U
				   | ((Luint32)3U << 8U)
				   |  (Luint32)3U;

//Setup flash access wait states for bank 7
FSM_WR_ENA_HL = 0x5U;
EEPROM_CONFIG_HL = (Luint32)0x00000002U
				 | ((Luint32)9U << 16U) ;


//Disable write access to flash state machine registers
FSM_WR_ENA_HL = 0x2U;

//Setup flash bank power modes
flashWREG->FBPWRMODE = (Luint32)0x00000000U

						/* Bank 7*/
						| ((Luint32)SYS_ACTIVE << 14U)
						 /* Bank 1*/
						| ((Luint32)SYS_ACTIVE << 2U)
						 /* Bank 0*/
						|  (Luint32)SYS_ACTIVE;

I should have been a bit more clear.

Regards

Stomp!.

Hi Stomp,

Sorry I forgot to ask.

What is the return value from the function Fapi_initializeFlashBanks(HCLK_FREQ);  Is it Fapi_Status_Success(0) or Fapi_Error_InvalidHclkValue(8)?

Make sure to proceed with any Flash operation only when Fapi_initializeFlashBanks returns zero (Fapi_Status_Success).

Hi,

On RM57 we have 150MHZ HCLK, 300MHZ GCLK and the rest of the clocks are 75MHZ, which the exception of the EMAC (VCLK4A_DIV) at 37.5MHZ.

Our code calls Fapi_initializeFlashBanks(150U);

And we check the status, which is always Fapi_Status_Success.  If it is not success,  our driver reports back.

We have also checked that Fapi_initializeFlashBanks(300U); returns with Fapi_Error_InvalidHclkValue to ensure the function is just not returning 0 without doing anything.

If its any help, I have also been digging through the HalCoGen supplied FEE driver.  We can't use this driver in our system due to compatibility with our upper layers, and also the verification effort needed.  But I did notice this:

FLASH_CONTROL_REGISTER->FrdCntl.FRDCNTRL_BITS.RWAIT = 0x3U;
FLASH_CONTROL_REGISTER->FsmWrEna.FSM_WR_ENA_BITS.WR_ENA = 0x5U;
FLASH_CONTROL_REGISTER->EepromConfig.EEPROM_CONFIG_BITS.EWAIT = 0x4U;
FLASH_CONTROL_REGISTER->FsmWrEna.FSM_WR_ENA_BITS.WR_ENA = 0x2U;

By default, the FEE driver also sets EEPROM wait to 4, not 8??

Thanks.!

Hi Stomp,

Please find an attached simple Bank7 Erase and program routines on RM57x Device.

0068.F021_Sample.zip

Hi,

Firstly thanks very much for the help yourself and others have provided thus far, its world class.

Your application works well, and differs from mine in only that I am erasing a sector, not the entire bank. Also the #defines you have for the bank sizes are a little off for the RM57 (0x2000 versus 0x1000).

By testing your application it gave me the ability to further define the problem I am seeing in my application. I am not able to reproduce the same results in your application, maybe simply due to the very small size of your app.

1. In CCS Debug Configuration -> FLASH settings, choose to erase Bank 7 Sector 1 during programming.
2. Download my firmware onto the RM57 and run it.
3. Read the entire B7S1 sector into a RAM array.
4. Modify some bytes in the RAM array.
5. Erase sector B7S1 and re-program the array, all Fapi commands return success.
6. In the memory watch window at a 0xF0200000 I can see that the FLASH contents HAVE NOT changed at this point.
7. Compare the RAM array to the FLASH array results in a compare failure, the FLASH was not programmed.
8. Restart the debugger, but do not run the app. Note the memory watch now shows a correctly programmed FLASH!!!

In all essence, it would appear that the FLASH does get programmed correctly, BUT I can not read it back again until after a restart, and the memory debug window does not always reflect the current state of the FLASH.

Is this simply a cache issue that I am seeing?

Thanks again
Stomp!.

Is this simply a cache issue that I am seeing?

Some options to find out if the cache is causing the issue:

1) After the Memory Watch window has shown the FLASH contents have NOT changed in the Cortex-R5 CPU context, try and view the same FLASH address in the Debug Access Port (DAP) context. This is because the DAP context reads the memory directory, bypassing the Cortex-R5 CPU cache. If FLASH as viewed by the Cortex-R5 CPU and DAP differ, it is a sign that the CPU has cached "stale" contents of the cache. See Manual launch for a link to accessing memory using the DAP.

2) In the HALCoGen PMU configuration for the FEE address space try changing the type to "DEVICE_SHAREABLE", to prevent the contents of the FEE from being cached:

Hi Stomp,

Let me confirm again. 
Your problem is, after programming Bank 7 you cannot see the data in memory Window, but after reset you can see it. Is that right? 

I did a similar experiment as yours reading BANK7-sector0 and store data, erase Bank7 - Sector 0, and write with new set of data. It works fine and I am able to see the new data in the memory window, able to read it through code. 

For my code MPU Type for Bank 7 is NORMAL_OINC_NONSHARED. ( This is Non-Cacheable configuration).

Only point to note is for RM57x device F021 API - Blankcheck routine uses DiagMode7, which is not the case with RM48x devices.

Hi,

I think a simpler explanation:

"After Bank7 S1 is erased during programming and the application is first run, its not possible to program any data into the FLASH at B7, despite the all of the Fapi commands returning success".

The methods for determining if the FLASH was programmed correctly is to do a verify check (which fails) or to view the memory window (which shows the FLASH still in an erased state with ECC corrections visible).

After application reset, the FLASH works as expected.

Thanks.

Hi Stomp,

/cfs-file/__key/communityserver-discussions-components-files/312/6840.F021_5F00_Sample_5F00_v2.zip

I have attached HALCoGen + CCS project. Which does Bank7 erase, write and verify. 

There is two options running Blankcheck from RAM and Flash. This can be controlled by pre-processor macro RUN_FROM_RAM ( must change in Compiler and Linker option in ccs project properties) . 

For MPU setting please refer HALCoGen project that I attached. 

Note : I configured RAM to be non cacheable just to execute code from it. If running from Flash This setting is not needed. 

Hope this Helps.