LPCScrypt v2.1.1 Broken? Have to revert to 2.1.0

variable_andrew · ‎09-17-2020

I got 3 brand new LPC-Link2 probes to use to debug our RT1052 board.

I'm debugging with MCUXpresso 11.1.1 via OSX 10.15.6.

I programmed all 3 LPC-Link2 probes with LPC432x_CMSIS_DAP_V5_361 from lpcscrypt_2.1.1_15 - and none of them can consistently debug. Almost always they'd somehow cause a fault/kill the RT1052 chip.

While they can't debug w/ this firmware, I am able to consistently program flash from the MCUXpresso Flash Tool....

If I program the LPC-Link2 probes with LPC432x_CMSIS_DAP_V5_224.bin.hdr from lpcscrypt_2.1.0_842, then they all work fine for debugging, flash tool, etc.

Why is the lpcscrypt 2.1.1 failing for mcuxpresso in my setup when 2.1.0 works?

Will this be fixed, or do I need to keep track of archived lpcscrypt tools in order to use the probe HW?

mvaranda · ‎09-22-2020

Andrew, I am a bit out of context here but I noticed you had similar CSI problem of not starting DMA when everything looks good when using csi 2.0.0 (or fixed 2.1.1 driver). How did you solve your problem? Thanks in advace.

kerryzhou · ‎09-22-2020

Hi mvaranda

If you have any question, you also can create your own post, then we will help you in your question post.

Best Regards,

Kerry

variable_andrew · ‎09-22-2020

Hi @mvaranda ,

If you're referring to the post here: https://community.nxp.com/t5/i-MX-RT/RT1052-CSI-stuck-waiting-for-GetFullBuffer/m-p/1156953#M10206 , then I've responded in line.

Basically I believe there's a bug in the newer CSI drivers. Had to revert to the old ones used by the AN SW.

mvaranda · ‎09-22-2020

Thanks a lot Andrew.

kerryzhou · ‎09-21-2020

Hi variable_andrew,

I test the CMSIS DAP again, and it works, mainly refer to this post:

https://community.nxp.com/t5/MCUXpresso-IDE/Problem-debugging-on-iMX-RT1052-using-LPC-Link2/m-p/8208...

This is my test result with LPC-LINK2 CMSIS-DAP V5.361

Please try it again.

RT1052-EVK:

J29,J32,J33,disconnect

J1 connect 3-4, USB connect to j9

LPC-LINK2, JP1 connect, JP2 connect

Please try it again, any improvement or not?

Wish it helps you!
If you still have questions about it, please kindly let me know!
Best Regards,
Kerry
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-----------------------------------------------------------------------------

variable_andrew · ‎09-21-2020

thanks for the double-check @kerryzhou , i will test this this week

kerryzhou · ‎09-21-2020

Hi variable_andrew,

You are welcome!

After you test it, any updated information, just kindly let me know.

Best Regards,

Kerry

kerryzhou · ‎09-18-2020

Hi variable_andrew，

Just the newest CMSIS DAP firmware have issues, right?

Do you try the JLINK firmware in the LPC-LINK2, whether that works or not?

About the newest CMSIS DAP firmware version issues, I will test it on my side next week.

BTW, you mentioned: Almost always they'd somehow cause a fault/kill the RT1052 chip.

What's the detail situation? Do you mean the RT1052 is broken, and even can't used forever? Do you use the JLINK to contact with the killed RT1052, whether the ARM core can be found or not?

Best Regards,

Kerry

variable_andrew · ‎09-26-2020

Hi @kerryzhou ,

I've tried the JLink firmware as you 1st suggested and this seems even more stable than the the older CMSIS-DAP firmware that I had previously been using so I'll be sticking with this.

The previous CMSIS_DAP FW would lose connection to the RT1052 as soon as the device goes into low power mode on our board, but the JLink FW seems to be stable regardless of low power mode.

Thanks!

kerryzhou · ‎09-26-2020

HI variable_andrew,

Thanks for your feedback.

And that's good to hear the JLINK firmware make you works on your side.

About the low power mode, some low power mode will disable the SWD interface, so if you test the low power mode, I suggest your download the code to the chip flash, and test it directly instead of debug mode.

Wish it helps you!

Best Regards,

Kerry

variable_andrew · ‎09-19-2020

Hi @kerryzhou

Right, just the version mentioned in the original post.

I haven't tried the JLINK firmware. Would you say this might be more reliable than CMSIS for debugging / is there much difference?

Regarding the details of the fault/kill problem:

What I meant was the RT1052 chip would halt/perhaps hit an exception or somehow become unresponsive and would require me to reset power to the chip in order for it to boot back up (to the code that was already in FLASH).

So it appeared the chip was reset, but then halted execution instead of resetting and jumping to the internal boot code. (If the debugger failed to attach, I would expect the chip to not be affected, or to perhaps reset and start back up as normal, but not reset and then stop executing.)

kerryzhou · ‎09-20-2020

Hi variable_andrew,

I highly suggest you try the JLINK on your side.

You can use the JLINK firmware which still can use the LPCscrypt to download the code:

https://www.nxp.com/design/microcontrollers-developer-resources/lpc-microcontroller-utilities/lpcscr...

To make sure you are using the latest jlink firmware, you also need to refer to this item in the segger website:

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/lpc-link-2/

I have tested the LPC-LINK2 JLINK firmware with the MCUXPresso IDE, it works OK.

This is the JLINK command connection, it can find the ARM core

This is the JLINK MCUXPresso project debug result, it can debug the code:

So, please try the JLINK.

About the newest LPCscrypt about the CMSIS DAP, I also didn't make it works, I will check with internal side.

Any updated information, will let you know.

Best RRegards,

Kerry

variable_andrew · ‎09-27-2020

Hi @kerryzhou ,

I was able to debug with J-Link.... (when code was already FLASHed to my board), but when i need to flash new code or just try to erase the flash / do anything with the FLASH, the j-link version of FW failed to work. (it kept saying chip was already running).

Just switching to a cmsis-dap probe enabled me to program flash.

So in the end, I can't use the latest lpcscrypt_2.1.1_15/scripts with JLINK to debug so long as I need to change code in FLASH.

So I went and tried your suggestion of the CMSIS-DAP lpcscrypt_2.1.1_15, but with J1 and J2 connected, and this couldn't connect our board.

In the LPC-Link2 schematics it says if J2 is connected, then the LPC-LINK2 will provide power to the debug port - isn't this dangerous if both LPC-LINK2 and the RT1052 are providing power?

I tried lpcscrypt_2.1.0_842 JLink - but apparently this version doesn't support CORTEX M7.

I ended up going back to lpcscrypt_2.1.0_842/scripts CMSIS-DAP and am able to debug with these, tho as noted, unfortunately they aren't very stable in the low power modes that the JLINK version was able to debug

kerryzhou · ‎10-09-2020

Hi variable_andrew,

Jlink need to use the newest firmware:

https://www.segger.com/downloads/jlink/Firmware_JLink_LPC-Link2

More details checking:

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/lpc-link-2/

n order to get started with LPC-Link 2 just a few steps are necessary:

Download LPCScrypt here.
To make sure that LPCscrypt uses the latest LPC-Link2 firmware, please replace the J-Link firmware images located in:
- LPCScrypt_InstallDir\probe_firmware\LPCXpressoV2\ and
- LPCScrypt_InstallDir\probe_firmware\LPCLink2\

by these:
- Firmware_LPC-Link2

(Files may need to be renamed after download, to match the ones in LPCScrypt)

Set the eval board into DFU boot mode. How is explained in the respective board manual.
Connect LPC-Link 2 to the PC.
Execute %LPCScrypt_InstallDir%\scripts\program_JLINK.cmd
Follow the instructions given by the script.
Power-cycle LPC-Link 2. It will now enumerate as a J-Link.

Do you already update the newest JLINK firmware to your lpcscrypt:LPCScrypt_InstallDir\probe_firmware\LPCLink2\ ?

Best Regards,

Kerry

variable_andrew · ‎10-09-2020

Hi @kerryzhou ,

Yes - I'm running with LPC Scrypt 2.1.1.-15, and this has the latest script (dated 2019 4/4)

Downloaded again from the web and tested again.

variable_andrew · ‎10-08-2020

@kerryzhou

Just pinging you again on the above -

Also - the suggestion for the latest LPC-Link2 FW seems to be a little dangerous for custom boards where you can't cut the vref line on the board, right?

Driving JTAG VREF from the LPC Link2 board and driving it from the the RT1052... should cause hardware issues i'd assume.

Unrelated, but at this point - I'm unable to debug across multiple LPC-Link2 boards.

I keep getting "0 available SWD Devices detected" when i try to debug.
Or:

02: Failed on connect
02: Failed on connect
Invalid ID for processor.
Probe(0): Connected&Reset. Was: NotConnected. DpID: 0BD11477. CpuID: 0000000E. Info: <None>
Debugging context: TestProject-SDK270 LinkServer Debug

But I'm able too run the flash programmer just fine........

We have purchased a number of LPC-Link2 probes for this project....... none of them seem to be working at this point....

kerryzhou · ‎10-09-2020

Hi variable_andrew,

You need to connect the VDD to the SWD JTAG_VREF pin, this is important.

It used to detect the VTref =3.3V or not, do you have this item, after it has the 3.3v, then it will do the SWD checking.

Please check it at first.

Best Regards,

Kerry

variable_andrew · ‎10-09-2020

I have been switching back n forth between JLINK and CMSIS-DAP.

Here is the output from jlink:

Why would it keep getting CPU halted?

kerryzhou · ‎10-09-2020

Hi variable_andrew

Thanks a lot of for your effort.

Your log should from the MCUXPresso IDE right?

Do you use the JLINK Commander directly or not? Can you find the ARM core or not like the picture which I have shared with you in the previous time?

BTW, which JLINK driver version you are using? You can use the newest JLINK driver. Seems your JLINK driver version is old, please download it from this link:

https://www.segger.com/downloads/jlink/JLink_Windows.exe

Your own board RT105X is using the external hyper flash or the QSPI flash? As I know, the JLINK RT105X is using hyper flash in default, just for the MIMXRT1050-EVKB board.

Wish it helps you!

If you still have questions about it, please kindly let me know!

Best Regards,

Kerry

-------------------------------------------------------------------------------

Note:

- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored

Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

-----------------------------------------------------------------------------

variable_andrew · ‎10-10-2020

Hi @kerryzhou ,

Correct, that was from MCUXpresso IDE. I am on MacOS and couldn't find JLINK commander, but I see SEGGER updated their software package last night.

I downloaded these tools andI don't see JLINK commander, but I do see the SEGGER J-Link GDB Server v6.86d:

I was able to connect to a Seeed Arch board last night - just not this board, so it would seem that after lpc-link2 started having issues, it some how brought down this RT1052's JTAG/SWD port.

The odd thing is - everything else still functions (spi, qspi flash, internal ram, sdram, usb, csi, i2c, uart, etc etc etc etc).....

I have never had a board/chip just have SWD/JTAG debug die on it... any ideas what else it might be? Our boot_mode == 01 (inteernal) same as always.

Our device is QSPI FLASH (64MB) and appears to be working fine... we're using the same project we've been using over the past 6 months.

Currently in MCUXPresso 11.2 + the above JLINK, if i try to debug, it appears to downloads code, resets the part, but doesn't break at main - starts running, & prints the expected (to the console):

"USB device CDC virtual com demo" in the console.

If i try to pause the debugger - it fails to set breakpoint and disconnects.