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.
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.
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.
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.
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.
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.
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.
Hi Earl-san,
thank you for your detailed explanation. I have understood.
Best regards,
Yasuhiko Koumoto.