- NXP Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- Wireless Connectivity
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- Vigiles
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
-
- Home
- :
- General Purpose Microcontrollers
- :
- Kinetis Microcontrollers
- :
- What does the remark mean for the write-through cache action to the flash region?
What does the remark mean for the write-through cache action to the flash region?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello all,
could anyone let
me know the meaning of the following remark which was found in the "Table 3-41. Cache regions" of the Kinetis "K70 Sub-Family Reference Manual"? Because of my poor English ability, I cannot understand it.
1. Cache write hits do not write-through to program flash or FlexNVM regions because flash writes require flash programming.
Does it mean that any write action will not happen when written to the program flash or FlexNVM regions?
Best regards,
Yasuhiko Koumoto.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The originally quoted table describes the memory regions, and the general interaction with the K70 memory cache, as from the generic ARM architecture. The 'note 1' is a reminder at this point that while the general ARM architecture might consider 'write hits' into the cache 'valid' for the noted memory regions, Kinetis does NOT honor them as operations that would lead to Program Flash alteration -- that process MUST be done thru Flash Programming (FTFE, chapter 30), and for 'pages' then also using the FlexRAM buffer. The fact that table 3-41 even MENTIONS 'write hits' implies that you COULD make write cycles to the FLASH-ROM space, and those WOULD update a copy in the cache (should it find a 'hit') -- which would, if not declared a 'hard fault', lead to very odd behavior where the self-modifying code might then work 'for a while' (as long as cache continues to hold the modified copy) and would 'quit sometime later' when that cache-line is 'taken over' for some other addressed-line.
In general, chapter 3 gives 'implementation information' for how the 'generic' Freescale function modules are instantiated in the part(s) named for this manual. The K70 is 'somewhat unique' in that it HAS a general-memory cache, more completely described in 28.3.3.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It means that 'regular write operations' are NOT the mechanism to program flash -- that is a whole 'special sequence' involving an access state machine and potentially the program-page-buffer-RAM.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Earl-san,
is it that write operation is performed but there is no influence to the flash?
I think it will be quite natural and I wonder why it will becomes the remark.
Are there any other meanings?
Best regards,
Yasuhiko Koumoto.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I"m not sure where you are going with this. Any attempt by code to 'write' to 'read only' flash is inherently a code-bug, and MAY end up with a hard-fault -- I haven't tried.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Earl-san,
sorry for your confusion. I understand well your mentioning.
However, I want just to know why the expression was taken instead of "any write to these regions are prohibited". Especially I want to know the meaning of the subject of the remark such as "cache write hits". Why "cache"? Why "hits"? I think the situation would be the same as the case of the no-cached or cache miss. So I think the remark may have special meaning.
Best regards,
Yasuhiko Koumoto.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The originally quoted table describes the memory regions, and the general interaction with the K70 memory cache, as from the generic ARM architecture. The 'note 1' is a reminder at this point that while the general ARM architecture might consider 'write hits' into the cache 'valid' for the noted memory regions, Kinetis does NOT honor them as operations that would lead to Program Flash alteration -- that process MUST be done thru Flash Programming (FTFE, chapter 30), and for 'pages' then also using the FlexRAM buffer. The fact that table 3-41 even MENTIONS 'write hits' implies that you COULD make write cycles to the FLASH-ROM space, and those WOULD update a copy in the cache (should it find a 'hit') -- which would, if not declared a 'hard fault', lead to very odd behavior where the self-modifying code might then work 'for a while' (as long as cache continues to hold the modified copy) and would 'quit sometime later' when that cache-line is 'taken over' for some other addressed-line.
In general, chapter 3 gives 'implementation information' for how the 'generic' Freescale function modules are instantiated in the part(s) named for this manual. The K70 is 'somewhat unique' in that it HAS a general-memory cache, more completely described in 28.3.3.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Earl-san,
thank you for your detailed explanation. I have understood.
Best regards,
Yasuhiko Koumoto.
