Hi,
There is some confusion on this thread because it references both the lpcxpresso55s69 (the standard NXP EVK) and in the subject and in some other places it refers to the OKdo LPC55S69 E1 board. I'm guessing you are using the E1.
The E1 board has the LPC11u35 based debug probe, so isn't supported by LPCScrypt (which is for the LPC-Link2 type debug probe.) I dont have an E1, but what I describe below should work.
First step is to check if MCUXpresso IDE detects the debug probe when it starts a debug session. This is called "probe discovery" ... you should see a dialog appear showing the probes that the system can see, which should be an LPC11U35 probe in this case. If you see that, then the problem is probably down to the system not being able to get debug control of the target LPC55S69 device. Skip this next part in blue if probe discovery shows the LPC11U35 probe. Looking at the errors, it seems the IDE did already find a probe and you dont need to mess with the firmware, but I'm going to leave the info below for the benefit of others who read this thread
OKdo use (basically) the same firmware as NXP's LPC11u35, which we use on our LPC800 series boards. It is a basic DAP-Link implementation by Arm, with a VCOM (UART); note that it is not OpenSDA based. A few steps to try if MCUXpresso IDE doesn't see your probe:
- Open Windows Device Manager then plug in the board and see if a VCOM port appears. If it does then its likely that the firmware is up and running, so skip the next part (debug firmware update)
- Debug firmware update:
Open a file manager window. Unplug your board, then hold down the reset button on the E1 while reconnecting. This should place the LPC11U35 into firmware update mode, and your should see a drive appear with the name CRP_DISABLED appear in the file manager. Go to that drive and delete the file there, then drag and drop the firmware.bin file into the CRP_DISABLD drive to update the firmware, then power cycle. You could use the firmware we use for LPC800 boards with the same debugger - but I cannot guarantee this will work (as I cant test it): https://cache.nxp.com/downloads/en/emulators-probes/LPC11Uxx-Debug-Probe-VCOM.zip
The LPC55S69 boot ROM is intended to be secure, its possible that an application can boot and prevent debug from attaching. It can also happen if the code is in a very tight loop. The best way to recover from this is to put the part into ISP mode by holding down then ISP button while pressing and releasing the reset button. After doing that try the debug session again. If this doesn't work try holding down ISP while power cycling the board, then retry your debug session (this is because a pin level reset wont reset absolutely everything in the device - details are in the device manual). When you place the LPC55S69 in ISP mode it is sitting in a loop waiting for an in-system programming operation to start, and will respond to a debug request. You can also try using the mass erase feature in the Quickstart panel to remove any troublesome code, preferably after doing the power-cycle type ISP mode entry.
Hope that helps.