Hi Guittet,
USBDM should be able to unsecure a Kinetis device providing the unsecure function has not been disabled. There may be some connection problems due to watchdog issues etc but I have not seen these with an entirely blank chip. There are issues if the device has been programmed with invalid information.
I don't have a pristine device to test with. The only devices I have, have been previously programmed. The best test I can do is to erase a chip and re-program it to a secured state. USBDM works OK with this. I believe Freescale distribute the chips in an unsecured condition.
I'm unsure what situation is causing the program.
If you have the patience you can use the attached script to try to see what is going wrong with the mass erase of the device.
- Save the attached text as a TCL script try.tcl in the USBDM installation root directory (.../USBDM 4.10.5).
- Start the USBDM TCL Interpreter from the USBDM menu
- Type source try.tcl
- It should produce one of the results commented in the script below. The second result indicates the chip is failing to unsecure (rather than some bug).
Bye
PS. The forum doesn't like the attachment - which is not surprising since it's a script that could potentially do anything to your machine!
I've added it inline - you can assess the risk to running it 
.
openbdm
settarget arm
source devicedata/arm/Kinetis-KLxx-flash-scripts.tcl
massEraseTarget
closebdm
# Expected successful results for a secured chip (mass erase not disabled)
#
# Found 1 devices
# USBDM DLL Version = 4.10.5.0
# BDM Version = HW=97, SW=4A
# USBDM DLL Version = 4.10.5.0
# BDM Version = HW=97, SW=4A
# :setTarget ARM
# bytesex => Little-endian
# :pinSet 0x8
# :rCreg r=0x1000004(MDM_AP.Control)->0x00000000
# :wCreg r=0x1000004(MDM_AP.Control)<-0x00000019
# :wCreg r=0x1000004(MDM_AP.Control)<-0x00000011
# :rCreg r=0x1000004(MDM_AP.Control)->0x00000010
# :wCreg r=0x1000004(MDM_AP.Control)<-0x00000000
# :reset 0x08(SOFTWARE, SPECIAL)
# %
# Expected unsuccessful results for a secured chip (mass erase disabled)
# % source try.tcl
# Found 1 devices
# USBDM DLL Version = 4.10.5.0
# BDM Version = HW=97, SW=4A
# USBDM DLL Version = 4.10.5.0
# BDM Version = HW=97, SW=4A
# :setTarget ARM
# bytesex => Little-endian
# :pinSet 0x8
# :rCreg r=0x1000004(MDM_AP.Control)->0x00000000
# :wCreg r=0x1000004(MDM_AP.Control)<-0x00000019
# :wCreg r=0x1000004(MDM_AP.Control)<-0x00000011
# :rCreg r=0x1000004(MDM_AP.Control)->0x00000001
# :rCreg r=0x1000004(MDM_AP.Control)->0x00000001
# :rCreg r=0x1000004(MDM_AP.Control)->0x00000001
# :rCreg r=0x1000004(MDM_AP.Control)->0x00000001
# :rCreg r=0x1000004(MDM_AP.Control)->0x00000001
# :rCreg r=0x1000004(MDM_AP.Control)->0x00000001
# :rCreg r=0x1000004(MDM_AP.Control)->0x00000001
# :rCreg r=0x1000004(MDM_AP.Control)->0x00000001
# :rCreg r=0x1000004(MDM_AP.Control)->0x00000001
# :rCreg r=0x1000004(MDM_AP.Control)->0x00000001
# :rCreg r=0x1000004(MDM_AP.Control)->0x00000001
# :wCreg r=0x1000004(MDM_AP.Control)<-0x00000001
# :reset 0x08(SOFTWARE, SPECIAL)
# Flash mass erase failed
# %
!
Hello PGO,
I looked at the datasheet, but I'm a little bit confused.
First of all, here is the result of the script: MDM AP Status = 0x34
Note that I had to add "catch { connect }" to your script, just after calling "Kinetis-KLxx-flash-scripts.tcl".
Ok, so, according now to the datasheet:
- Flash Mass Erase Acknowledge bit (0) is not set.
- Flash Ready bit (1) is not set. By reading the description, I'm not sure this is correct...
- System Security bit (2) is set . Again, not sure this is correct...
- System Reset bit (3) is not set, indicating that the system is in reset. Is it normal ?
- Reserved bit (4) is set.
- Mass Erase Enable bit (5) is set, so it seems that mass erase is enabled.
I don't know really how to interpret this. I have no Kinetis device to compare the result.
EDIT:
- What is the SEC setting ? Is it System Security bit ?
- Another post with maybe quite the same issue: Re: Kinetis K20 - unable to debug. I have tried to force reset pin low but this make no difference. According to your Kinetis TCL script, this is what you are doing throw the USBDM.
Thanks for your help.
Best Regards,
Joel Guittet
Note: I have several KL05 devices, maybe I can try with another one....
Hi PGO,
Yes I have a scope, I have recorded a trace looking at RST and BKGD signals and pressing "Detect chip" button in the ARM programmer.
This is done with the device I can't erase, so it fails. After power up and after the connection of the USBDM to the target, there is an oscillation of the RST signal (about 500Hz), probably because the device is continuously reseting.
I have tested your script and checked again the signals. I see the RST line going low, then the three state status (with the capacitor which is charging) and then it is low again.
I will now work with the chip I succeeded to erase and program, and I will keep the first one (maybe I will succeed to unlock the Security Bit later).
Thanks again for your help and your time,
Best Regards,
Joel Guittet
Hi zq c,
The SWD is based on JTAG protocol. Input data is clocked on the rising clock edge, output data is appears on falling edge (so as to be valid on next rising edge). However the only requirements have to do with the rising clock edge.
According to JTAG specs the input data to target should be valid a tsu before and thld after the rising clock edge. However, thld is usually zero.
I haven't had any communication problems so I would think the timing I'm using is correct.
I can't comment on what other interfaces do.
This seems consistent with the data sheets for the kinetis devices e.g. 6.1.1 JTAG electricals of the K20P48M50SF0 data sheet
or the 6.1.1 SWD Electricals of the KL05P48M48SF1 data sheet.
bye
PS. Why are you posting on this thread?
