S12X flash protection problem CW SE 5.1 HIWAVE

[jsmcortina]

A number of years ago I created a serial bootloader for MC9S12XEP100 using CodeWarrior 4.7 and have been using the P&E Multilink BDM device to load the bootloader to chips. (I have found the multilink to be horribly unreliable, but that's another story.)

Recently I installed a different version of CodeWarrior to support a newer different product family. The installer managed to break the drivers for the P&E multilink. After re-installing various stuff I'm in the same situation as a colleague...  I now have CodeWarrior for S12(X) v5.1 special edition installed. (Fresh download yesterday.) It can load firmware ok (for once) but the results don't work correctly.

My application uses flash protection and enables security.

When V4.7 worked this was going on.

With V5.1, when I enable security, the device unexpectedly has full flash protection too and the serial bootloader cannot do anything.

I have confirmed that the generated binary ( P&E_Multilink_CyclonePro.abs ) is identical between releases.

I have enabled protocol logging in HIWAVE and it looks like it is reading the binary correctly and the data it _should_ be writing to the chip is the same. However, when I get my loader to spit out memory locations afterwards, they don't look correct.

My bootloader binary puts the various flash/security words into memory at FF08 onwards: (no backdoor key)

org $ff08

fdb $ffff

fdb $ffff

fcb $cc  - protect high range of flash 0xf000 upwards FPROT

fcb $ff

fcb $ff

fcb $7d - enable device security FSEC

Afterwards, that $cc is reading back as $7f meaning full flash protection, which is why I get FPVIOL when I try to erase a flash sector from within my application.

Any ideas what changed in HIWAVE between V4.7 and V5.1 and how to workaround this change?

The amount of time I've spent on it so far, I could have been a good way through writing my own BDM driver... However, I have a customer's device here that I was trying to reflash and return yesterday...

James

[jsmcortina]

I've found the problem, it is in the "control" algorithm in hcs12xe_common.fpp the 5.1 version of this file is incorrectly programming the security bytes as part of erase.

In the code that follows:

MODULE CONTROL_FLASH_BLOCK_12X_FTM1024K

is the following subroutine:

	21f3:    cc 30 a4	ldd    #0x30a4
	21f6:    7b 01 08	stab    0x108
	21f9:    7a 01 06	staa    0x106
	21fc:    79 01 02	clr    0x102
	21ff:    c6 06		ldab    #0x6
	2201:    7b 01 0a	stab    0x10a
	2204:    c6 7f		ldab    #0x7f
	2206:    7b 01 0b	stab    0x10b
	2209:    c6 01		ldab    #0x1
	220b:    7b 01 02	stab    0x102
	220e:    50		negb
	220f:    7b 01 0a	stab    0x10a
	2212:    c6 08		ldab    #0x8
	2214:    7b 01 0b	stab    0x10b
	2217:    72 01 02	inc    0x102
	221a:    c6 ff		ldab    #0xff
	221c:    7b 01 0b	stab    0x10b
	221f:    b6 01 0b	ldaa    0x10b
	2222:    7a 01 0a	staa    0x10a
	2225:    b6 01 02	ldaa    0x102
	2228:    81 04		cmpa    #0x4
	222a:    25 eb		bcs    0x0x2217
	222c:    72 01 02	inc    0x102
	222f:    7b 01 0a	stab    0x10a
	2232:    58		aslb
	2233:    7b 01 0b	stab    0x10b
	2236:    1c 01 06 80     bset    0x106, #0x80
	223a:    1f 01 06 80     brclr    0x106, #0x80, 0x0x223a
	223e:    fb
	223f:    c6 01		ldab    #0x1
	2241:    3d		rts

At address 0x2232 that's programming FE to address 0xFF0F. It should not be doing this as part of the erase cycle as it causes a subsequent double programming of those bytes and a flash error!

I edited the binary to put an RTS at address 0x21f3, thereby bypassing this code section and my device now programme correctly like it used to.

[kef2 · Accepted solution]

Yes, programming flash sector at 0xFF00 on devices with ECC flash, CW should erase flash sector first. Solution is to use FLASH NOUNSECURE in CW cmd scripts. Check this thread, it applies to S12XE as well.

P128, flash securnig

[jsmcortina]

"Yes, programming flash sector at 0xFF00 on devices with ECC flash, CW should erase flash sector first."

The issue is that by default HIWAVE is programming the security phrase _during_ the erase command. It isn't that it is missing an additional erase, it's the "erase" that is doing it. The (unexpected) security programming code is part of the "control" applet that is used for flash erasing as I posted above.

What's also troubling for me is that HIWAVE reads back the flash after programming, but fails to notice that it doesn't match. (I have HIWAVE command window logs with "show protocol" that show this.)

Using the "flash" dialogue in HIWAVE also doesn't permit erasing without also unsecuring. The secure/unsecure buttons are greyed out for me. Surely this dialogue ought to offer full control?

[kef2]

• "Yes, programming flash sector at 0xFF00 on devices with ECC flash, CW should erase flash sector first."
• The issue is that by default HIWAVE is programming the security phrase _during_ the erase command. It isn't that it is missing an additional erase, it's the "erase" that is doing it. The (unexpected) security programming code is part of the "control" applet that is used for flash erasing as I posted above.

I mean that it would be OK, if CW debugger wrote 0xFE to  0xFF0F after mass erase step, and then, when it comes to program phrase (or sector) at 0xFFxx, CW debugger could erase and reprogram whole sector.  

• Using the "flash" dialogue in HIWAVE also doesn't permit erasing without also unsecuring. The secure/unsecure buttons are greyed out for me. Surely this dialogue ought to offer full control?

Sure.

ZhangJennie wrote:

• It is also good to remember that in order to have BDM communication and therefore the possibility to debug the code, the security bits have to be in a 1:0 combination (SEC[1:0] = 10).

To be more precise, BDM communications are still enabled while SEC[1:0]!=10! More than that, flash is programmable and eraseable while SEC[1:0]!=10. More than that, having mass erased chip, flash is eraseable, programable and even readable (verifyable) (until reset). I agree that debugger won't work with SEC[1:0]!=10, but without proper programming what are you going to debug??? Right flashing is more important than ability to step over source lines.

CW cyclone/multilink flasher always was bit troublesome. I understand that very old devices with no BDM SYNC support (912D60, 912DT128?) were problematic to detect bus clock, and thus, I think, hiwave wants devices to be unsecured and scanned (RAM write/verify check?) to verify proper BDM speed. But those old devices had no flash security feature, so why newer S12's have to be SEC[1:0]==10 all the time for proper communications? Why also it is a problem for CW debugger to unsecure accidentally secured devices? Unsecure scripts are ~80% or even more likely to fail with unsecure task. Certainly SYNC is not used to determine bus speed.

Regards

Edward

[jsmcortina]

Edward,

this CW 5.1 version of HIWAVE is more unreliable than the one in 4.7. Previously (4.7) when I tried to flash a secured device it would give me the option to unsecure it.

Now it just keeps beeping and failing and beeping some more until I've cleared all of the dialogues.

Then I have to manually unsecure it, then quit HIWAVE, then unplug and replug the USB cable (fails otherwise.)

Then try to programme again.

To be clear, with 4.7, HIWAVE would automatically give you the choice to unsecure a device. That no longer works.

[kef2]

Are you sure CW4.7 supported S12XE family? I think it supported only S12(X) with non-ECC flash. It's hard to find CW 4.7 readme files.

[jsmcortina]

DEMO9S12XEP100 came with a CW 4.5 CD.

I'm sure that I was using CW 4.7 with the XEP100 until very recently when an update to the P&E drivers appears to have broken it. I've subsequently uninstalled all the old versions of CodeWarrior I had.

[kef2]

I guess you are right and something gone wrong with updated P&E drivers. I don't have working S12XE target to try it. My last time S12XE project wasn't too hard to debug with CW 5.x Hiwave and Multilink, the only issue was with missing FLASH NOUNSECURE command, when flash protection word had to be programmed.

Edward

[jsmcortina]

I attached a zip of my test project to the SR mentioned.

[ZhangJennie]

Hi James

yes, Edward Karpicz's solution is right.

Let's start with the fact that when working with the flash you can change a bit that has a value of '1' into a '0' with a write command but to turn a '0' into a '1' you need to perform an erase command which erases a full sector. It is also good to remember that in order to have BDM communication and therefore the possibility to debug the code, the security bits have to be in a 1:0 combination (SEC[1:0] = 10).

Based on the previous statements, the programming algorithm using CodeWarrior and the BDM programmer (either a USB Multilink, Softec, etc.) is designed to mass erase the memory first and then write a combination of 1:0 to the security bits in order to allow the debugger to communicate with the part and to allow any user to debug through the code using single stepping, breakpoints, etc. Whenever you configure your code to write a value of either 1:1 or 0:1 to secure the device, the debugger will try to change a bit that is already a '0' because of the programming algorithm into a '1'; in this case, bit 0 of the FSEC register.

command

FLASH NOUNSECURE

will not change security byte to unsecured state prior to programming that can solve the problem.

Have a great day,
Zhang Jun

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[jsmcortina]

I do fully understand how the flash security works, there's no need for a lesson here, that's how I was able to hack the binary blob to create my workaround.

When did this behaviour change (CW 4.7 worked without it) and is it documented?

The CW SE 5.1 generated scripts do not include that critical command.

Thanks for the answer, I'll apply that in the future. Just a shame that I wasted a good $1500 in labour time getting to my workaround.

[ZhangJennie]

Yes, it was a bit different. This worked in CW4.7.I don't find any document on this related. I am sorry for the inconvenience. I will feedback the team to improve it.

thank you for bringing the problem to our attention.

Have a great day,

Zhang Jun

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[ZhangJennie]

Hi,

can you please upload your project here? I need check it directly here. thanks!

Have a great day,
Zhang Jun

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[jsmcortina]

I cannot upload the project here as it is commercially sensitive.

I'll see if I can create a small test-case that replicates the problem.

James

[jsmcortina]

OK, so I've done some more digging. I trimmed my project down and have it spit out the values of some registers down the serial line after boot:

In non secure mode I'm programming:

*0xff0c = 0xcc

*0xff0f = 0xfe

On boot I see that:

*0xff0c = 0xcc

*0xff0f = 0xfe

FPROT = 0xcc

FSEC = 0xfe

This is exactly as it should be.

In secure mode, I'm programming:

*0xff0c = 0xcc

*0xff0f = 0x7d

On boot I see that:

*0xff0c = 0xcc

*0xff0f = 0x7c (incorrect!!)

FPROT = 0x7f (incorrect - full protection)

FSEC = 0xff (different value - secured)

This is WRONG!!!

According to the datasheet, the values in ff0c and ff0f are copied to FPROT and FSEC on boot unless there is a double bit-fault, in which case the device is set with full security and full flash protection.

I notice that the value in 0xff0f is incorrect and doesn't match the value in my code. I checked the generated S19 and .ABS files and they both match my code, so HIWAVE is causing the wrong value to go to flash. The Cyclone-Pro standalone doesn't do this.

Is HIWAVE silently doing something weird and programming these addresses twice? That could explain the incorrect value and the double bit fault.

My colleague confirms similar bad behaviour on his install with the current CW tools. It seems that something in HIWAVE has changed or there is a fault in the generated scripts?

[ZhangJennie]

Hi

regarding your latest reply. is this problem only in CW5.1? does CW4.7 have same problem?

because my computer currently doesn't have CW4.7 installed. I need classify the issue. thanks!

Have a great day,
Zhang Jun

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[jsmcortina]

This is with CW 5.1 Special Edition.

The latest P&E USB multilink drivers seem to have broken CW 4.7, it will never connect to the target, so I gave up trying to use it.

[ZhangJennie]

so may I understand your problem turns to as:

there is programming problem in CW5.1. but you don't test if it also work in CW4.7, right?

please send me the demo project for this issue under CW5.1. I will test the problem directly. thanks!

Have a great day,
Zhang Jun

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[trytohelp]

Jennie, James

There is a SR related to this question: 1-3881214301.

I don't know it this can help but I recommend you to install the last P&E firmware.

Please have a look to the post:

      Problem with Multilink Rev C - not running after MCU V10.6 Update4 installed & CW for MCF V7.2

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[jsmcortina]

Any thoughts on this? An equivalent image works ok on a Cyclone Pro.

James