Hi,
I am new to this community and processor.
I am taking over a legacy project that is using the MC9S12A128 processor.
I have made some changes and seems that after the changes, when I flash using the PROG12Z, I see that the processor has gone into SAFE/Secure mode, and I need to use 'P&E MC9S12 Unsecure Program' to unsecure it again.
This does not seem to be a problem when flashing the original flash before the changes.
Could someone point me to some things I should be looking at to resolve this issue.
Thank you very much in advance,
Kind regards!
Hi,
Your original code does not contain writing to security byte so after mass erase
It contains only these addresses from the range 0x0FFFxx :
S2 24 0F_FF80 C000C000C000C000C000C000C000FD29C000C000C000C000C000C000C000C000E7
S2 24 0F_FFA0 C000C000C000C000C000C000C000C000C000C000C000C000C000C000C000C0002D
S2 24 0F_FFC0 C000C000C000C000C000C000C000C000C000FCE0FC13FB90C000C000C000C000D7
S2 24 0F_FFE0 C000C000C000C000C000C000C000FD13C000C000C000C000C000C008C008C00885
So there is no write to the address 0xFF0F which means the device will be automatically secured after the mass erase and loading this code. Why…. I made a mistake in my thinking….
Hmmmmm, I was influenced by programming when debugging. In this case the programmer automatically unsecures the MCU (if it is not set in different way in postload command file). It is my fault I forgot to think about your issue as a standalone programming where if the flash is mass erased before programming then secure byte remains in secure state 0xFF which is from practical use better because without thinking about security the code is automatically secured and not readable from outside.
So now, for this approach it would be good to have in the code unsecure action for final code. (not suitable for debugging because of cumulative programming from if FLASH NO_UNSECURE command was not used in postload command file for debugging)
Set security byte to unsecure status
//==============================================================================
// const segment variables
//==============================================================================
// security code, this is the code which is written to security bytes during program flashing.
// backdoor key is disabled, only mass erase is accepted from BDM
const unsigned int security_and_protection_array_code[] @ 0xFF00=
{ 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,0xFFFF,0xFFFF,0xFFFE // address FF0F stores 0xFE: unsecure device with backdoor key disabled
};
//==============================================================================
.... or you can do it manually as described previously .....
Best regards,
Ladislav
Hi,
Could you please share with me S record you are loading into MCU?
Just to check it because I am surprised Prog12z secures the MCU automatically.
Another way how to load S record without paying any money is to download CodeWarrior and use hiwave.exe from prog directory. It also uses pemicro USB multilink as a interface for programing. It is also good to think about operating system. CW 5.2 is designed for W10. There is also god to read..
https://community.nxp.com/t5/Classic-Legacy-CodeWarrior/How-to-Add-missing-derivatives-to-CodeWarrio...
( Some more info https://community.nxp.com/t5/S12-MagniV-Microcontrollers/S12-X-Programming-Debugging-Possibilities/t...)
If you want to send me Srecord then you can submit a a ticket to https://www.nxp.com/support/support:SUPPORTHOME?tid=sbmenu.
You can add text ... "assign to Ladislav" into it.
Some more notes:
1) Have you tried to load into MCU another very simple code whether the programming makes the same issues?
2) Have you tried to use another board
3) Have you check programming procedure whether there is no "postload" action selected or enabled for programming process.
4) Do you program banked for of Srecord or Linear form of Srecord as it is usually required by programming tools?
... you can answer all my question in the ticket if you will share the Srecord with me.
Best regards,
Ladislav
Hi,
So again. I have not made mistake in the message I deleted. I was preparing it in the late evening and woke up in the morning with imagination I had made a mistake. .... professional deformation........
However, I added dome info here.
The address FF0F is 3FBF0F in banked form or in linear form 0FFF0F
The line from you record which contain the security byte is…
S2240FFF00 001402001402001402001D0027CB08010014020014020014020014020014020005
Check address 0FFF0F and you will find there 01 which gives…
Entire reality from your Srecord is 0x01
KEYEN1 KEYEN0 NV5 NV4 NV3 NV2 SEC1 SEC0
0x0FFF0F: 0 0 0 0 0 0 0 1 ............. so secured
I suggest to use: 0 0 0 0 0 0 1 0 ………….. unsecured.
or : 1 1 1 1 1 1 1 0 ………….. unsecured.
You have two possibilities….. you can rewrite simply 0x01 to 0x02 .... I will not investigate usage of NV[5..2] bits.
S2240FFF00001402001402001402001D0027CB08020014020014020014020014020014020004
Or another approach is to rewrite it to a standard unsecured status 0xFE. In this case the new line will be
S2240FFF00001402001402001402001D0027CB08FE0014020014020014020014020014020008
So you have to somewhere when you generated S record from C code or somewhere in the code define constant or something which sets FF0F to secured state.
You can change it manually to 00 but you have to recalculate Checksum. Last byte in the line. Excel and functions hex2dec(), dec2hec() and mid() are good to split row to bytes and recalculate the check sum.
checksum -- These characters when paired and interpreted as a hexadecimal value display the least significant byte of the ones complement of the sum of the byte values represented by the pairs of characters making up the count, the address, and the data fields (http://www.amelek.gda.pl/avr/uisp/srecord.htm)
Simple approach
Original code
S2240FFF00001402001402001402001D0027CB08010014020014020014020014020014020005
New code
S2240FFF00001402001402001402001D0027CB080200140200140200140200140200140200??
Because we increased sum with 1 the checksum will be 1 less so the result is….
S2240FFF00001402001402001402001D0027CB08020014020014020014020014020014020004
But the MCU will not be secured after reset as in original code. Probably it was done intentionally.
More complicated approach to understand
If you want to write there 0xFE then
BR,
Ladislav
Thanks for the quick response.
I checked the code, and it seems that we are not setting or initializing the above security bit at all in the code.
I wonder if I am seeing this because these registers are not initialized at all, thus we are seeing the problem intermittently.
>I am not sure because I do not use Prog12z but probably it also enables secure the MCU after programming as a part of additional programming >steps defined by user. (it is a product of www.pemicro.com)
Which program do you use to flash the processor?
Kind regards.
Hi,
There is the Flash Options/Security byte at the address $FF0F ( Refer to S12FTS128KV2 reference manual).
This byte is loaded from flash to FSEC register during reset and if it was pre-programmed in the application to the „secure MCU“ the MCU is secured after reset and the only mass erase command is accepted from BDM.
See description of FSEC register in the manual.
I am not sure because I do not use Prog12z but probably it also enables secure the MCU after programming as a part of additional programming steps defined by user. (it is a product of www.pemicro.com)
However, the first thing I would check is the application code for setup of the security byte. You can find there something like this….
Secure without backdoor key
//==============================================================================
// const segment variables
//==============================================================================
// security code, this is the code which is written to security bytes during program flashing.
// backdoor key is disabled, only mass erase is accepted from BDM
const unsigned int security_and_protection_array_code[] @ 0xFF00=
{ 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF,0xFFFF,0xFFFF,0xFFFD // address FF0F stores 0xFD: secure device with backdoor key disabled
};
//==============================================================================
Secure with backdoor key
//==============================================================================
// const segment variables
//==============================================================================
// security code, this is the code which is written to security bytes during program flashing.
// when you want to unsecure you should write this code (backdoor key) to security memory
const unsigned int security_and_protection_array_code[] @ 0xFF00=
{ 0xC0DE,0xC0DE,0xC0DE,0xC0DE, // backdoor key code
0xFFFF,0xFFFF,0xFFFF,0xFFBD // address FF0F stores 0xBD: secure device with backdoor key enable
};
//==============================================================================
Best regards,
Ladislav