How to unlock MC56F84xxx via JTAG Interface?

[larryyang]

Xeltek, a programmer manufacture, is developing programmer for MC56F84550. They found that after send mass erase command (FTFA, mass erase command) the MCU will be locked.

We try to execute erase all blocks command, then modify the flash control block, but the chip still can't unlock.

Before modify flash control block, we try the following two ways to judge whether the Flash erase is finished.

(1) Time delay, then modify the flash control block.

(2) Read FSTAT register to judge whether the erase is finished, but the readout register is always 0. Then modify the flash control block.

Whether the operation is right? if not, If there are other ways to unlock MC56F84550?

[johnlwinters]

On 3/9/2015 the procedure above is clarified.

Note the comments in red in the above scripts.

This may solve any issues you may be having currently.

Note: the reset pin of the SOC does not need to be active for this sequence to work.

However, the flash is not actually unlocked until a reset is performed after doing this sequence.

[johnlwinters]

:smileyalert: CAUTION 

When using JTAG signals, power the target prior to applying the JTAG signals.

When removing power from the target, remove the JTAG signals first.

Applying voltage to RESETB whilst the target is powered off may disturb the flash contents.:smileymischief:

[johnlwinters]

The following commands are used with the Freescale USB TAP.  They can be easily tranlated to a flash programmer vendor's environment.

Comment lines begin with a "#" character.

Commands addressed to ccs (command coverter server) begin "ccs".

Commands addressed to the JTAG begin "jtag".

#configure the command converter server for the hawkv3 (MC56F84xxx)

ccs::config_chain hawkv3

#lock the jtag interface so that ccs will not allocate it to another instance

jtag::lock

#advance the jtag state machne to reset to the known starting state

jtag::state_move test_logic_reset

#Read the data register to check the device ID

jtag::scan_in dr 32

#0x16B4801D, just to check idcode, optional step

#tlm select to instruction register

jtag::scan_out ir 8 5

#chip select to instruction register

jtag::scan_out dr 4 1

#Chip Tap Test Control Unit Register "Flash tdr Register" selected by JTAG instruction '9'

# "Flash tdr Register" width is 16 bits.

jtag::scan_out ir 8 9

#BIt zero of the "Flash tdr Register" is ftfl_erase_all_req, which when set will initiate an erase of all the flash and the returning of the flash to the unsecured state.

#This bit zero is first set, then a period of time later, cleared.  The setting kicks off an errase.

jtag::scan_out dr 16  1  #NOTE: at a lower level of abstraction this gets changed to 0x8001 instead of 0x0001.  The MSB is the write_enable bit added for saftey.

                                     #            The write_enable bit purpose is to make sure that two things and not just one thing is changed to perform the flash erase to avoid accidental flash erase.

jtag::scan_out dr 16 0   #this is key to making this work.  Do not check status.  Just turn this off on next command.

                         #must deassert between 6usec and 16ms after assertion.  Too soon, and may not errase.  To late,and may start another

                         #errase cycle!

                         #NOTE: at a lower level of abstraction this gets changed to 0x8000 instead of 0 since it will not clear unless the write enable bit is also set.

                         #Further more, immediately after the write of 0x8000, 0x0000 is written to clear the write enable bit to guard against accidental flash commands.

#Note:  Bit one of the above register, Flash tdr, is a status bit that operates as follows so that the end of the erasure cycle is signaled:

# SoC erase all acknowledge is bit one of Flash tdr.

# ftf_erase_all_ack is initiated by rising edge (set to one) on a rising edge of soc_erase_all_req.

# ftf_erase_all_ack will go low after the

# erase operation has completed, so wait for this bit to go to zero prior to reseting the device.

#allow other instances to use the jtag

jtag::unlock

#reset to debug state

ccs::reset_to_debug

# only after the reset to the debug state is the chip then unprotected and ready to be programmed.

Best Regards,

John L. Winters

Senior Applications Engineer

AMR/EU MCU & MPU AE Group

Freescale Inc.

2100 Elliot Road

This email and any associated attachments have been classified as:

Freescale Confidential and Proprietary

[larryyang]

The customer still have doubt about the commands, could you help answer the questions marked by blue color?

1. What's the ccs command and how to carry it out ?  could pls. tell me the detailed step. I can not find any illustration in the spec.
2. how to implement  jtag::lock and jtag:unlcok?
3. about the the following steps:

#tlm select to instruction register

jtag::scan_out ir 8 5                   

this instrunction changes to core tap,right?

#chip select to instruction register

jtag::scan_out dr 4 1

#flash tdr

jtag::scan_out ir 8 9

the instruction is 4 bit when using core tap ,what's the meanning of this command?

#ftfl_erase_all_req

jtag::scan_out dr 16 1

jtag::scan_out dr 16 0

does it mean 6us-16ms delay must be added after these two command? and the chip will be unsecure

[johnlwinters]

The customer still have doubt about the commands, could you help answer the questions marked by blue color?

1. What's the ccs command and how to carry it out ?  could pls. tell me the detailed step. I can not find any illustration in the spec.
   1. This is just a way to implement using the JTAG interface.  The calls are self expanatory. 
2. how to implement  jtag::lock and jtag:unlcok?
   1. You do nothing for this.  It is just saying that no other process should use that JTAG interface while you are doing this operation. 
3. about the the following steps:

#tlm select to instruction register

jtag::scan_out ir 8 5                   

this instrunction changes to core tap,right?

We cannot provide further explanation about the proprietary internal structure of these registers.

#chip select to instruction register

jtag::scan_out dr 4 1

#flash tdr

jtag::scan_out ir 8 9

the instruction is 4 bit when using core tap ,what's the meanning of this command?

We cannot provide further explanation about the proprietary internal structure of these registers.

#ftfl_erase_all_req

jtag::scan_out dr 16 1

jtag::scan_out dr 16 0

does it mean 6us-16ms delay must be added after these two command? and the chip will be unsecure

It means between the ..16 1 and the ..16 0 commands there must be at least 6us and no more than 16ms.

If less, the erase all will not be complete.  If more, a second erase all opoeration will begin and may not be completed.

[larryyang]

For the secured chip ,the customer tried several times, the unlock issue still unsolved. Could you help check whether the code is right?

---------------------------------------------------------------------------------------------------------------------------------------------------

  init（）；//initialize the chip, including power on ,set pins state

RESET=0;

TMS=1;        //reset JTAG

for (i=0;i<5;i++)

{

      TCK=1;

      TCK=0;

}

TMS=0;

  TCK=1;

  TCK=0;

IRSCAN(0x02,8);//IR scan 8bit instruction 0x02 to read chip ID

DRscan(0x00,32);// read 32 bit ID ,it's 0x16b4801D

IRScan(0x05,8);

DRScan(0x01,4);

// RESET=1;        //is it necessary?

IRScan(0x09,8);
DRScan(0x0001,16);
DelayMs(8);
DRScan(0x0000,16);

TMS=1;        //reset JTAG

for (i=0;i<5;i++)

{

      TCK=1;

      TCK=0;

}

TMS=0;

  TCK=1;

  TCK=0;

IRScan(0x05,8);   //change to core tap
DRScan(0x02,4);

IRScan(0x02,4);    //read core ID
DRScan(0,32);    //read core ID,it's 0x61C0301D

IRScan(0x07,4);    //debug request

RESET=1;

DelayMs(5);

IRScan(0x06,4);    //enable EonCE, and get 0x0d correctly

eonce_rd_xaddr(0xE3C0,0); //read FSTAT register,it is always 0  if the chip is secured and it's 0x80 if not secured

[johnlwinters]

I cannot see where the customer has followed the advice posted earlier. This script does not seem to be correct.

Best Regards,

John L. Winters

Senior Applications Engineer

AMR/EU MCU & MPU AE Group

Freescale Inc.

2100 Elliot Road

This email and any associated attachments have been classified as:

Freescale Confidential and Proprietary

[pgo]

Hi John,

Coincidently, I found myself looking for exactly this information last night - and here it was ready and waiting.

I have used it with USBDM successfully.

Follow-up:

I do have a couple of questions which you may be able to answer:

• The 6us and 16ms timing seems strange.  According to the data sheet the "Erase all Blocks" command can take from 175 ms to 1500 ms depending on device Flash wear etc.  I would expect a mass-erase to be comparable. Are the values you give the limits for initiating the command or the actual expected erase times?
• If the above initiates the command is there a required delay before resetting the device after the above sequence so as to not interfere with the mass-erase?  Is there a way to poll the device?
• Is there a reliable way using JTAG to determine if the device is secured.  Currently I read the FSEC value and assume a value of zero means secured (or actually any value not ending in 'b01).

Thanks.

[johnlwinters]

Try just one millisecond delay. I will check the rest more carefully later.

Best Regards,

John L. Winters

Senior Applications Engineer

AMR/EU MCU & MPU AE Group

Freescale Inc.

2100 Elliot Road

This email and any associated attachments have been classified as:

Freescale Confidential and Proprietary

[larryyang]

Thanks John!

[johnlwinters]

In the case of MC56F82xxx, the answer is below:

The following script may be used with a USB TAP, or the primitive commands in the latter part of the script may be adopted to other debugging and programming systems.

The script follows.

--------------------------------cut here-------------------------------------------

#This is a CCS script, Command Converter Server
#It is in play with the Freescale USB TAP
#These commands may be entered at the console window of CCS
#CCS can be initiated from the Freescale directory, the same directory that CW10.5 is located in.
#These are generic JTAG commands for MC56F82xxx (not MC56F82xx) to mass errase the device, even when locked.

#these command tell CCS what kind of device is being dealt with and prepare the utap to respond to the script:
#these commands are generic and already in use by vendors for other DSC devices:

delete all
config cc utap
show cc
ccs::config_chain hawkv3
display ccs::get_config_chain
ccs::reset_to_debug
ccs::config_template 0 18 0
after 1000
ccs::reset_to_debug
after 100

# you can ignore the commands above this line, since they are just to set up the USB TAP.  Below is what is needed at a low level to errase the flash:

#The jtag::lock command does not lock the flash.  It locks the CCS protocol at the jtag level, the level below the ccs level
#When locked with the jtag::lock command, ccs commands will be ignored, and only jtag command will be recognized.
#jtag commands can be input with hbug for most DSC devices (accept Anguilla Silver).  They can be input with CCS.
#A vendor who is making a product to talk to jtag will likely have their own jtag command API to which the following script may be apapted:

jtag::lock

#the following command, state_move, is used to move the JTAG state machine to the test_logic_reset state.

jtag::state_move test_logic_reset

#this command shifts 32  dr (data register) bits from the target to the host, shifting in all zeros to the dr.

jtag::scan_in dr 32
#0x16B4801D, just to check idcode, optional step

# shift 8 bits of data binary 00000101 from the host to the instruction register (ir) of the target to effect
# tlm select.  tlm is tap link mode, one of two major states of the jtag machine, as in all DSC devices.
jtag::scan_out ir 8 5

# shift 4 bits of data binary 0001 from the host to the data register of the target to effect chip select
# chip select
jtag::scan_out dr 4 1

# shift 8 bits of 00001001 to the instruction register, ir from the host to the target to effect
# flash tdr
jtag::scan_out ir 8 9

#this is the mass errase, shift 16 bits of data 0000000000000001 to the data register from the host to the target device to effect mass errase
# ftfl_erase_all_req
jtag::scan_out dr 16 1  #NOTE: at a lower level of abstraction this gets changed to 0x8001 instead of 0x0001.  The MSB is the write_enable bit added for saftey.

                                     #            The write_enable bit purpose is to make sure that two things and not just one thing is changed to perform the flash erase to avoid accidental flash erase.
jtag::scan_out dr 16 0   #this is key to making this work.  Do not check status.  Just turn this off on next command.
                         #must deassert between 6usec and 16ms after assertion.  Too soon, and may not errase.  To late,and may start another
                         #errase cycle!

                         #NOTE: at a lower level of abstraction this gets changed to 0x8000 instead of 0 since it will not clear unless the write enable bit is also set.

                         #Further more, immediately after the write of 0x8000, 0x0000 is written to clear the write enable bit to guard against accidental flash commands.

#the jtag::unlock command only puts the CCS into a state where it can accept normal ccs command, not the low level jtag commands.
jtag::unlock

[sm0khey]

Hello, John!

Do you have the code for MC56F82XX versions?

[sinanakman]

Hi John

Do you have the list of ccs and jtag commands

available. This would be handy.

Regards

Sinan Akman