Fail Debug/Program with MCUxpresso and EVK-MIMXRT1020 or MIMXRT1050-EVK

[luiHS]

 
Hello.

I am starting to work with the EVK-MIMXRT1020 evaluation board, based on the NXP i.MX RT1020 microcontroller . I follow all the instructions on the i.MX NXP website, I install MCUXpresso, download and install SDK, install USB driver, open the "Hello_World" source code example, press Build to compile and Debug to program and run, but it fails last step to Debug/Run (I only want run at this moment). Attached screenshot of MCUXpresso.

I have also reinstalled Java, but it always fails. I also have an MIMXRT1050-EVK evaluation board for the RT1050, and the problem is the same, none can Program and Run, following the instructions on the NXP website.

https://www.nxp.com/products/processors-and-microcontrollers/applications-processors/i.mx-applications-processors/i.mx-rt-series/i.mx-rt1020-evaluation-kit:MIMXRT1020-EVK?tab=In-Depth_Tab

Any suggestions, or someone with the same problem solved ?.
It looks like a driver problem, but I downloaded and installed it, according to the NXP installation instructions.

Best Regards

[luiHS]

 

I have install now MCUxpresso 10.1.0, and this recognize the DAP Link CMSIS DAP driver, program, run and debug.
But fail with MCUxpresso 10.2.0. What happen, what is the problem with MCUxpresso 10.2.0 and mbed drivers ??

[ehughes]

I use the j-link firmware with 10.2 with no issues on the EVKs.    The CMSIS DAP firmware that comes as a default was slow and buggy.

I eventually migrated to using the large 20 pin header for debug via swd with an external jlink.    It is much faster with a much better debug experience.   

[luiHS]

I use the j-link firmware with 10.2 with no issues on the EVKs.    The CMSIS DAP firmware that comes as a default was slow and buggy.

I eventually migrated to using the large 20 pin header for debug via swd with an external jlink.    It is much faster with a much better debug experience.

I have a Jlink Segger V9 and P&E propgrammers, but I do not know if it will be compatible with RT1020 / RT1050, and if I can program these microcontrollers without internal flash memory. This is the first time I work with a microcontroller that requires external flash to boot.

I also want to develop, as soon as possible, my own board, without an intermediary OpenSda microcontroller, dumping the program directly to an external SQPI or an SD card. Maybe I can use Debug (for SWD?), but I still do not know how to upload the program to the QSPI. To create the program to boot from SD card, it seems that there is PC software to create an encrypted firmware image.

Right now what interests me, above all, is to start testing these two evaluation boards, to migrate as soon as possible all my developments from Kinetis MK66 to RT1020. Being able to do Debug more or less quickly does not bother me.

Do you mean that if I connect my Seglink Jlink V9, with a 2x10 flat cable, directly to the JTAG connector on the RT1020 / RT1050 evaluation board, I will be able to program and debug with MCUxpresso 10.2.0?

[luiHS]

 
I have connected my Segger Jlink V9 and PE Micro Multilink programmers, and both work well with MCUxpresso 10.1 and 10.2, with the two boards. Then, I will work with these programmers instead of CMSIS DAP via USB.

Unfortunately, I connected the flat cable in an incorrect position between the RT1020 board and the Mutilink programmer, and damaged irreversibly the RT1020 board (I suspect the microcontroller damaged, its a LQFP 144 pin, no yet available to order, so I can not replace), but my RT1050 board is still working fine.

[mac.6]

Reversal of 19pin arm-jtags means V+ from jtag is shorted to ground (yeah bummer pin assignment), so you mostly fry corresponding regulator.

[ehughes]

I also want to develop, as soon as possible, my own board, without an intermediary OpenSda microcontroller, dumping the program directly to an external SQPI or an SD card. Maybe I can use Debug (for SWD?),

That is what you want to do.  SWD is the debugging option enabled by default in the RT.

Flash programming works for QSPI or HyperFlash by using small program that is loaded into internal RAM that accepts flash commands via SWD.     

MCUXpresso has the algorithms already built in for CMSIS DAP.     The MCU Settings dialog in the project properties show the memory map and which flash programming algorithms are used for different regions.       

Segger also has flash programming algorithms for QSPI and HyperFlash built into the latest j-link drivers.   I believe there was some configuration if you have QSPI (there were some posts on the Segger Forum about) instead of Hyper Flash but it is pretty easy to do.

I am not sure if the multilink driver has flash programming routines for the RT family yet.

If you are using the latest SDK,  the hello world code already is targeting Hyper flash.  If you managed to get a debug session working, you have already programmed the flash.

[luiHS]

I also want to develop, as soon as possible, my own board, without an intermediary OpenSda microcontroller, dumping the program directly to an external SQPI or an SD card. Maybe I can use Debug (for SWD?),

That is what you want to do.  SWD is the debugging option enabled by default in the RT.

In the scheme of the RT1020 evaluation board, I see some SWD and JTAG pins. So, can I add to my own board a connector with GND, SWD_CLK and SWD_DIO to debug with Jlink or Multilink, from MCUXpresso?

Flash programming works for QSPI or HyperFlash by using small program that is loaded into internal RAM that accepts flash commands via SWD.     

MCUXpresso has the algorithms already built in for CMSIS DAP.     The MCU Settings dialog in the project properties show the memory map and which flash programming algorithms are used for different regions.       

Segger also has flash programming algorithms for QSPI and HyperFlash built into the latest j-link drivers.   I believe there was some configuration if you have QSPI (there were some posts on the Segger Forum about) instead of Hyper Flash but it is pretty easy to do.

I am not sure if the multilink driver has flash programming routines for the RT family yet.

I do not know if this is exactly the same as I read in the application notes AN12108 and AN12107, on "How to enable booting from QSPI Flash" and "How to enable booting from the Octal SPI Flashand SD card".

In these documents, they work with the MFG tool to load the new user firmware to the QSPI or SD card, through USB or Serial port. This is a solution to load the firmware into a new custom board, but I will also need a system to provide updates to the end user (customer) of the product. Now for example in my boards based on Kinetis MK66 microcontrollers, these install an encrypted bootloader in the flash of the microcontroller, which can update the firmware with a new firmware file (encrypted) from the SD card.

For the RT1020 custom boards, I understand that I can provide a file to copy directly to the SD card, if the product will boot and run the program from the SD card, but I still do not know how to provide updates for the custom boards that boot from QSPI. I need some system to update the QSPI from the SD card, not by USB or Serial connected to a PC computer. Also, I need to control which firmware can be loaded.

[luiHS]

Reversal of 19pin arm-jtags means V+ from jtag is shorted to ground (yeah bummer pin assignment), so you mostly fry corresponding regulator.

What has been damaged is the board, and in particular it seems that the RT1020 microcontroller has been burned. The Multilink programmer is still working, but the RT1020 board can no longer be programmed, read, or run the last program it had loaded that caused a led to flash.

Fortunately it's a cheap board, I've already ordered another one from Mouser.

Or do you mean, what has been damaged is a voltage regulator on the board of the RT1020, which feeds this microcontroller ?. I'll look at the schemes, see if that's it, and it's easy to solve. The MK20 with OpenSDA, is working on the RT1020 board.

[ehughes]

I do not know if this is exactly the same as I read in the application notes AN12108 and AN12107, on "How to enable booting from QSPI Flash" and "How to enable booting from the Octal SPI Flashand SD card".

In these documents, they work with the MFG tool to load the new user firmware to the QSPI or SD card, through USB or Serial port. This is a solution to load the firmware into a new custom board, but I will also need a system to provide updates to the end user (customer) of the product. Now for example in my boards based on Kinetis MK66 microcontrollers, these install an encrypted bootloader in the flash of the microcontroller, which can update the firmware with a new firmware file (encrypted) from the SD card.

During development you can you *everything* through SWD  (it will get you up an running much quicker).   This includes programming external flash.

The Manufacturing Tool (and the flash loader tool) are more for factory programming once you are in production.   

For the RT1020 custom boards, I understand that I can provide a file to copy directly to the SD card, if the product will boot and run the program from the SD card, but I still do not know how to provide updates for the custom boards that boot from QSPI. I need some system to update the QSPI from the SD card, not by USB or Serial connected to a PC computer. Also, I need to control which firmware can be loaded.

I have not used a configuration where you boot from SD and then program the QSPI.       You may need to write your own 2nd stage bootloader if you want to be able to select which images you want programmed.   I.E.     Boot via SD (load program into internal RAM) and then that program looks for files on the SD card to program the QSPI.      You would also probably need some configurable pin strapping to boot from SD when there is a card present vs boot from QSPI when running application software.

I generally always write my own  2nd stage bootloader to have some additional flexibility/control of the process.

You use case probably is supported, I just have never done it. 

[luiHS]

During development you can you *everything* through SWD  (it will get you up an running much quicker).   This includes programming external flash.

The Manufacturing Tool (and the flash loader tool) are more for factory programming once you are in production.   

Do you mean that I can program the QSPI directly by SWD without using OpenSDA? I have read that to program QSPI or SD card, directly, without using OpenSDA, I must connect via USB or UART to a PC and use the MFG software.

SWD I understood, that it will only work for Debug, not to directly program the QSPI or the SD card.

I have not used a configuration where you boot from SD and then program the QSPI.       You may need to write your own 2nd stage bootloader if you want to be able to select which images you want programmed.   I.E.     Boot via SD (load program into internal RAM) and then that program looks for files on the SD card to program the QSPI.      You would also probably need some configurable pin strapping to boot from SD when there is a card present vs boot from QSPI when running application software.

I generally always write my own  2nd stage bootloader to have some additional flexibility/control of the process.

You use case probably is supported, I just have never done it.

The question is how to provide firmware updates to the end user, so that they can be uploaded from the SD card to the QSPI. All my boards with Kinetis MK66 install a micro SD card to update the firmware, and I want to do the same with the RT1020 board.

All the examples in Application Notes for loading firmware in RT1020 and RT1050, without using OpenSDA, are made by connecting the board, by USB or UART, to a PC computer, there are no examples to update the firmware of QSPI with SD card.

To provide firmware updates, if the board boots from the SD card, I understand that I simply need to provide a copy of the SD card programmed for the first time with the MFG tool, although there is also no information in the Application Notes about it, I'll check it for myself.

[luiHS]

 
Today I received a new RT1020 board and I have test RT1020 and RT1050 boards with MCUXpresso 10.1.0 and 10.2.0, Multilink PE and Jlink programmers (after cut the wires 1 and 2 of JTAG to avoid damage again the board), and also tested with DAP Link CMSIS-DAP driver by USB.

This is a headache, Jlink is the only one that works with RT1020 and RT1050, but only with 10.1.0 MCUXpresso. Multilink also works with RT1050 but only with version 10.1.0 MCUXpresso. MCUXpresso 10.2.0 fails with all the programmers, USB driver and both boards.

These are my tests:

RT1050 + MCUxpresso 10.1.0  + DAP LINK CMSISI-DAP Driver --> FAIL
RT1050 + MCUxpresso 10.2.0 + DAP LINK CMSISI-DAP Driver  --> FAIL
RT1020 + MCUxpresso 10.1.0 + DAP LINK CMSISI-DAP Driver --> FAIL
RT1020 + MCUxpresso 10.2.0 + DAP LINK CMSISI-DAP Driver --> FAIL

RT1050 + MCUxpresso 10.1.0  + Multilink PE programmer  --> OK
RT1050 + MCUxpresso 10.2.0 + Multilink PE programmer  --> FAIL
RT1020 + MCUxpresso 10.1.0 + Multilink PE programmer  --> FAIL
RT1020 + MCUxpresso 10.2.0 + Multilink PE programmer  --> FAIL

RT1050 + MCUxpresso 10.1.0  + Jlink programmer  --> OK
RT1050 + MCUxpresso 10.2.0 + Jlink programmer  --> FAIL
RT1020 + MCUxpresso 10.1.0 + Jlink programmer  --> OK
RT1020 + MCUxpresso 10.2.0 + Jlink programmer  --> FAIL

Therefore, currently, only Jlink works with RT1020 and RT1050 with MCUXpresso 10.1.0, and RT1050 with Multilink and MCUxpresso 10.1.0. I have deleted and reinstalled MCUXpresso and drivers several times, I work with Windows 7 64 bits.

I sent this problem to NXP, I hope they help me solve the problem or some new release of MCUXpresso.

[ehughes]

Curious.  I cant say what is wrong with the 10.2 installation.       I have a 10.2 installation and everything seems fine.    Maybe try an external debugger (like Segger Ozone) to see if it is a driver issue or if something is just messed up with the IDE.

[luiHS]

Curious.  I cant say what is wrong with the 10.2 installation.       I have a 10.2 installation and everything seems fine.    Maybe try an external debugger (like Segger Ozone) to see if it is a driver issue or if something is just messed up with the IDE.

I already know what the problem is, the FIREWALL.
You can check all my progress on this problem in the NXP forum, at this link, https://community.nxp.com/message/1034553

[luiHS]

 
Problem totally solved, and now everything works perfectly. The solution was to simply remove the installation and the directory, and install again but in a NEW directory (in my before tests I always reinstalled in same directory name by default). Therefore, when it is executed from a new directory, the firewall warns about each new process and requests whether to accept the process to grant or not permissions.

Then, after running from a new directory and accepting all the warnings from the firewall, everything works perfectly, Jlink, Multilink and DAP-CMSIS via USB in both versions of MCUXpresso 10.1 and 10.2.

The only thing I did not like, is that NXP at no time they offered help on this problem, not a single suggestion about the problem of a FIREWALL server, and when I knew that the problem came from the firewall they did not give me a solution either to definitely solve the problem.

Thanks to Erich from "MCU on Eclipse" blog, without his suggestion about the firewall, I would not have been able to solve this problem.


These are all messages from the firewall when MCUXpresso is running from a new installation and a new directory, for first time. I accept all the warnings, and in this way, the firewall grants permissions to all the MCUXpresso processes, and everything finally works fine.

[krho]

You have overzealous firewall. The firewall should mind it's own businesses as long as the application listen only on any of the localhost addresses.

[luiHS]

 
Well, I do not know, after trying some firewalls, PC Tools Firewall seemed the best. I think it perfectly fulfills its purpose, warns me when a new process tries to access the network, to grant or deny permissions.

My mistake, when running for the first time MCUXpresso 10.2, is that I denied permanently  permission to all processes that were executed, then nothing could work. I have the habit of denying permissions in the firewall to any process that I do not know, to avoid malicious software.

In this case, given that I did not know that MCUXpresso run processes that make use of the network, I denied all the permissions, since the firewall was giving me notices requesting access permissions.