Protected area of eeprom [MC9S08DZ96CLF]

[g_g1]

Hi all,

In MC9S12XET256 MCU i'm using 'Program Once filed' to store serial number of device. This 'Program Once field' is 64 byte size, is placed at 0x400100 address in memory and can be write only once and is no way to change this after once write.

Is something like this in MC9S08DZ96CLF? I have to store serial number of device based on MC9S08DZ96CLF in memory and i dont want to change it in the future. Also i want protect this area of memory against program or erase operations.

I found information in datasheet about EEPROM Block Protection but i don't know this area is always protected because I can still change registers NVPROT and FPROT.

Best

gg

[tonyp]

There is no 9S08 MCU that can survive BDM re-programming.

(Making the chip blank should not matter in most cases as the S/N is destroyed in the process.)

What I do is to give a bootloader with the S/N built-in and the related Flash region protected.  This means the end user can upgrade the unit without altering or risk damaging the S/N.

This, however, still does not protect the determined ones from connecting a BDM programmer and completely erasing the chip.

[g_g1]

Hi Tony,
Thank you for reply. Indeed in most case SN ereasing should not matter but i have very sensitive automotive infrastructure and checking SN is crucial to me.
Are you using NVPROT or FPROT registers for writing SN in memory? Or are you using some space of eeprom and your bootloader protect this space?
If I set NVPROT register like PE generate in CPU.c file but different EPS1 and EPS0 could i be sure the space of eeprom is protect? In this case i have to write SN with bootloader and always application should set NVPROT to protect? Am i right?

Best,
gg

[tonyp]

I write S/N at the same time as I program the bootloader -- whether stand-alone or combined with the initial app version.

With an appropriate tool, such as Cyclone PRO (in my case), I can generate serial numbers on the fly based on a predetermined pattern and memory location.  Each time I program another unit, a new S/N is 'engraved' automatically.

In my case, the location is always within the bootloader space in Flash (not EEPROM).  For example, for some MCUs, I use the range $FFA0-$FFAD for S/N.

Of course you need to protect the bootloader while programming it with appropriate NVPROT setting.

Most current members of the 9S08 MCUs allow incremental protection of Flash at run-time.  I let the application protect more memory, as it wishes, on startup during the first few instructions.

[g_g1]

Hi Tony,
Your description sound very good. Can we discuss about details? How do you combine bootloader with application code? I have only stand alone bootloader but want to create combined with my application. This could speed up programming of new devices.
I'll use the same flash range as you.
In case of my stand alone bootloader i have NVPROT set at 0xFD (FPS set at 1E - protect 8Kbytes of flash at range 0x0_E000–0x0_FFFF).
How i have to set NVPROT register in my application? Does it matter? As i think NVPROT register is loaded to FPROT during start sequence of MCU. How can i change those registers at run time?
I want to be sure my application will not change the SN.
What about the NVOPT register? Need i change something in this register?

Best,
gg

[tonyp · Accepted solution]

g g wrote:

How do you combine bootloader with application code?

I work with S19 files (assembly language).  If you use CW or some other tool, make it produce S19 files (instead of ELF or whatever other non-ASCII format).

Once you have your two S19 files (one for your bootloader, and one for your application), it's very simple.

Simply remove the S9 record from the first file (but not both) to avoid confusing certain image burning applications that assume S9 is the end of your image, and concatenate the result into a single file.  (Depending on your OS, you will have to use appropriate command line commands. Examples (assuming app.s19 is first with S9 record removed):

Under Windows:

copy app.s19+boot.s19 image.s19

Under Linux:

cat app.s19 boot.s19 > image.s19

This can all go into your makefile.

In case of my stand alone bootloader i have NVPROT set at 0xFD (FPS set at 1E - protect 8Kbytes of flash at range 0x0_E000–0x0_FFFF).

I assume 8KB is the size of your bootloader alone, and not the combination of app and bootloader.  Because you should only protect the bootloader Flash so that the bootloader can update the app region of the Flash.  So, for 8KB bootloader, $1E seems correct.  But, because of the FPOP bit in position 0 inside FPROT, you need to shift this value one bit to the left.

So, you need to use $3C for NVPROT value to protect 8KB of Flash, and all EEPROM.

Assuming EEPROM is not to be protected, you need to combine those two EPS bits also (%11000000), and so the final NVPROT value would become $FC, if I did all the math right.

The application should protect as much more Flash as needed.  For the DZ128 I used in one project, I only needed EEPROM and no user configuration Flash storage, so my app starts like so (assembly language):

                    lda       #%11000000          ;protect all program Flash
                    sta       FPROT               ;leaving EEPROM area unprotected

How i have to set NVPROT register in my application? Does it matter?

No, just in the bootloader.  NVPROT is meant to protect the fixed bootloader code.

I want to be sure my application will not change the SN.

The S/N should be within the bootloader then.

Hope this helps.

[g_g1]

Hi Tony, 

Thank you very much for your help
However, I have used eeprom memory for my sn but now i know how to protect this area.
I failed to combine bt with the app but I will return to this issue in my free time.

Best,
gg

[tonyp]

Regarding failing to combine app with bootloader, one thing I forgot to mention that may be related to whatever problem you had is that the app must keep itself out of the bootloader space -- and that means the vectors also.

So, vectors in your app should be placed in their redirected locations, not the original ones.  You need to enable vector redirection either in hardware (where available) or software via the bootloader doing the redirection 'manually'.