RX65N Flash Access Window (FAW) register questions ?

Our project hit an issue with the Flash Access Window (FAW) register in Option-Setting Memory, and I'm confused about its operation.

The 32-bit FAW register contains two bitfields which describe the start (FAW.FAWS) and end (FAW.FAWE) addresses of a window of flash ROM, outside of which destructive operations such as writes and erases are forbidden.

  • When/how is this access policy enforced (enabled)?
  • How do we disable this access policy (i.e. allow all access to flash)?
  • On a new board, we read 0xFFFFFFFF from the register; Can we set the FAW to this value to disable the access policy?

Also in the FAW register are two bit flags - Access Window Protection (FAW.FSPR) and Start-up Area Select (FAW.BTFLG).  I am confused about FAW.FSPR, whose description in the datasheet says a value of 1 = Without protection and 0 = With protection.  With the FAW.FSPR set to 1 and valid addresses in FAW.FAWS and FAW.FAWE, we see failures to write/erase outside the defined region.

  • What does FAW.FSPR do exactly?  Does it enable/disable the FAW access policy?
  • What does "1 = Without protection" mean?
  • Why is writing a 0 to this bit immutable?

I'll try to respond promptly to any replies.  Thanks in advance!

Top Replies

  • Okay I think I understand the FAW.FSPR bit now - it essentially locks down the FAW register, preventing any future changes.  That suggests the FAW register is used to partition (code?) flash into two regions - writable and read-only.  So a user can define a read-only region in code flash (e.g. a bootloader), set the FAW register to allow writes to code flash outside the bootloader area, and lock the FAW with the FAW.FSPR bit.

    Anyone have corrections to my understanding?

    I also still need clarification on how to enable writes to all code flash; my assumption is FAW.FAWS = FAW.FAWE = 0xFFF is magic and allows such writes.

  • Hi AnthonyJenkins,

    How's your issue regarding the FAW register operation? Were you able to figure out the answers to your questions now? I'm not familiar with this register and can't find other documentation about it except on what's in the hardware user's manual. I hope you can still wait for others to answer your questions.

    RenesasRulz Forum Moderator


  • Hi JB,

    Thanks for checking - nothing new learned so far. We have a number of possible solutions based on our limited understanding of the register.

    Anthony Jenkins
  • Hi AnthonyJenkins,
    I am also very interested on how this FAW register works. Unfortunately, I have not found any documentation that explains this register behaviour. I have obtained the same results to write all code flash (FAW.FAWS = FAW.FAWE = 0xFFF ) but I don´t know why.

    I have also tried to configure some specific block (for example: FAW.FAWS = 004 and FAW.FAWE = 0xFF7 ) to protect the rest of blocks but it has not work as expected.

    I hope someone could help us to understand how this register works.
  • I learn this FAW on the Synergy MCU. The description in the manual e.g. S5D9 is clearer.

    fpsr bit is used to lock down FAW setting.  Once set to 0, it is not reversible.  So use with caution!

  • Thanks ,

    Yes I saw this chapter in the RX flash programming manual; the behavior of the FAW.FSPR bit matches my understanding.

    The Figure 7.2 documentation regarding FAWS/FAWE clarifies my understanding about when the window is enforced.  FAWS == FAWE disables the access window (all destructive accesses are allowed), FAWS > FAWE makes the access window 0-length (no destructive accesses are allowed), FAWS < FAWE is normal window access (finite region of MCU code flash allows destructive accesses).

    I don't think there's a way to set the last (highest) block of code flash as being accessible (within a finite window).  FAWEmax = 0x7FF, which points to the last block of code flash at 0xFFFFE000.  The block pointed to by FAWE is the highest protected block.  So there's no way to include the last block in a writable access window.  That may be by design, to protect the boot vector at 0xFFFFFFFC and vector tables.

    The high bit (bit 11) of the FAWS and FAWE bitfields is confusing; FAWS:11 apparently should always be set to 0, but FAWE:11 should be set to 1 if trying to define an access window whose end is 0x00000000.  Maybe this is how one includes the last block of code flash in the access window; FAWEmax = 0x800 would be greater than FAWS, defining a valid window.

  • I am also working on memory protection. Although our product is in development phase. 

    From above discussion I am assuming, if I set FAW.FSPR = 0, I won't be able to reprogram the chip forever, and there would be no way recover. Even if I use e2 lite debugger with Renesas Flash programmer, for erasing the entire flash

    Is my assumption correct guys ?

  • You can no longer change the flash access window.  You can still program whatever blocks that are inside the access window.  

    Erase chip will fail as those blocks outside the window cannot be erased. 

    If you set the window such that FAWE[10:0] < FAWS[10:0]  You cannot erase/program any block.

  • that's exactly what I was looking for.