Copyright notice
This blog is owned by okman automotive electronics. Please indicate the source for reprint. Okman automotive electronics is committed to the development and design of Renesas MCU and surrounding related products.
email: 1256153255@qq.com
website for get Renesas RH850F1x development board and Renesas E1 simulator

Serious friends will find that my last blog post Introduction to usage of Renesas RH850 FCL Library Based on IAR for RH850 Finally, a bug is left, that is, when FCL executes ERASE or WRITE, the returned status is myrequest status_ ENU is often 0x00000005 (R_FCL_ERR_PROTECTION). The last solution given in the last blog is to perform Chip ERASE through RFP. However, after this ERASE, FCL WRITE can only be executed normally once, and R_FCL_ERR_PROTECTION will appear the second time.

Analyze the occurrence of R in the official FCL manual_ FCL_ ERR_ The reasons for protection are as follows

The official reason is that the security setting (security Flag) is enabled, resulting in Code Flash Protection. The solution is to Disable the security setting.
How to Disable? Keep looking in the manual and find here

That means macro R_FCL_SUPPORT_SECURITYFLAGS is responsible for enabling and disabling security settings. That's easy to do. Put r in the code_ FCL_ SUPPORT_ Just comment out the securityflags. The result is still not finished after annotation, still R_FCL_ERR_PROTECTION.

Then try other areas, as modified below

/* erase block 2 and 3 */
    myRequest.command_enu = R_FCL_CMD_ERASE;
    myRequest.idx_u32     = 0x2;                   /* erased range = 0x4000 to 0x7fff */
    myRequest.cnt_u16     = 1;
    R_FCL_Execute (&myRequest);
    #if R_FCL_COMMAND_EXECUTION_MODE == R_FCL_HANDLER_CALL_USER
        while (R_FCL_BUSY == myRequest.status_enu)
        {
            R_FCL_Handler ();
        }
    #endif
    test_value = myRequest.status_enu;

    /* write 512 bytes to address 0x40000 (start of block 2) */
    REINITIALIZE_BUFFER;
    myRequest.command_enu = R_FCL_CMD_WRITE;
    myRequest.bufferAdd_u32 = (uint32_t)&writeBuffer_u08[0];
    myRequest.idx_u32       = 0x4000;
    myRequest.cnt_u16       = 1;                    /* written bytes = 256 * cnt_u16 */
    R_FCL_Execute (&myRequest);
    #if R_FCL_COMMAND_EXECUTION_MODE == R_FCL_HANDLER_CALL_USER
        while (R_FCL_BUSY == myRequest.status_enu)
        {
            R_FCL_Handler ();
        }
    #endif
    test_value = myRequest.idx_u32;

↓↓↓↓↓↓↓↓↓

/* erase block 2 and 3 */
    myRequest.command_enu = R_FCL_CMD_ERASE;
    myRequest.idx_u32     = 0x3;                   /* erased range = 0x4000 to 0x7fff */
    myRequest.cnt_u16     = 1;
    R_FCL_Execute (&myRequest);
    #if R_FCL_COMMAND_EXECUTION_MODE == R_FCL_HANDLER_CALL_USER
        while (R_FCL_BUSY == myRequest.status_enu)
        {
            R_FCL_Handler ();
        }
    #endif
    test_value = myRequest.status_enu;

    /* write 512 bytes to address 0x40000 (start of block 2) */
    REINITIALIZE_BUFFER;
    myRequest.command_enu = R_FCL_CMD_WRITE;
    myRequest.bufferAdd_u32 = (uint32_t)&writeBuffer_u08[0];
    myRequest.idx_u32       = 0x6000;
    myRequest.cnt_u16       = 1;                    /* written bytes = 256 * cnt_u16 */
    R_FCL_Execute (&myRequest);
    #if R_FCL_COMMAND_EXECUTION_MODE == R_FCL_HANDLER_CALL_USER
        while (R_FCL_BUSY == myRequest.status_enu)
        {
            R_FCL_Handler ();
        }
    #endif
    test_value = myRequest.idx_u32;

It's OK. Try other block s in the back, too
That's why Block2 can't play like this. Why? Is it Block2 or Code that cannot be erased? Check map file

  11 638 bytes of readonly  code memory
      50 bytes of readonly  data memory
  41 116 bytes of readwrite data memory

The Code volume occupies 11638 bytes, and Block 0 and block 1 occupy a total of 16KB, which is enough.

No way!!!

Then read out the whole 1M Code Flash with RFP and find the problem

S0110000437265617465642062792052465033
S31500000000E0022C2C000000000000000000000000B0
S315000000101F00E0027E2D000000000000000000002E
S31500000020EE0F4000C10E1F001F00E0027E2D0000F3
S31500000030EE0F4000C10E0F001F00E002662D00000B
. . . . . . . . 
S31500002D7050000000000000008207610006E863EFD3
S31500002D8001000338013280FF0600A5FD7F00000028
S31500002D90850500008505000085050000E00748015F
S31500002DA041000000410000004100FFFFFFFFFFFF60
S31500002DB0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1D
S31500002DC0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0D
S31500002DD0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD

From this paragraph, it is right that the code is placed in Block0 and Block1.

But, further down

S31500003FD0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEB
S31500003FE0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDB
S31500003FF0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCB
S31500004000000800000241000008000240000104040C
S31500004010000000002004000008020A080100080A47
S315000040200400820000000000008000000000060678
S31500004030000000220000000008000A08100400002A
. . . . . . . . 
S31500005FD000000000000000000000000000000000BB
S31500005FE000000000000000000000000000000000AB
S31500005FF0000000000000000000000000000000009B
S31500006000000102030405060708090A0B0C0D0E0F12
S31500006010101112131415161718191A1B1C1D1E1F02
S31500006020202122232425262728292A2B2C2D2E2FF2

No, Block2 (0x0000 4000~0x0000 5FFF) is not in ERASE state, so it cannot be written.
The start of Block3 (0x0000 6000) is the value we just wrote. Now you see, it turns out that Block2 is not in ERASE state.

But there are two more questions:
1. What is the data in Block2?
2. The common instruction in FCL executes r on Block2_ FCL_ CMD_ ERASE, why not normal ERASE?

The reasons for these two problems have not been found. After finding them, share them with you. If any friends know, please leave a message to me for literacy.