Secure Warning

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

Secure Warning

Jump to solution
1,742 Views
TomSkwara
Contributor III

After updating Codewarrior to the recent patch, I'm now receiving a warning message when trying to debug.

 

CodeWarrior Alert

 

The cuurent download operation attempts to modify the Flash Control Field (FCF).  Therefore, the target processor may become secured irreversibly.  This is often caused by an incorrect Linker Command File that does nor reserve the FCF address range from 0x400 to 0x40f.

 

Jeez, one cryptic issue after another...  After looking at the Linker Control File, I see no entry reserving this memory.  The LCF is part of the MQX 3.7 install that includes the TWRK60N512 BSP.  Is the stock BSP not adequate to deal with this isse?  If not, what are the recommended changes?

 

Is it me or does anyone else think that a CodeWarrior Technical Support package is required to do the basics, like creating a new MQX project with the included Wizard and compiling to debug?  This is a 101 step and should work cleanly right out of the gate...why is it like trying to dock an aircraft carrier?

0 Kudos
1 Solution
953 Views
jimtrudeau
Senior Contributor I

I've been in touch with the apps team. Relative to MQX demo or sample projects, this is a false alarm. If you see this dialog (image below) you are safe to click "No" and continue the flashing operation. There has been no change in the MQX linker files. They are safe and the processor will not be locked.

 

This warning results from a new check introduced in the latest CodeWarrior update. This problem will be corrected either in the next MQX RTOS update or a subsequent CodeWarrior update. The CodeWarrior tools now check to see if values are being written to addresses in the range 0x400 to 0x40f. However, it is the final four bytes of that range that must be 0xfffffffe. If they are not, the processor will be locked. The current MQX linker files set off the warning but do not cause real problems.

 

View solution in original post

0 Kudos
6 Replies
953 Views
DavidS
NXP Employee
NXP Employee

Partial answer to your question from other post:

https://community.freescale.com/message/93414#93414

 

A JimT suggested below, did you submit an SR?

Sorry for the hassles.

Regards,

David

0 Kudos
954 Views
jimtrudeau
Senior Contributor I

I've been in touch with the apps team. Relative to MQX demo or sample projects, this is a false alarm. If you see this dialog (image below) you are safe to click "No" and continue the flashing operation. There has been no change in the MQX linker files. They are safe and the processor will not be locked.

 

This warning results from a new check introduced in the latest CodeWarrior update. This problem will be corrected either in the next MQX RTOS update or a subsequent CodeWarrior update. The CodeWarrior tools now check to see if values are being written to addresses in the range 0x400 to 0x40f. However, it is the final four bytes of that range that must be 0xfffffffe. If they are not, the processor will be locked. The current MQX linker files set off the warning but do not cause real problems.

 

0 Kudos
953 Views
TomSkwara
Contributor III
Recommendation followed and verified to work - thank you.
0 Kudos
953 Views
sps
Contributor I

Thanks for getting this out Tom.

 

As for your first question - 'no it's not just you'. I've had quite an effort just to get examples to build, and still get 4 or 5 warnings (muitlple delcarations) every project anyway - which I see have caused forum entries too.

 

 

0 Kudos
953 Views
chembal_g
Contributor I

I'm getting the same problem with the K40 BSP.  A reply to this thread would definitely be helpful.  I'm going to crosspost to the MQX forum as well.

 

0 Kudos
953 Views
jimtrudeau
Senior Contributor I

I don't want to let this hang. I would ask you to open a service request, but I just did that for you. That means the support teams will investigate and we'll see what's going on. Thanks for the report. I pointed them at this report. 

 

For the future, an issue of this level of severity ALWAYS merits a service request IMHO. Not that you shouldn't discuss in the forums, I like it here as well 'cause others can learn from the solution, it's not a private discussion. Anyone who learns a solution here saves us an SR. But the initial SR helps us get it into a formal system to get what could be a systemic problem resolved as quickly as possible.

 

So again, thanks for the report. Much appreciated. We'll get it resolved ASAP. I'm raising the temperature on this one. 

0 Kudos