on mcf51je not able to change flash non volatile registers

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

on mcf51je not able to change flash non volatile registers

Jump to solution
881 Views
bango
Contributor II

Hello,

 

I am using mcf51je256 on the evaluation board from Freescale (TWR-MCF51JE) with CW 10.2 and Multilink Universal from PE Micro. I compiled the USB Stack 4.0.3 for the MSD_and_CDC application and flashed it. But I cannot set the registers CHKSBYP or any other from registers at the addresses 0x400-0x40F. In the code there is a line

 

/* checksum bypass */

const uint_8 checksum_bypass@0x040a = 0x0;

 

In the memory map this entry is present, in the S19 file too. But the value at address 0x40A remains always 0xFF. I have functions that can delete and write in the flash from user mode (tested and working for the space 0x410- 0x3FFFF). When I try from the code to delete this address space I get an exception "Access Error" with "Error on operand write". So I am not able to make any changes at these addresses. Should I do anything before I try to access this space? Has anybody experienced a similar problem?

 

Thank you in advance

 

Vasil

 

 

Labels (1)
0 Kudos
1 Solution
663 Views
bango
Contributor II

Hi Tom,

thank you for answering. I have read all these chapters very thoroughly, but still could not make changes in this memory space. But today after hours of trying I found a way to do that. First of all there is an application note (as you mentioned) that describes this a bit. It is AN3305 and discusses "On-Chip System Protection Basics for HCS08 Microcontrollers". Because Coldfire V1 is based on S08 (as far as I know) then this app note should be quite helpful. There is one paragraph there:


A user program cannot set or clear the FPROT register. Instead, after an exit from reset, FPROT is loaded

with the contents of the NVPROT location, which is in the nonvolatile register block of the flash memory

and cannot be altered by application software. The EPS and FPS bits can be set in the NVPROT location

during programming to enable block protection. The only other way FPROT can be written is through

background debug commands, which provide a way to erase and reprogram protected memory.

I have also seen in the links that you have provided that these TRIM configurations needed to be set with Background Debug Commands. Here this was also mentioned.

So what I did was to make a complete erase of the memory. 0x40A was 0xFF.

Then I flashed the program that I have compiled. 0x40A was still 0xFF although the entry in the S19 file S3060000040A00EB was present.

Then I made another S19 file with these 3 lines:

S0030000FC

S3060000040A00EB

S705000010EA00

Then I made a target task in CW with 2 actions: program and verify. In the program action I load this S19 file and run the task. Afterwards the only change in the memory is that 0x40A is set to 0x00 instead of 0xFF. Then my program runs as expected in user mode and not in bootloader mode (as it  did before).

Not sure if this is the proper way of doing this, but for now it is a workaround.

View solution in original post

0 Kudos
2 Replies
663 Views
TomE
Specialist II

I think I remember another post where someone was trying to change the clock TRIM bits, and was having similar problems. These ones might be worth reading through:

Re: Clock Trim Help?

ICS clock trimming: how is it implemented in the Programmers

You should also read through "4.3.3.4 Flash Protection Register (FxPROT and NVxPROT)". What are these registers set to - are those locations protected in your device? What are the values of FPS and FOPEN? Also read "4.4.3.2 Flash Protection Violations".

That code is trying to bypass the boot checksum test. Something has to calculate the checksum and store it or bypass the checksum (as above) and I think the programmer has to do all this in concert with the Bootstrap.

There should be an App Note on how all this (and the Bootstrap) is meant to work, but the only documentation I can find is Chapter 3.

Tom

664 Views
bango
Contributor II

Hi Tom,

thank you for answering. I have read all these chapters very thoroughly, but still could not make changes in this memory space. But today after hours of trying I found a way to do that. First of all there is an application note (as you mentioned) that describes this a bit. It is AN3305 and discusses "On-Chip System Protection Basics for HCS08 Microcontrollers". Because Coldfire V1 is based on S08 (as far as I know) then this app note should be quite helpful. There is one paragraph there:


A user program cannot set or clear the FPROT register. Instead, after an exit from reset, FPROT is loaded

with the contents of the NVPROT location, which is in the nonvolatile register block of the flash memory

and cannot be altered by application software. The EPS and FPS bits can be set in the NVPROT location

during programming to enable block protection. The only other way FPROT can be written is through

background debug commands, which provide a way to erase and reprogram protected memory.

I have also seen in the links that you have provided that these TRIM configurations needed to be set with Background Debug Commands. Here this was also mentioned.

So what I did was to make a complete erase of the memory. 0x40A was 0xFF.

Then I flashed the program that I have compiled. 0x40A was still 0xFF although the entry in the S19 file S3060000040A00EB was present.

Then I made another S19 file with these 3 lines:

S0030000FC

S3060000040A00EB

S705000010EA00

Then I made a target task in CW with 2 actions: program and verify. In the program action I load this S19 file and run the task. Afterwards the only change in the memory is that 0x40A is set to 0x00 instead of 0xFF. Then my program runs as expected in user mode and not in bootloader mode (as it  did before).

Not sure if this is the proper way of doing this, but for now it is a workaround.

0 Kudos