Hi everyone!
I've installed MCUXpresso IDE in Linux (Debian but I have seen the same behaviour in Ubuntu).
Following, my problem:
When I want to debug my lpcxpresso 1768/1769 REV B (the same behaviour for REV C and REV D) cannot find the target:
Some output console:
[Started server]
[Connected on port 3025]
redlink>ProbeList
No probes found
redlink>ProbeList
No probes found
redlink>ProbeList
No probes found
redlink>ProbeList
No probes found
redlink>ProbeStatus
redlink>quit
[Closed]
The project and the workspace are new ones, created from MCUxpresso itself.
-----------------------------------------------------------------------------------------------------------------------------------------------------------
But, if I try to debug with my old installation LPCXpresso v8.2, after the seek for any enabled emulator, I can debug without problems. Picture with LCPXpresso:
After pressing the button "Search for any...":
After that, if I use again MCUxpresso I can debug without problems.
All of above are repeat when I disconnect the tool from usb.
My problem is that I can't to migrate to MCUxpresso in these conditions.
Please, any suggest?
BR!
Mariano
Solved! Go to Solution.
Mariano
We have managed to replicate your problem.
MCUXpresso IDE (and LPCXpresso) uses a background server, the 'link server' to manage debug connections via multiple probes. It is visible in e.g. 'ps auxw | grep redlinkserv'. It is this service to which you issued the 'ProbeList' command - which is how the IDE locates the Link1 probe that is part of your LPC1769 board.
The link server comes and goes, but is more persistent in MCUXpresso IDE than in LPCXpresso. In MCUXpresso it can be terminated using the new 'Clean Up Debug' icon on the toolbar. It will simply be restarted when needed.
Your LPC1769 board's debug firmware is booted using the 'dfu-util' utility that is part of Debian/Ubuntu. An unbooted probe can be seen in the output of 'dfu-util -l'. Once booted 'lsusb' will show a different entry for the probe. The IDE detects whether the firmware is booted and reboots it if necessary. We believe that this part of the IDE is working perfectly in your case.
The link server detects only booted probes. It seems that, in your case, that if the probe is power cycled the IDE reboots the firmware but the link server does not register the new probe (even though it did before the power cycle).
Can you confirm that - when the probe discovery dialogue can not find the probe - you can cancel the discovery; then use the 'Clean Up Debug'; then find that the probe is then discovered properly?
Sincerely
MCUXpresso IDE Support
What is the actual version of Ubuntu that you have seen this issue on?
Is this Ubuntu running natively on your PC, or inside a virtual machine?
Do you see the same behaviour with the current MCUXpresso IDE v10.2 as well?
Can you check if your LPC-Link on your LPCXpresso1769 board appears both before it is booted and after it is booted (using lsusb or similar) ? [ This FAQ may assist in doing this : https://community.nxp.com/message/630541 . Although this was written for LPCXpresso IDE, the basic information still applies to MCUXpresso IDE. ]
Regards,
MCUXpresso IDE Support
Hi support, thank you so much for your reply.
My OS is Debian 9.4 and the Ubuntu that I have seen the same behaviour was 16.04 LTS (or 16.02 I don't remember well). Both cases running natively.
In Ubuntu, I have seen similar behaviour for MCUxpresso 10.2 (I can try in my Debian with 10.2 IDE, I will back soon with the results)
1) Before, and MCUxpresso working fine:
dmesg:
[ 382.838621] usb 1-2: new high-speed USB device number 4 using xhci_hcd
[ 382.978960] usb 1-2: New USB device found, idVendor=0471, idProduct=df55
[ 382.978966] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
lsusb:
Bus 001 Device 005: ID 1fc9:0009 NXP Semiconductors
2) Disconnect LPC1769 from the USB and back to connect (MCUxpresso cant see the target):
dmesg:
[ 1703.260660] usb 1-2: new high-speed USB device number 6 using xhci_hcd
[ 1703.401541] usb 1-2: New USB device found, idVendor=0471, idProduct=df55
[ 1703.401549] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
lsusb:
Bus 001 Device 006: ID 0471:df55 Philips (or NXP) LPCXpresso LPC-Link
3) After back to live with LPCxpresso IDE:
dmesg:
[ 1296.936481] usb 1-2: new high-speed USB device number 5 using xhci_hcd
[ 1297.081270] usb 1-2: New USB device found, idVendor=1fc9, idProduct=0009
[ 1297.081272] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1297.081273] usb 1-2: Product: LPC-Link Probe v1.3
[ 1297.081275] usb 1-2: Manufacturer: Code Red Technologies
[ 1297.081276] usb 1-2: SerialNumber: WIN64HS12
lsusb:
Bus 001 Device 007: ID 1fc9:0009 NXP Semiconductors
I could see that device changed from 6 to 7, and in some probe I have seen this when I use with LPCxpresso, maybe help you:
dmesg:
[ 1296.672755] usb 1-2: reset high-speed USB device number 4 using xhci_hcd
[ 1296.812605] usb 1-2: device firmware changed
[ 1296.812732] usb 1-2: USB disconnect, device number 4
[ 1296.936481] usb 1-2: new high-speed USB device number 5 using xhci_hcd
[ 1297.081270] usb 1-2: New USB device found, idVendor=1fc9, idProduct=0009
[ 1297.081272] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1297.081273] usb 1-2: Product: LPC-Link Probe v1.3
[ 1297.081275] usb 1-2: Manufacturer: Code Red Technologies
[ 1297.081276] usb 1-2: SerialNumber: WIN64HS12
Thank you so much!
Mariano
Mariano
We have managed to replicate your problem.
MCUXpresso IDE (and LPCXpresso) uses a background server, the 'link server' to manage debug connections via multiple probes. It is visible in e.g. 'ps auxw | grep redlinkserv'. It is this service to which you issued the 'ProbeList' command - which is how the IDE locates the Link1 probe that is part of your LPC1769 board.
The link server comes and goes, but is more persistent in MCUXpresso IDE than in LPCXpresso. In MCUXpresso it can be terminated using the new 'Clean Up Debug' icon on the toolbar. It will simply be restarted when needed.
Your LPC1769 board's debug firmware is booted using the 'dfu-util' utility that is part of Debian/Ubuntu. An unbooted probe can be seen in the output of 'dfu-util -l'. Once booted 'lsusb' will show a different entry for the probe. The IDE detects whether the firmware is booted and reboots it if necessary. We believe that this part of the IDE is working perfectly in your case.
The link server detects only booted probes. It seems that, in your case, that if the probe is power cycled the IDE reboots the firmware but the link server does not register the new probe (even though it did before the power cycle).
Can you confirm that - when the probe discovery dialogue can not find the probe - you can cancel the discovery; then use the 'Clean Up Debug'; then find that the probe is then discovered properly?
Sincerely
MCUXpresso IDE Support
Hi dear support,
I installed 10.2 version (and fixed the "Null pointer" error by enabling "shared file" in the debug configuration).
Later, with the use the 'Clean Up Debug' suggested by you finally I could debug my lpcxpresso LPC1769.
So, thank you so mucho for your appreciate help!
BR
Mariano
Dear support, thank you so much again for your reply.
I had to upgrade to MCUxpresso v10.2 since the "Clean debug button" didn't appear (or I can't found it) in my older 10.1 version.
And, what now?
When I try to debug my lpc1769 stick, the following message appears:
I tried to do a new Workspace, new project but the final result is the same.
I have seen before this error weeks ago, and I remember that the solution was do a downgrade to 10.1 version (note that I am in a kind of infinite loop :smileyhappy:) but the new problems that rised, were regard to a this discussion.
Believe me, my next discussion was going to be the java.lang.NullPointerException.
I will wait for your comments!
BR
Mariano