Can't connect the device if the device had been secured.

[ltbkey]

l used the script below, but if the device had been secured, the script occurs error.

Init the jlink

jlink = pylink.JLink()

# Open a connection to your J-Link.
jlink.open(serial_no)

# Set SWD as the interface
jlink.set_tif(pylink.enums.JLinkInterfaces.SWD)

# Connect to the target device.
jlink.connect('stm32f301k8',4000, verbose=True)

the error is shown below.

Traceback (most recent call last): File "jlink_flash.py", line 49, in jlink.connect('stm32f301k8',4000, verbose=True) File "D:\APP\Python27\lib\site-packages\pylink\jlink.py", line 141, in wrapper return func(self, *args, **kwargs) File "D:\APP\Python27\lib\site-packages\pylink\jlink.py", line 910, in connect result = self._dll.JLINKARM_Connect() WindowsError: exception: priviledged instruction

I tried to use "unlock()", but it didn't work.

jlink.unlock() #does not work

Looking forward your help! Thank you!

[hkpeprah]

This doesn't seem to be a secured issue. WindowsError generally indicates a Windows system call error. This could be related to what is being fixed by PR #25, so I'd give that a go. If not, I'd check to see if your system has weird permissions.

[ltbkey]

Thank you for your reply! I have checked PR #25, and tested the new library.py, it did not work because my python version is on win32. My script "jlink_flash.py" should find the "JlinkARM.dll", is that right? Thank you again!

[ltbkey]

Hi @hkpeprah , I made more tests. JLink_x64.dll does not affect the connection between jlink and device. I deleted "JLink_x64.dll" in JLink_v620, J-Flash and J-Link commander work correctly: connecting, securing, reading, programming. So the issue just is that "jlink.py" can't connect device if the device had been secured. One more test, if a device had been secured, I used J-Link commander to connect the device, connected successfully, and the device was erased too. Then "jlink.py" worked correctly. Thanks!

[hkpeprah]

We currently have not implemented an unlock method for the STM32 in PyLink FWIW.

[sstallion]

How difficult would it be to implement? This is just a single call into the SDK, right?

On Wed, Mar 28, 2018 at 2:36 PM, Ford notifications@github.com wrote:

We currently have not implemented an unlock method for the STM32 in PyLink FWIW.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/square/pylink/issues/27#issuecomment-377009328, or mute the thread https://github.com/notifications/unsubscribe-auth/AFtLiL1gY10SyMK8nsDz-gEK_JUqIOANks5ti-YogaJpZM4S8_cP .

[hkpeprah]

Nope. The SDK has no unlock method. The one that exists for Kinetis is based on Freescale's specification.

[sstallion]

Ah, gotcha. So relatively painful - is there something from JLinkExe that could be used for inspiration?

On Wed, Mar 28, 2018 at 2:45 PM, Ford notifications@github.com wrote:

Nope. The SDK has no unlock method. The one that exists for Kinetis is based on Freescale's specification.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/square/pylink/issues/27#issuecomment-377011981, or mute the thread https://github.com/notifications/unsubscribe-auth/AFtLiPzuu88XOvrywTTtagm7gktegQHtks5ti-g_gaJpZM4S8_cP .

[hkpeprah]

Maybe. But I imagine that there's a spec out there that we can follow. And OpenOCD probably has something as well that we could look at (I did this for the Kinetis one as well), though the first step would be getting a board.

[sstallion]

I might take a look at it if I can find the time. I do have an STM32F207 board handy I can test with.

[ltbkey]

Thank you both! @hkpeprah, @sstallion Looking forward a good news. It doesn't matter that chip is erased after the connection. Thank you again.

[Moral-ecomo]

Hi: I just fix this problem, the remove need two steps: 1、modify the pylink source code 2、

def unsecure_device_hook(title, msg, flags):
    return pylink.enums.JLinkFlags.DLG_BUTTON_YES

...
jlink = pylink.JLink(unsecure_hook=unsecure_device_hook)
...