Hello.
I have a strange problem with MCULink on LPCXpresso55s36 board. OS is Windows 10.
I should highlight that I have successfully programmed it under Ubuntu.
I simply cannot update MCULink firmware under Windows. The board is in ISP mode. The board is detected and enumerated as HID-compliant vendor-define device.
When running program_CMSIS.cmd (or JLINK, no difference), the script is stuck when I press "any key" (so the script doesn't even complain it cannot find the probe/the probe is not in ISP mode etc.).
Trying to debug the problem, I went to blhost (with admin rights) and ran a line from *.cmd script:
That's it, nothing happens after that. Moreover, I cannot close the powershell, and blhost.exe process is absolutely unkillable.
What I can guess, the problem is related to permissions, access rights etc. But no response from blhost makes it super hard to track. Also I am not sure where to even look for permissions for USB...
Summary:
blhost doesn't get reply from MCULink AND hangs forever without any response, the process is unkillable. Ctrl+C doesn't help too.
I could not find any posts even remotely like that, so I am very curious about the reason for such behavior.
EDIT: By the way, after updating MCULink (CMSIS) from Ubuntu, I can program MCU just fine from Windows + MCUXpresso IDE.
已解决! 转到解答。
First of all, firewall has nothing to do with it. That's not how blhost works.
I disabled it anyway. No luck. Reinstalling? Tried several times with several versions.
Okay, I've opened the source code of blhost, and then of libusbsio. Figured out the exact line where the process hangs (inside hid_write_timeout function for anyone wondering).
Thanks to Visual Studio Debugger, I have identified what process/program interferes with blhost in such a weird way. Not going to name it, but it is indeed (partially) security-related. It was not obvious, though! Uninstalled (though I think simply killing the related process before running blhost would be enough) and blhost FINALLY works.
This was too specific, and would hardly happen again to anyone. Otherwise - go and debug the code yourself, it is the only way.
Yes, I refer to these steps. Which I follow to the dot. The board is in ISP mode: D16 is on, the board is enumerated as HID device (VID 0x1FC9, PID 0x0021).
I have no idea about the version of the board. Although the marking says WO-**-2308, which I guess yyww?So it should be fresh. Both MCUs are from last year, based on markings.
I have tried version 3.108 of MCULink installer.
I repeat, I have successfully updated the MCULink firmware to version 3.108 using Ubuntu.
Hello, @Alice_Yang .
Thank you. Of course it is working fine. It is not supposed to happen, otherwise it would have been mentioned already by other users.
That was not my question anyway.
I have even tested it on another PC in my company, guessing it might be security software interfering, but it worked (updating MCULink firmware with program_CMSIS.cmd via blhost).
USB ports and cables on my PC are also okay: I can (now) flash and debug the target MCU in MCUXpresso IDE. However, the said MCULink firmware update tool is still not working on my PC.
So, again: I am not talking about bugs in software. My question is, let me clarify:
What might be the reason for blhost hanging with no response when get-property/set-property command is executed on Windows 10?
Simply curious.
First of all, firewall has nothing to do with it. That's not how blhost works.
I disabled it anyway. No luck. Reinstalling? Tried several times with several versions.
Okay, I've opened the source code of blhost, and then of libusbsio. Figured out the exact line where the process hangs (inside hid_write_timeout function for anyone wondering).
Thanks to Visual Studio Debugger, I have identified what process/program interferes with blhost in such a weird way. Not going to name it, but it is indeed (partially) security-related. It was not obvious, though! Uninstalled (though I think simply killing the related process before running blhost would be enough) and blhost FINALLY works.
This was too specific, and would hardly happen again to anyone. Otherwise - go and debug the code yourself, it is the only way.