EEPROM goes into protected mode after loading application using a bootloader

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

EEPROM goes into protected mode after loading application using a bootloader

Jump to solution
1,143 Views
aceshigh99
Contributor I

A colleague has written a CAN-based bootloader for a family of devices that utilizes the MC9S12DG256 MCU, Mask 0L01Y.  I've modified the bootloader for the device that I'm working on, and after using it to load the application code, the application's EEPROM erase/write routines no longer work properly.

 

The rest of the application appears to execute correctly.  It is performing all of its CAN-based communication, and the PC software can connect to and recognize the device.

 

However, when I try to change any configurable parameters, the EEPROM erase/write does not take.  Upon power-cycling, all the parameters revert back to their default states.

 

The EEPROM initialization routine I'm using is below:

 

void eeprom_init()

{

    INITEE |= 0x01;

    ECLKDIV = ECLK_DIVISOR;  // ECLK_DIVISOR = 74

    ECNFG = 0x00;

    EPROT = 0x88;            // EPOPEN (bit 7) = 1; EPDIS (bit 3) = 1

}

 

As can be seen above, I've seen the EPROT register to 0x88 so that the entire EEPROM array is unprotected (EPOPEN = 1) and protection is disabled (EPDIS = 1).

 

I put a diagnostic routine into the code that transmits the value of the EPROT register, and what I've found is that when the application is running in standalone mode, EPROT is set to the expected value of 0x88.

 

However, when the application is running after being loaded via the bootloader, the value of EPROT is unstable - it is sometimes 0x48, sometimes 0x18, etc.  In each case, the EPOPEN bit is set to 0, which means that the entire EEPROM array is protected, and hence, not writable.

 

I can't run the code through the BDM and set breakpoints because it's already executing the CAN Loader, so debugging has been extremely challenging, to say the least.

 

Can anyone think of any reasons why the state of the EPROT register would randomly change to protected mode only when loading the application with the CAN Loader?

 

Any thoughts or suggestions would be much appreciated.  Thanks in advance.

Labels (1)
0 Kudos
1 Solution
762 Views
StenS
Contributor III

Can it be so that you are writing to the EEPROM Protection/Reserved Field? I'm not familiar with this derivate, but on 9S12DT128, which belong to the same family, the top 16 bytes of the EEPROM are reserved, and the EPROT-register is automatically loaded from one of these bytes during reset. This means that on a 2k EEPROM you can not use all 2048bytes, only 2032 are available for your program.

Sten

View solution in original post

0 Kudos
4 Replies
762 Views
aceshigh99
Contributor I

I have some more information:

Apparently, it's NOT just in bootloader mode that this is occurring.  After power-cycling, the EEPROM goes into protected mode for NO reason.

I've changed the initialization routine to simply:

void eeprom_init()

{

    ECLKDIV = 74;

}


The first time the code executes, the value of EPROT is 0xFF.  After power-cycling, it's 0x4F and NO EEPROM writes are possible.


I don't manipulate EPROT anywhere in the code, so I have no idea why it's randomly changing on me but this is very frustrating.  Any ideas?

0 Kudos
763 Views
StenS
Contributor III

Can it be so that you are writing to the EEPROM Protection/Reserved Field? I'm not familiar with this derivate, but on 9S12DT128, which belong to the same family, the top 16 bytes of the EEPROM are reserved, and the EPROT-register is automatically loaded from one of these bytes during reset. This means that on a 2k EEPROM you can not use all 2048bytes, only 2032 are available for your program.

Sten

0 Kudos
762 Views
aceshigh99
Contributor I

You're correct - that is what was happening.

The original code saved a checksum value to 0x0FFC - 0x0FFF, and this was overwriting the EPROT value.

When I moved the location where the checksum was being written to, the issue appeared to resolve itself.  Thank you for your assistance.

0 Kudos
762 Views
RadekS
NXP Employee
NXP Employee

Yes, that looks like reason for that behaviour.

When your core run fist time (EPROT is 0xFF), your code probably write to address 0x0FFD where is EEPROM protection byte. The EPROT register is loaded from EEPROM array address 0x0FFD during next reset.