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

Device list different from Jlink.exe #32

Open
rcaproni opened this issue May 4, 2018 · 17 comments
Open

Device list different from Jlink.exe #32

rcaproni opened this issue May 4, 2018 · 17 comments

Comments

@rcaproni
Copy link

rcaproni commented May 4, 2018

Hello:
I'm working with NXP's MCIMX7U5_M4 processor. Using Jlink Commander 6.32a, I can connect to JTAG port and debug. If I do not pass the "-device MCIMX7U5_M4" paramenter on command line, the SEGGER J-link Target Device Settings selection menu opens and I can find the correct device name.
In python, when connecting using pylink, the MCIMX7U5_M4 is not accepted as a valid device.
jlink.connect(verbose=True, chip_name="MCIMX7U5_M4")
When I cannot pass chip_name= in the connect method, the device selection menu opens, but the MCIMX7U5_M4 is not present in the device list. The number of devices in the pylink connection is lower than the number in Jlink Commander.

I'using WIN10.
Jlink version 6.32a
Python 3.6 (pycharm 2018.1.2)
pylink 0.1.0

I debugged the DLL loading and it is copying it from correct path: C:\Program Files (x86)\SEGGER\JLink_V632a\JLinkARM.dll.

Thanks
mcimx7

@hkpeprah
Copy link
Contributor

hkpeprah commented May 4, 2018

Hm, the number should be same if the Window pops up. What do you mean by cannot pass in chip_name?

Are you sure that's the correct chip name? Doing a Google search leads me to few results, one being this Kinetis document, and this thread, which points to this page: https://wiki.segger.com/IMX_Series_Devices

@rcaproni
Copy link
Author

rcaproni commented May 4, 2018

At the image I posted you can see what happens when I use chip_name="MCIMX7U5_M4". The Target Device Settings selection menu opens, as it not recognize MCIMX7U5_M4 as a valid chip name. The same occurs when I leave chip_name with the default value (jlink.connect(verbose=True))
Using Jlink.exe, I do not have this problem:

jlink -device MCIMX7U5_M4 -speed 1000 -JTAGConf -1,-1
SEGGER J-Link Commander V6.32a (Compiled Apr 30 2018 15:45:20)
DLL version V6.32a, compiled Apr 30 2018 15:44:54

Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware version: V8.00
S/N: ************
OEM: IAR
VTref=3.144V

Type "connect" to establish a target connection, '?' for help
J-Link>con
Device "MCIMX7U3_M4" selected.


Connecting to target via JTAG
***************************************************
J-Link script: iMX7ULP Cortex-M4 core J-Link script
***************************************************
TotalIRLen = 4, IRPrint = 0x01
***************************************************
J-Link script: iMX7ULP Cortex-M4 core J-Link script
***************************************************
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x6BA00477, IRLen: 04, CoreSight JTAG-DP
AP map detection skipped. Manually configured AP map found.
...
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
...
Disabling Cortex-M4 MPU ...
Cortex-M4 identified.

@hkpeprah
Copy link
Contributor

hkpeprah commented May 4, 2018

Have you tried passing in device_name=iMX7ULP? There may be some internal logic present that is doing the mapping from MCIMX7U3_M4 to iMX7ULP.

@rcaproni
Copy link
Author

rcaproni commented May 4, 2018

Not work too. IMX7ULP is not recognized as valid chip_name.
There is a significant difference between the devices available in the list when you are using Jlink and when using pylink. Maybe is related with the loading of the DLL library? I forgot to mention that my machine is 64 bits.

This is the Jlink list:
x7_ok

This is the pylink list:
x7_nok

@hkpeprah
Copy link
Contributor

hkpeprah commented May 4, 2018

I would take a look at this issue, as it could be a 32-bit vs 64-bit issue. I'm not entirely sure what's going on here.

@ChaoticEnigma
Copy link

I am struggling with a similar issue on Linux. I have added entries for an ARM MCU to JLinkDevices.xml in /opt/SEGGER/JLink, and written a flash loader for this device, for use with JLinkExe (J-Link Commander). This works great, however, pylink does not recognize the new device entries. Clearly, pylink (or the JLink library) is not loading the same file.

My understanding is that the JLink library reads supported devices from a JLinkDevices.xml. I have four of these files and coresponding Devices directories containing various flash loaders, between JLinkExe, Ozone, and SEGGER Embedded Studio. They are in:

/opt/SEGGER/JLink/
/opt/SEGGER/JLink/JLink_Linux_V632g_x86_64/
/opt/SEGGER/Ozone/Lib/
/opt/SEGGER/segger_embedded_studio_for_arm_3.34a/bin/

pylink loads libjlinkarm from /opt/SEGGER/JLink/libjlinkarm.so

Even after replacing each JLinkDevices.xml with

<DataBase>

  <Device>
   <ChipInfo Vendor="Holtek" Name="HT32F1654" Core="JLINK_CORE_CORTEX_M3" WorkRAMAddr="0x20000000" WorkRAMSize="0x00004000" />
   <FlashBankInfo Name="Internal Flash" BaseAddr="0x00000000" MaxSize="0x0000FC00" Loader="Devices/Holtek/FlashLoader_HT32F1654.elf" LoaderType="FLASH_ALGO_TYPE_OPEN" AlwaysPresent="1" />
  </Device>
  <Device>
   <ChipInfo Vendor="Holtek" Name="HT32F1655" Core="JLINK_CORE_CORTEX_M3" WorkRAMAddr="0x20000000" WorkRAMSize="0x00008000" />
   <FlashBankInfo Name="Internal Flash" BaseAddr="0x00000000" MaxSize="0x00020000" Loader="Devices/Holtek/FlashLoader_HT32F1655.elf" LoaderType="FLASH_ALGO_TYPE_OPEN" AlwaysPresent="1" />
  </Device> 

</DataBase>

which JLinkExe works fine with, in pylink, jlink.num_supported_devices() is still >6000.

So where in the world is libjlinkarm getting its device list from? Does pylink have its own list, or is it built in to libjlinkarm?

Any suggestions are appreciated.

@hkpeprah
Copy link
Contributor

hkpeprah commented Jul 30, 2018

Hm, from a cursory examination, it seems to be baked into the .so file. I'm not sure if there is a way to dynamically add a new device definition (as I've never looked into it), but this definitely seems like a good feature. I'll investigate a bit more when I have some free time, and see if it's possible.

@djgood
Copy link

djgood commented Mar 14, 2019

I ran into a similar issue recently. My RSL10 device was failing to download a .hex file to flash memory using JLink.flash_file(). To flash the RSL10, it requires some information and code in the Devices folder which is normally in the same directory as the DLL files. I think it was not working because the DLL is being copied to a temporary location and then loaded, meaning the Devices folder cannot be found, since they are no longer in the same directory. I was able to fix the issue by loading the original DLL instead of the temporary one in the Library.load() function. I hope this helps anyone facing the same issue!

@hkpeprah
Copy link
Contributor

@djgood Ah, that's interesting. If you copy the XML file alongside the DLL, does it work? If so, we might be able to add support for copying the XML file / directory, then methods for adding new devices programmatically.

@djgood
Copy link

djgood commented Mar 14, 2019

I just tried it, and yes, it works if I copy the XML and directory to my temp folder.

@freyc
Copy link

freyc commented Sep 24, 2019

By the way, another solution seems to be calling exec_command with the J-Link Commandstring JLinkDevicesXMLPath (inspired by this link):

jlink = pylink.JLink()
jlink.open()
jlink.exec_command('JLinkDevicesXMLPath /opt/SEGGER/JLink/JLinkDevices.xml')

With this solution, you can even provide your own device-list, without having to change the one from the original installation.

@tianxiaoMCU
Copy link

JLink.exe can export the DLL internal device list, how to do this by pylink

image

@bigbrett
Copy link

bigbrett commented Jan 15, 2020

I'm seeing this issue on my end too. Having to pass a path makes writing cross platform code difficult. Any idea why the installed JLinkDevices.xml isn't being honored?

@sergio-soar-es
Copy link

I also faced this issue before I discovered this thread.

In my case, I found a workaround by modifying the tempdir. Pylink creates the dll in a temporary folder. So, if you just set tempfile.tempdir to your JLink installation path, it works because the temporary dll created by Pylink will be in the same directory of the JLinkDevices.xml.

This is probably not the cleanest workaround, especially because you will need permission to write on the JLink installation directory but it may be useful for some people.

@pratimshah111
Copy link

pratimshah111 commented Mar 26, 2020

Could someone please post the solution here in terms of how to change the temp location to fixed location in Library.load() function? I tried but didn't quite correctly work for me.
I changed it to following:
self._lib = ctypes.cdll.LoadLibrary(self._path)

Now I can see my device in the list but after connecting to that device, it gives 7676 and when I query jlink.target_connected(), it gives false. So, not sure what is wrong

@oszalex
Copy link

oszalex commented Nov 4, 2020

I had the same issue, that the chip name was not accepted as a valid device. For me the solution was to set the the target interface to SWD after opening the jlink.
jlink.open(serno)
jlink.set_tif(pylink.enums.JLinkInterfaces.SWD)

@kettenbach-it
Copy link
Contributor

By the way, another solution seems to be calling exec_command with the J-Link Commandstring JLinkDevicesXMLPath (inspired by this link):

jlink = pylink.JLink()
jlink.open()
jlink.exec_command('JLinkDevicesXMLPath /opt/SEGGER/JLink/JLinkDevices.xml')

With this solution, you can even provide your own device-list, without having to change the one from the original installation.

This works for me!

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

No branches or pull requests