FXLC95000 how to enable erasing and programming via MailBox Tool v1.1?

cancel
Showing results for 
Search instead for 
Did you mean: 

FXLC95000 how to enable erasing and programming via MailBox Tool v1.1?

Jump to solution
778 Views
vitaliysiplichu
Contributor III

Hello!
I work with MailBox Tool v1.1. After several attempt to programm FXLC95000 with "MyProject.elf.S19" I have an error when I try to erase:

**** Flash erase failed.

  Error code 2: Flash is protected, FOPT[PROTB]=0

 

And I have an error when I try to programm:

**** Flash erase failed.

  Error code 4: Program/erase operation failed because expected values do not match

 

So my question is:
How can I enable erasing and programming via MailBox Tool v1.1? What command should I send to make it?

Can anyone help me with described steps to do?

Labels (1)
0 Kudos
1 Solution
256 Views
jimmcglasson
Contributor III

Vitaliy,

What I am assuming has happened is that you programmed a binary image that included writes to the FOPT register at 0x1FFFE.

The value written by that executable into FOPT included the FOPT_PROTB bit set to 0.

It may have also included the FOPT_BF bit (Boot to Flash) set to 1 which causes the part to immediately boot and begin executing your executable instead of the built-in ROM Command Interpreter (CI).

The mailbox tool uses the ROM command interpreter on the FXLC95000 to perform program/erase operations.  When the FOPT_BF is set to 1, the ROM CI no longer executes after boot, and the mailbox can no longer use the ROM CI to perform these operations.

It is recommended that:

1. any executable that sets the FOPT_BF bit also provides a command that can be sent to it to tell it to rewrite the FOPT so that the part will again boot to ROM at the next power cycle.

2. For typical development and debug use of a debug probe such as the P&E Multilink be used rather than relying on the flash capability IN THE Mailbox Tool.  The multilink can be used to re-flash the part even when the FOPT setting would prevent it via the Mailbox Tool/ROM CI.

The code that  I typically use and add to my project to handle FOPT is:

(But remember that if you set the #if 0 to a 1 such that AUTO_BOOT_TO_FLASH is defined, then you must either use a multilink debugger or implement a command that, when sent, rewrites FOPT back to boot to ROM.)

#if 0

#define AUTO_BOOT_TO_FLASH

/* The downside to this is that the only way to get the part back into ROM CI mode is to reflash a new image with NVOPT[5]

* set- for example by turning this macro back off and reloading using the BDM connection in CodeWarrior.

*/

#endif

#ifdef AUTO_BOOT_TO_FLASH

/* Set Flash Options to enable boot from Flash

* The value at address 0x1FFFE (NVOPT, the last location in Flash memory) is used to initialize the hardware FOPT register

* at bootup by the boot ROM. (See the FXLC95000 Hardware Reference Manual for details of the control register).

* In brief, when the BF bit (bit 13) is set in FOPT, the ROM CI will transition execution to the program stored in

* flash memory after the boot sequence is complete.  When the bit is clear, the ROM code will continue to execute after the initial

* power-up initialization has be completed and the ROM Command Interpreter will be available to execute commands as defined in the

* Hardware Reference Manual.

* Note: The tricky part is that the value placed by the boot ROM into FOPT is the inverse of the bit[5] of the byte at

*      location 0x1FFFE so setting bit[5] in NVOPT results in FOPT[BF/13] = 0- which means boot to ROM.

* If the NVOPT is configured to remain in the ROM CI at boot, the flash image can be executed by sending a

*      0x29 0x00 0xFF 0xFF 0xFF 0xFF to the ROM command interpreter.

* This can be sent anytime the ROM CI is active and there is a valid image programmed in flash.

*

*/

uint32 flash_opt @0x1FFFE = //FOPT_BF_MASK  | // Not ORing the mask leaves the bit unset in NVOPT which means: boot to flash

                            FOPT_CHECKB_MASK | // Do not perform Flash CRC

                            FOPT_PW_MASK    | // PROTB writable

                            FOPT_PROTB_MASK  | // Flash Array NOT protected

                            FOPT_SSW_MASK    | // Security State Writable

                            FOPT_SSC_MASK;    // Security State = Unsecured

#else

/* Stay in ROM CI mode after power-up */

uint32 flash_opt @0x1FFFC = 0xFFFFFFFF;  // Boot to ROM CI

#endif

View solution in original post

0 Kudos
1 Reply
257 Views
jimmcglasson
Contributor III

Vitaliy,

What I am assuming has happened is that you programmed a binary image that included writes to the FOPT register at 0x1FFFE.

The value written by that executable into FOPT included the FOPT_PROTB bit set to 0.

It may have also included the FOPT_BF bit (Boot to Flash) set to 1 which causes the part to immediately boot and begin executing your executable instead of the built-in ROM Command Interpreter (CI).

The mailbox tool uses the ROM command interpreter on the FXLC95000 to perform program/erase operations.  When the FOPT_BF is set to 1, the ROM CI no longer executes after boot, and the mailbox can no longer use the ROM CI to perform these operations.

It is recommended that:

1. any executable that sets the FOPT_BF bit also provides a command that can be sent to it to tell it to rewrite the FOPT so that the part will again boot to ROM at the next power cycle.

2. For typical development and debug use of a debug probe such as the P&E Multilink be used rather than relying on the flash capability IN THE Mailbox Tool.  The multilink can be used to re-flash the part even when the FOPT setting would prevent it via the Mailbox Tool/ROM CI.

The code that  I typically use and add to my project to handle FOPT is:

(But remember that if you set the #if 0 to a 1 such that AUTO_BOOT_TO_FLASH is defined, then you must either use a multilink debugger or implement a command that, when sent, rewrites FOPT back to boot to ROM.)

#if 0

#define AUTO_BOOT_TO_FLASH

/* The downside to this is that the only way to get the part back into ROM CI mode is to reflash a new image with NVOPT[5]

* set- for example by turning this macro back off and reloading using the BDM connection in CodeWarrior.

*/

#endif

#ifdef AUTO_BOOT_TO_FLASH

/* Set Flash Options to enable boot from Flash

* The value at address 0x1FFFE (NVOPT, the last location in Flash memory) is used to initialize the hardware FOPT register

* at bootup by the boot ROM. (See the FXLC95000 Hardware Reference Manual for details of the control register).

* In brief, when the BF bit (bit 13) is set in FOPT, the ROM CI will transition execution to the program stored in

* flash memory after the boot sequence is complete.  When the bit is clear, the ROM code will continue to execute after the initial

* power-up initialization has be completed and the ROM Command Interpreter will be available to execute commands as defined in the

* Hardware Reference Manual.

* Note: The tricky part is that the value placed by the boot ROM into FOPT is the inverse of the bit[5] of the byte at

*      location 0x1FFFE so setting bit[5] in NVOPT results in FOPT[BF/13] = 0- which means boot to ROM.

* If the NVOPT is configured to remain in the ROM CI at boot, the flash image can be executed by sending a

*      0x29 0x00 0xFF 0xFF 0xFF 0xFF to the ROM command interpreter.

* This can be sent anytime the ROM CI is active and there is a valid image programmed in flash.

*

*/

uint32 flash_opt @0x1FFFE = //FOPT_BF_MASK  | // Not ORing the mask leaves the bit unset in NVOPT which means: boot to flash

                            FOPT_CHECKB_MASK | // Do not perform Flash CRC

                            FOPT_PW_MASK    | // PROTB writable

                            FOPT_PROTB_MASK  | // Flash Array NOT protected

                            FOPT_SSW_MASK    | // Security State Writable

                            FOPT_SSC_MASK;    // Security State = Unsecured

#else

/* Stay in ROM CI mode after power-up */

uint32 flash_opt @0x1FFFC = 0xFFFFFFFF;  // Boot to ROM CI

#endif

View solution in original post

0 Kudos