CW 10.0 beta 3 tries to load NVPROT_INIT and NVOPT_INIT into DEMOQE board

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

CW 10.0 beta 3 tries to load NVPROT_INIT and NVOPT_INIT into DEMOQE board

Jump to solution
1,994 Views
wdfarmer1
Contributor III

I'm attempting to load a simple C++ program into the DEMOQE board with the MCF51QE128 installed.  I've built the program using CW 10.0 beta 3 with Processor Expert.  Connection from my PC to the board is over USB via P&E Micro USB BDM Multilink hardware on the board.

//

Using CS 10.0 beta 3, I'm able to erase the uC flash and verify that it is blank, but when I attempt to load the program into flash, the load won't complete.  It fails because the load includes these two segments:

//

1.  Load 0xFF into address 0x40D (NVPROT_INIT)

//

2.  Load 0x7F into address 0x40F (NVOPT_INIT)

//

and the loader reports that the board signals "NOT READY" after that attempt.  The load aborts at that point, so the rest of my program never gets loaded.

//

What's happening?  Is the load failing because the flash considers these addresses protected?  (Perhaps it is trying to protect the USB bootloader already present in the flash.)  But if that's the case, why did my attempt to erase the flash succeed?

//

One idea I haven't yet tried:   would it help to change the Project properties so that under Processor Expert.pe / CPUs / MCF51CE128 , right-click Inspector, Build Options / Flash Registers Initialization , the setting is Disabled rather than Enabled?

Labels (1)
0 Kudos
1 Solution
513 Views
wdfarmer1
Contributor III

I didn't find the answer in Processor Expert, but 'following the problem report, I restricted the address range.

 

1.  Create a new Target Task, of Flash programming type, that does an Erase, Verify Blank, Program only 0x410 - 0x1FFFF, Verify only 0x410 - 0x1FFFF.

 

2.  Change the Debug configuration / Download to use that task instead of the standard download.

 

This gave me a valid load, and I was able to debug.

View solution in original post

0 Kudos
4 Replies
513 Views
wdfarmer1
Contributor III

Follow-up:  The release notes for CW 10.0 beta 3 include this known problem and workaround, which may be related:

 

=====

MTWX31779

Issue: MCU Flash Programmer does not provide the ability to protect sections of memory.

Workaround: Use Restrict address range to protect memory sections.

Ensure the sector that should be protected is outside the address range for

programming. The Flash programmer will write only in the specified area

=====

 

I haven't yet tried this.

0 Kudos
513 Views
BlackNight
NXP Employee
NXP Employee

Hello,

yes, this is exactly the issue, and as well the workaround. I had to disable the settings in Processor Expert.

 

BK

0 Kudos
514 Views
wdfarmer1
Contributor III

I didn't find the answer in Processor Expert, but 'following the problem report, I restricted the address range.

 

1.  Create a new Target Task, of Flash programming type, that does an Erase, Verify Blank, Program only 0x410 - 0x1FFFF, Verify only 0x410 - 0x1FFFF.

 

2.  Change the Debug configuration / Download to use that task instead of the standard download.

 

This gave me a valid load, and I was able to debug.

0 Kudos
513 Views
wdfarmer1
Contributor III

Follow-up:  I did find how to make the Processor Expert solution work.  Rather than creating a new Target Task with restricted addresses:

 

1.  Change the Project properties so that under Processor Expert.pe / CPUs / MCF51CE128 , right-click Inspector, Build Options / Flash Registers Initialization , the setting is Disabled rather than Enabled.

 

2.  Do a Project / Generate Code to generate a new "cpu.c" file that implements that setting; it won't contain these lines that the enabled version had:

 

=====

/* Initialization of the CPU registers in FLASH */

 

unsigned char NVPROT_INIT @0x0000040D = 0xFF;

 

unsigned char NVOPT_INIT @0x0000040F = 0x7F;

=====

 

0 Kudos