cant assert security setting via S19 file content

[jah]

reference mc9s08rd32dwe processor, code warrior debugger ver6.1
while debug using a P&E multilink debugger in CodeWarrior i am unable to assert flash location 0xFFBF to a 0xFF value, it seems to default to 0xFE and gives me a unable to verify error at load.

dont see any options in the codewarrior debugger to modify this behavior. what step by step method to set the option in the debugger to load from S19 the security settings.


//in code i am asserting 0xFFB0 through 0xFFBF by:
//from the file myglobals.c
#pragma CONST_SEG _mySecurity
const struct flashreg FlashReg = {{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08},
{0xFF, 0xFF, 0xFF, 0xFF, 0xFF,},
0x7F, 0xFF, 0xFF};
#pragma CONST_SEG DEFAULT

//from the myLinker.prm file
SEGMENTS
mySecurity = READ_ONLY 0xFFB0 TO 0xFFBF;
END
PLACEMENT
_mySecurity INTO mySecurity;



in the debug scession, the "MEMORY" window i can see the 1,2,3,4... pattern in flash but the last location at 0xFFBF is set to 0xFE not 0xFF. this results in the loader giveing me a flash memory load verify error.

thanks everyone!

[peg]

Hi jah,

When you erase a S08 device with an automated programmer the programmer straight away sets the security bits to 1:0 to un-secure it.

A blank check of a device will ignore the non-erased state byte here. Not sure if this is done by the device or the programmer.

Therefore the only value you can use to subsequently secure the device is 0:0.

This is due to the fact that you can only programme flash bits from a 1 to a 0, you must ERASE a 0 to a 1.

Regards

David

Message Edited by peg on 2006-11-2108:33 AM

[jah]

somehow my codewarrior debuger is automatically setting bit zero at 0xFFBF, the control register for the mc9s08rd32dwe security enable disable.

this control register is located in flash memory, transured to a volitle registor from flash at powerup.

i need to define the security on/off state in my s record loaded into flash memory and not have the debugger reset it.

dont know how to else say it: this post has nothing to do with fundimantals of flash memory programming, the freescale loader handles all this. the loader is not performing as expected.

[peg]

Hi jah,

Just because you are sitting in a higher layer DOES NOT mean that you can ignore the fundamentals of your underlying layers!!!

The fact is that when you erase the device the programmer then CLEARS bit 0 of $FFBF. (not set as you said). Therefore you are never given the oportunity to leave this bit set.

There is nothing any loader or debugger or whatever can do about this. You have to use $FC at $FFBF to secure it.

Regards

Peg

[jah]

i set location 0xFFBF = 0xFC

the codewarrior debugger behaved ODD. it pretended to load the code, completed the operation w/o an error prompt but when i looked at the result of the loading there was no code in the flash program memory 0x8000 through 0xFFFF, it was all set to zero. 0xFC is so bad.

why is this such a problemo?

flash memory location 0xFFBF is no different than any other location. granted when emulation starts it gets loaded into its equivalent vollitle ram register at 0x18?? but before that it is just another location to program. why dosnt it program along with all the others. i am not aware of security restrictions on clearing the whole memory and writing everything new no matter how the part's security is configured.

[Alban]

Hi Jah,

You can add a line in your S-Record to write at the Flash location and secure your device.
The line has to be added before the S9 line.

Something like:

S1FFBF0100xx

should do. xx is the checksum to calculate (add all FF+BF+01+00 on 16-bit)

Alban.

Message Edited by Alban on 2006-11-21 10:59 AM

[peg]

Hi Alban,

Super Moderator????

Why would you bother to fiddle with the S records to achieve this?

Also the value of 01 is wrong for the reasons outlined in the thread.

Regards

David

[jah]

thanks everyone 4your input!

i have to re-iterate, with the C language array, there seems no need to add and additional S record line.

the codewarrior debuger response (all zeros) is not as i expected. for example: a third party programer allowed access to the S record in clear text and the option to set or clear or set again security enable at will. C language or not it would be easy for someone to find and modify the S record controlling the 0xFFBF security enable.

once the code gets into the device all is good for security tho. but nothing is secure untill the chip is power cycle.

just while in the programming scession everything is known in clear text yet the debugger is all zero's while there is no secret.

good for marketing.

i will try to update my code samples for the good of peeps looking for code samples, if they do that type of thingy.

[peg]

Hi,

Alban, Hey I'm Australian! You should know that mockery of this sort of thing is a national sport!

I don't think it "stinks", pompous would be closer to the mark,

Nothing really bothering me, just wondering why you would want to go to the trouble of manual editing. I guess that in the case of production programming of virgin parts you might be able to use other values to achieve security if the devices are delivered truly blank.

Jah, I agree that Hiwave could make it clearer that the values displayed are not real! When I tried it, I fired up hiwave and connected to an already secured chip, There was a line in the command window that reported that it thought the device to be secure. Did you not see anything, it is easy to miss and may even scroll out the top before you see it.

Regards

Peg

[Alban]

---

peg wrote:

Alban, Hey I'm Australian! You should know that mockery of this sort of thing is a national sport!

I don't think it "stinks", pompous would be closer to the mark,

---

Hi David,

I had figured a bit of it now . You'll have a pompous and non-smelly title then !
The Super-Moderator status does not reflect the quality of my contribution but it does for the Contributor. (I don't like super heroes that much).

I'll find something for even more posts... Like "Pillar" of the Community or "Expert". Last one seems nice actually.

I'm an Applications Engineer, I like to put my hands in the dirty mechanisms to try and get what I like...

Sure you know what I'm talking about !

But it's true that for my GZ32 ROM Code I declared in the code, and didn't butcher the S19.

Cheers,

Alban.

[peg]

Hi Alban,

Another problem with fancy titles is that they seem shut down the conversation.

People seem to be reluctant to challenge a "Super contributer"

I don't like being wrong but I dislike more being wrong and no one telling me.

It happens very rarely anyway

Oh dear only 19 posts to go!

Regards

Peg

(Almost Super)

[jah]

i have the codewarrior metroworks ver6.1
p&e usb multilink pod
with the jtag on the target, while loading a locked or unlocked part there are no errors prompts, nothing scroled out either. you might noice the Memory screen with all zeros, it may be pointed at ram tho. after loading you immediatly do a F5 run again no errors but the target dosnt run. if at anytime you do a reset target you finally get an error prompt.

this whole thingy generated more quesitons. the answers so far sound like a republican speech on iraq:
1)after clearing+loading the entire flash with data (this includes 0xFFBF=0xFE or 0xFC) when does the new setting come into effect. my thinking is the FFBF flash value gets transfured to the volitle upper ram register first time when the part is reset. is this wrong and exactly when does it transfur.

2)again 0xFFBF is just another flash memory location. with or without security a whole chip clear and load is always possible. so why must you load 0xFFBF to 0xFC to set security on. why dosnt 0xFF or 0x00 work just as well? did the chip designers not read the programming manual. lol

3)if you have just cleared and loaded the target flash why cant you emulate? yes i know the part is locked but could there be an option to unlock and emulate? after all you have just loaded the part and its only one bit, in clear text you know the code, why lock out the part? odd, very odd.

if anyone does a search or if the search is turned on here is some code
//in globals.c i set the flash security registors 0xFFB0 FFBF
#pragma CONST_SEG _NONEVOLITLEREG //security code = 1,2,3,4,5,6,7,8
const struct flashreg FlashReg = {{0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x06},
{0xFF, 0xFF, 0xFF, 0xFF, 0xFF,},
0xFF, 0xFF, 0xFC};
#pragma CONST_SEG DEFAULT

//in globals.c i also load the ram with the executable that does the backdoor reset
#pragma DATA_SEG _RAMROUTINE2 //sizeof 50bytes
unsigned char FlashRamRoutine2[] = {
0xA6,0x20, //LDA 0X20 ;ENABLE BACKDOOR WRITE FCNFG/KEYACC
0xC7,0x18,0x23, //STA FCNFG ;0x1823 = m(FCNFG)
0xA6,0x01, //LDA 0XFF ;WRITE 1OF8 CODE BYTES security code = 1,2,3,4,5,6,7,8
0xC7,0xFF,0xB0, //STA NVBACKEY+0
0xA6,0x02, // WRITE 2OF8 CODE BYTES
0xC7,0xFF,0xB1,
0xA6,0x03, //WRITE 3OF8 CODE BYTES
0xC7,0xFF,0xB2,
0xA6,0x04, //WRITE 4OF8 CODE BYTES
0xC7,0xFF,0xB3,
0xA6,0x05, //WRITE 5OF8 CODE BYTES
0xC7,0xFF,0xB4,
0xA6,0x06, //WRITE 6OF8 CODE BYTES
0xC7,0xFF,0xB5,
0xA6,0x07, //LWRITE 7OF8 CODE BYTES
0xC7,0xFF,0xB6,
0xA6,0x08, // WRITE 8OF8 CODE BYTES
0xC7,0xFF,0xB7,
0x4F, //CLRA ;DISABLE BACK DOOR
0xC7,0x18,0x23, //STA FCFG
0x81 //return
}; //unsigned char FlashRamRoutine2...
#pragma DATA_SEG DEFAULT
//here is the assoiciaged globals.h
#pragma DATA_SEG _RAMROUTINE2
extern unsigned char FlashRamRoutine2[];
#pragma DATA_SEG DEFAULT
#pragma CONST_SEG _NONEVOLITLEREG
extern const struct flashreg{
const unsigned char NvBackKey[8];
const unsigned char Reserved1[5];
const unsigned char NvProt;
const unsigned char Reserved2;
const unsigned char NvOpt;
}FlashReg;
#pragma CONST_SEG DEFAULT
//this is how the ram based application is called from program flash
//use back door
_asm jsr FlashRamRoutine2; //use back door
//from the linker file myliner.prn
SEGMENTS
NONEVOLITLEREG = READ_ONLY 0xFFB0 TO 0xFFBF;
END
PLACEMENT
_NONEVOLITLEREG INTO NONEVOLITLEREG;
END

Message Edited by jah on 2006-11-2110:08 PM

[peg]

Hi jah,

---

jah wrote:
i have the codewarrior metroworks ver6.1
p&e usb multilink pod
with the jtag on the target, while loading a locked or unlocked part there are no errors prompts, nothing scroled out either. you might noice the Memory screen with all zeros, it may be pointed at ram tho. after loading you immediatly do a F5 run again no errors but the target dosnt run. if at anytime you do a reset target you finally get an error prompt.

---

Well this seems to be a Codewarrior problem. (Not telling you it is secure) The 00 value is correct though as this is the actual value returned over the BDM interface when trying to access secure resources.

jtag????

---

jah wrote:
1)after clearing+loading the entire flash with data (this includes 0xFFBF=0xFE or 0xFC) when does the new setting come into effect. my thinking is the FFBF flash value gets transfured to the volitle upper ram register first time when the part is reset. is this wrong and exactly when does it transfur.

---

The value at NVOPT is copied to FOPT at reset. FOPT will be C3 for an truly erased device after reset.

This will be changed to C2 if a successful blank check is done via the FCMD register. As the security depends on the value in FOPT and not NVOPT the device is now unsecured until reset.

---

jah wrote:

2)again 0xFFBF is just another flash memory location. with or without security a whole chip clear and load is always possible. so why must you load 0xFFBF to 0xFC to set security on. why dosnt 0xFF or 0x00 work just as well? did the chip designers not read the programming manual. lol

---

The problem is Codewarrior/P&E writes $FE into NVOPT straight after an erase so bit zero is ALWAYS a zero you have NO OPTION! The blank check done by Codewarrior must not use the $05 command in FCMD to do its blank check as this fails when all is blank and $FFBF contains $FE.

FF and 00 DO WORK as secure values you just can't do it from Codewarrior/P&E!

---

jah wrote:

3)if you have just cleared and loaded the target flash why cant you emulate? yes i know the part is locked but could there be an option to unlock and emulate? after all you have just loaded the part and its only one bit, in clear text you know the code, why lock out the part? odd, very odd.

---

This again is a limitation of Codewarrior!

If you programme the device and set security FOPT will still contain C2 so you can do anything you like!

The problem is Codewarrior/Hiwave resets it and the secure value in NVOPT gets transferred into FOPT and NO ACCESS!

Providing some means to unlock and emulate would break the security. This would be like locking the front door but leaving the back door open in case someone needs to get in.

In summary I think you are directing your complaints to the wrong place.

The device works as advertised (at least the GB60 I have tried)

All the issues you describe are caused by Codewarrior/P&E/Hiwave NOT the MPU!

I hope we have put this to bed now

Regards

Peg

[Alban]

Hi Peg,

Yes, Super Mod as I have Admin rights but I'm not Admin. It's just that I'm the only guy in these boards covering moderation of every single board. My Admin rights are more for everyday stuff or unblock people. It's not my forum after all

Actually there is also Super Contributor at 500 posts with good rating. You're not to far away. If you think the name stinks, suggest something else not too pompous !
I'll see if I can change.

---

Back to the sheep now:

I fiddle with the S-Record to be compiler/debugger/programmer independant.
This way the code can be submitted to a programming house and the location would be programmed.
There is a similar way with doing a FILL of the location in the PRM file.
I find it easier as this line is OK for most HC08.

What's bothering you David ?

Cheers,
Alban.

[peg]

Hi Jah,

Congratulations, you have successfully secured your MPU!

Hiwave will display all zeroes for the secured resources!

Nothing odd here!

I have cross checked all that I have said in this thread on a M68DEMO908GB60.

I programmed your array in as you do.

The only difference is I am using assembler and stand alone P&E programmer.

I also confirmed that Hiwave will read a secured MPU as all zeroes.

Regards

David