This is the unsecure routine that I'm trying to get to work (but hangs at step 1)
Doing steps 4 to 7 of the unsecure routine currently unsecures the device.
Any idea what could be causing the problems?
Hi,
I have another problem with secure of my S12G128 device. If I change configuration field at address 0xFF0F. My new value is 0xFC. After reset FSEC is still 0xFE.
I tried send message after reset with value at address 0xFF0F and second message with FSEC and receive data in my terminal are 0xFC, 0xFE. I tried many resets but result is the same.
Here is my code:
if flasher module:
===============================
.
.
const unsigned char flash_array[] @0xFF08 = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFC};
/*
0xFF08-0xFF0B - reserved
0xFF0C - P-Flash Protection byte = 0xFF (default state, protection is disabled)
0xFF0D - D-Flash Protection byte = 0xFF (default state, protection is disabled)
0xFF0E - Flash Nonvolatile byte = 0xFF (default state, watchdog is disabled)
0xFF0F - Flash Security byte = 0xBC (secured)
*/
.
.
in main module:
================================
.
.
#pragma OPTION ADD _CONST_FAR "-CpPPage"
//================== IMPLEMENTACE VEŘEJNÝCH FUNKCÍ ===========
//=============================================================
// Spusteni hlavni funkce loaderu
// Vstupy: bez vstupu
// Vystupy: bez vystupu
// Pozn.:
void main(void)
{
AppExecute_t *pt_AppRestVector;
LONG u32_ResetApplAddr = ((LONG)APPL_END_ADDR) - 1;
volatile BYTE *__far pau8_Cfg = (BYTE *__far)0x3FF0F;
pt_AppRestVector = (AppExecute_t*)((WORD)u32_ResetApplAddr);
PE_low_level_init();
V_Sci0_InitPort();
V_Sci0_PutChar(*pau8_Cfg);
V_Sci0_PutChar(FSEC);
if(u8_Main_WaitForFlashMo
.
.
I do not understand why FSEC is 0xFE if this register is loaded during reset from address 0xFF0F and here is 0xFC.
CW: 5.9.0
Programmer: P&E Multilink
Device: S9S12G128F0CLH
Thanks a lot for any idea.
Mirek
Red wrote:So far, I have been able to write routines that allow me to secure the flash and also unsecure the flash but there's a few issues. The main one is that, despite setting a backdoor key when securing the device, the flash can be unsecured just by changing the value of $FF0F (ie. without doing any writing to $FF00 - $FF07.) Note that consecutive lock-unlock operations are done with a reset inbetween.
Red wrote:Another problem is that, if I do try to unsecure the device through the backdoor key method, the MCU seems to hang as soon as I try to set KEYACC in FCNFG. Note that this only occurs once the device is locked.Finally, when the device is unlocked, I've noticed that I cannot use bset to set KEYACC and instead have to do a full write to FCNFG. A bset simply doesn't set KEYACC.
kef wrote:Of course. If vector area isn't write protected then you can reprogram FF0F as any other byte and just reset. Part will get unsecured. Backdoor is to let you unsecure temporarily without program/erase cycles.
Of course! I thought I was missing something obvious. I'll execute that code in RAM.MCU "hangs" if you set KEYACC while running from flash. When KEYACC is set - MCU can't read program in flash. It's the same like with program/erase, flash is not readable while it's being programmed.
Red wrote:There are statements like 'The contents of the Flash Protection/Options byte at $FF0F in the Flash Protection/Options Field must be changed directly by programming $FF0F when the device is unsecured and the higher address sector is unprotected.'
I did however wonder how there could be any protection against a single byte in flash memory given that it's sector can be erased.
I'm not sure what the question is, but there are two different things: 1) flash security and 2) flash protection. Security is to make code not readable via BDM. Write Protection is to make memory not writeable/eraseable by firmware running in MCU. There are FSEC and FPROT registers. There are also default values for these registers which get loaded on reset from bytes at FF0F, FF0D, FF0C etc. If you want to unsecure part by reprogramming (from firmware in MCU) security byte at FF0E, then vector area must be not write protected. Backdoor will work even if vector area is write protected provided KEYEN=10.
ramabh wrote:I am not completely depending on the debugger.when i tried to overwrite at FF0F i got that error message and from the reset onwards i am not able to connect to debugger.It means i overwritten the data at FFOF to FC,i thought my rest of the also code resides in memory but nothing is working.
ramabh wrote:I am placing the constant data at FF0F not at BF0F.From the datasheet i understand that what ever data placed at FFOF will be replicated at BF0F.
kef wrote:I'm not sure what the question is
what kef mentioned is absolutely right.
I just want to clear one thing...
FFOF comes under unpaged memory and Flash block 0,so when u want to overwrite data at FF0F u have to use flash routines that are located in flash block 1 or eeprom or ram or stack..
ramabh wrote:With this when i am loading the program the compiler gives a error "Error while programming flash in area 3FBF0E"and afterwards when i look at that locations at FF02 the data is 12 and at FFOF its FC and next time to program the MCu i have to unsecure the device.
ramabh wrote:I thought it is behaving as expected with that error only i tried to run the program....it is behaving as if there is no data in flash.