flash profiling

Correcting my first mistake and setting the PLLTCTL1 to 0x00077700 doesn't help.

Actually got it working. It seems the HCLK divider is set to one so I have to adapt PLL settings accordingly. Would appreciate some information on the parameters collected though.

Mathieu

Hi Mathieu,
This is a rather new CCS feature. I will forward your question to our SME who is familiar with the flash profiling.

Thanks Charles.

I am very interested in understanding the parameters that are reported by the profiling test.

Mathieu

Hi Mathieu,
Are you using bootloader in your application?

I think the flash profiling is useful if you use a non-CCS tool to download your application. For example, if you have a bootloader you would download/update your application by running the Flash API. Sometime an incorrect use of the Flash API can adversely affect the qualify of the program image being programmed to the flash. The flash profiling allows you to profile the quality of the programming vs. how it would have been programmed by using CCS.

Below will be the validation steps:

1. Erase and program data into each device using the tool to be validated.
2. Erase and program data into each device using the tool to be validated again to ensure both the
erase and program were performed. The reason to repeat step 2 for one extra erase/program cycle is because the parts that are shipped to the customers are blank. The step 1 will not go through an erase cycle since it is already an erased part.
3. Profile each device.
4. Erase and program the same data into each device using CCS and the same settings as the previous
tool. So when you asked what parameters to use, you will put in the same parameters you used to program the application in the tool to be validated (i.e. the parameters like the frequency, wait states you used in your bootloader to run the flash API commands). If different settings are used, this could skew the data causing the results to fall outside the limits.
5. Profile each device.
6. Validate whether the average measured Vt (voltage threashold) and Bcc (Bit cell current) values are achieved using the tool to be validated, are within the limits of the average values achieved using the CCS tool.

Hello Charles,

I was aware of the text you quote.

I am not designing nor validating a bootloader application. We are currently investigating a complex issue and part of this investigation is focusing on the flash memory. Therefore I am trying to have good picture of the flash memory health and the quality of programming/erasing cycles. Hence I would really appreciate a quick description of the parameters reporting during the flash memory profile tests. I kind of guess what the Vt measurement means, but I am still struggling to understand the VTrefPV and VTrefRV parameters as well as the BCC measurements. Let me know if you can provide me this information. 

Mathieu

Hello Bob,

Thanks for this detailed information, looking forward for more :-)! 

Is there any thresholds for detecting over programmed bits? 

Mathieu

Also,

Is the memory erased during the flash memory profiling operations? The original contents are restored at the end of tests, but it looks like a lot of stuff is happening during the test, potentially including memory erasing and reprogramming.

Mathieu

Hello Mathieu,
Would you please check the date of the *.nfl files in the directory "C:\ti\ccsv6\ccs_base\hercules\flash\libraries". I think there are some errors in the reference values reported in the released version of the files (4/17/2015). I will checkout some beta files to see if those problems have been fixed.

All F021* files are dated from the 4/17/2015.
May it also be the reason for the null values of BccRefRV and BccRefRI?

OK, I am checking out some beta files now.

In regards to your earlier question, the profile operation should not erase the flash, but if you choose "Perform Full Validation", it will. While the Vts and BCCs will vary from device to device because of process variation, on a single device they should be pretty consistent from one programming cycle to the next. The purpose of the validation is to show that a customer implemented algorithm programs and erase the flash the same way as TI does using Code Composer. For example, if you write a boot loader and want to verify that it programs and erases properly, you use the boot loader to erase then program some sectors. You select those sectors in CCS and then perform the validation. CCS will first profile the sectors chosen, then erase, reprogram and re-profile the sectors. Then it will compare the first and second profiles to see if the extremes and means are within limits defined by TI.

Hello Bob,

Any updates on this point?

Mathieu