Accessing UUID on LPC55S69

[scottm]

I'm having trouble figuring out how to properly access the UUID on the LPC55S69. The MCUX SDK documentation seems woefully incomplete.

Most sources suggest that the way to access it is with FFR_GetUUID(). The "IAP_FFR Driver" has absolutely no explanation - as far as I can tell, it's not documented anywhere what FFR even stands for. Is it the same as "PFR"? If so, why isn't it explained somewhere? Does FFR_Init() need to be called? Why does FFR_Init() have no documentation?

If I try to use FLASH_Init() in my application, I get a hardfault. The only difference I can see between my code and the IAP example provided is that the example is running from the 96 MHz FRO. It looks like there may be some undocumented dependency there - FLASH_Init() is hardcoded to set the frequency to 96 MHz:

/* Initialize the clock to 96MHz */
config->modeConfig.sysFreqInMHz = (uint32_t)kSysToFlashFreq_defaultInMHz;

I can't verify this because modeConfig isn't documented - the entry in the manual is completely blank. The datasheet does say that flash erase/read/program isn't available at > 100 MHz. Does that apply to the UUID as well? Do I need to start up with a different clock configuration to be able to read it?

The datasheet also says that the UUID is accessible starting at address 0x9fc70. Is it safe to access it directly? Is the location different across different silicon versions?

Thanks,

Scott

[Xu_Zhang]

Hello scottm,

    I ran some tests that I hope will help you. I get the UUID by modifying the “flashiap1” demo.

Xu_Zhang_4-1683281815995.png

It is recommended that you use FFR_GetUUID() to access UUID. You need to complete FLASH_Init() first.

The FFR_GetUUID() and FFR_Init() instructions can be found in the “fsl_iap_ffr.h” driver.

Xu_Zhang_5-1683281816012.png

Xu_Zhang_6-1683281816034.png

 Access to UUID requires a call to FFR_Init()

If the system clock is greater than 100mhz, FLASH_Init() is faulty. If the system clock is greater than 100mhz, the flash erase/read/program is unavailable and the UUID cannot be read.

According to the Datasheet, the CPU cannot be higher than 100M for flash to run

Xu_Zhang_7-1683281816113.png

The UUID cannot be read directly. Since this address is protected flash region, FFR_GetUUID() is recommended.

I have put the modified program in the attachment

[scottm]

I've moved FLASH_Init(), FFR_Init(), and FFR_GetUUID() before my clock initialization so the UUID can be copied out to RAM and that seems to work. That leaves me with some questions:

Is it necessary to de-initialize anything prior to switching to the 150 MHz clock?

What does FFR stand for and where is it documented?

What is meant by section 48.8 in the manual where it says a UUID can be read from PFR registers at 0x0009_fc70? Is this the same UUID referenced by FFR_GetUUID()?

The UUID I'm pulling from the board on my desk says it's version 1, variant 1 which means the low 48 bits should be the MAC address of the generating system. Is that true of these UUIDs? What I'm specifically after is which bits can be guaranteed to change from one device to another.

Thanks,

Scott

[Xu_Zhang]

1."Is it necessary to de-initialize anything prior to switching to the 150 MHz clock?" ->>Yes.

 2.For FFR, you can check PFR in the manual. FFR and PFR are the same.

 3"Is this the same UUID referenced by FFR_GetUUID()?" ->> Yes, the same.

1. The UUID is the unique number of the chip. This number does not indicate the significance of special attention.

[scottm]

What does "FFR" stand for? Where is the term defined and how would one know it's the same as "PFR"?

And how does one go about de-initializing it to make the system safe to switch to 150 MHz? There's no documentation as to what the FFR_Init() function actually does and there's no de-init function listed.

[Xu_Zhang]

1. FFR is a way of naming the PFR API, and PFR is "Protected Flash Region".

2. You can view the description of the FFR_Init() function in the manual, the source code is not open.

图片1.png

3. use FFR_Lock_All() instead of FFR_Deinit(), the same function.图片2.png图片3.png

[scottm]

1. FFR is a way of naming the PFR API, and PFR is "Protected Flash Region".

Why does it have a different name? Why isn't it explained anywhere that "FFR" is the same as "PFR"? The files include no identification information beyond their copyright dates and license identifier. Neither "PFR" nor "FFR" appear in the list of abbreviations in the manual.

There is no "ffr_deinit()" function provided by fsl_iap_ffr.h. How would one determine that "FFR_Lock_All()" is the same function as the "ffr_deinit()" described in the manual, short of tracing through the driver code to determine its order in the jump table like I just did?

What is it that ffr_deinit() does that's necessary for switching to 150 MHz? The manual seems to say that it locks flash access until a POR or BOD reset. If I'm reading that correctly, then I wouldn't be able to launch my bootloader later for firmware updates. What is the accepted procedure for reading the UUID when the system is going to be operating > 100 MHz, without locking out flash write access later on? What's the procedure for re-initializing it at a lower speed for the bootloader?

Scott

[Alice_Yang]

Hello @scottm 

If there are Flash operations(erase, blank check, program) and reading single word, recommend CPU frequency not above 100MHZ. If you must use 150MHZ after reading flash, recommend disable modules clocks before change to 150MHZ ,( for example if you used UART in your code, disable it by "USART_Deinit()"). Then enable (re-initialize) it again after changed to 150MHZ. About re-initialize process, please refer to the Initialize code in your project, meaning initialize (enable) again.

For the name "FFR" & "PFR", we have reported to doc team.

BR

Alice

[danielholala]

For the name "FFR" & "PFR", we have reported to doc team.

Obviously, that request did not reach the doc team as the same issue applies to the LPC553x reference manual: no explanation what the abbreviation "FFR" means. Maybe that's an acronym for "flash firewall region"?

Further confusion is created by defining "PFR" as "Protected Flash Area":

danielholala_0-1753884660724.png

and no information what these different flash regions are used for.

I have to agree with @scottm , the SDK documentation could definitely be improved. I would be grateful if you would start with NOT using ambiguous acronyms or different terms for the same entity and also giving some context if you introduce a new functionality.

[scottm]

My own personal guess is that "FFR" is either "factory flash region" or "Freescale flash region". They went and renamed some stuff after the NXP merger. They don't seem to have good internal coordination on these things.

The inconsistent naming in the SDK really drives me nuts. There's an 'lptimer' peripheral that's a Kinetis low-power timer, but other places 'lp' is (apparently) used as a prefix to distinguish LPC peripherals - like 'lpadc' isn't a low-power ADC, but rather an LPC ADC, which has a different API from the 'adc' that was already present in the Kinetis SDK.

One of my favorites was the section on the C90TFS Flash Driver. "C90TFS" is define nowhere. Apparently it's an internal designation for a proprietary 90nm thin film storage.

Scott

[scottm]

I'm not sure I follow. All I need to do is to be able to access the UUID and leave the flash in a state where my IAP bootloader can access it later if needed.

I'm able to read the UUID at startup, before switching to PLL0 @ 150 MHz. Nothing seems to be affected after the UUID has been read and the clock source changed. No other peripherals are initialized before changing clocks.

Are you saying there is something that needs to be de-initialized? Or is it safe to run like that as long as the clock is switched back to the FRO96 before the bootloader makes any flash API calls?

Thanks,

Scott

[Alice_Yang]

Hello @scottm 

"I'm able to read the UUID at startup, before switching to PLL0 @ 150 MHz. Nothing seems to be affected after the UUID has been read and the clock source changed. No other peripherals are initialized before changing clocks."

->>If it doesn't make any issue, you don't have to re-initialize.  Then you just need confirm CPU clock is not above to 100HZ when reading UUID.

BR

Alice