Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Programming problems with MKL16 core #28

Open
PHBMOC opened this issue Apr 2, 2018 · 1 comment
Open

Programming problems with MKL16 core #28

PHBMOC opened this issue Apr 2, 2018 · 1 comment

Comments

@PHBMOC
Copy link

PHBMOC commented Apr 2, 2018

Hello,
I have several target MCUs in different devices I am working on. The pylink library is working great with STM32F401 cores, but I am having problems with an NXP MKL16Z64VFM4 chip.

Using JLink v6.30e, Windows 7, pylink 0.1.0 or 0.0.10
Running Segger J-Link Commander or J-Flash, it is reported that the protection settings in memory 0x400-0x40F indicate readout is disabled. Pressing "OK" triggers a mass erase and subsequent programming through that software succeeds.

However, I cannot do this through the pylink interface. Attempting to connect() to the device, I get one of several issues - not always the same. They include:

  1. WindowsError(-1073741795, 'Windows Error 0xC000001D')
  2. WindowsError('exception: access violation writing 0xCE941527',)
  3. WindowsError('exception: access violation reading 0xFFFFFFFF',)
  4. PCode returned with error code -1
    JLinkException('Unspecified error.',)

Since I cannot connect, I cannot unlock. Related to this, unlocking the Kinetis family appears to be supported in the library, but is it only a subset? I saw mention of K40 and K60 specifically - is the L family not supported?

So, my specific question is - do you have any suggestions for what might be wrong with the connection method? Any debugging tips?

Thanks in advance!

@hkpeprah
Copy link
Contributor

hkpeprah commented Apr 3, 2018

You can suppress that pop-up (only shows up on Windows actually) by calling disable_dialog_boxes() before calling open(). I believe the DLL has some logic around unlocking as well. I would also look at the unsecure_hook callback that you can pass to the constructor, as you can have that always return to always force unsecuring through the DLL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants