Transition from i.MXRT1020 EVK to production PCB - debugger issue (2nd post)

[davidagraham]

Good morning,

I have developed my 90% of my application code on the i.MXRT1020-EVK. My newly designed board is basically a copy paste of the eval board minus the unneeded hardware. I am using the i.MXRT1021 microcontroller with an external XIP memory through Quad SPI. I am not using external RAM on this application. The memory chip is IS25LP064A-JBLE connected the same as the Eval board.

The flash seems to be programming as I see the results by watching the console output when running the GUI Flash Tool:

(pic in word doc)

When I try to debug u sing a PEMicro Universal Multilink FX , something is going wrong. 

When I start debugging, the contents of the memory addresses do not match what should be programmed; i just see a series of mov instructions. Please see in the picture below. I put a break point in the startup code:

(pic in word doc)

I did read another person’s post with a similar problem and followed their fix, unfortunately this did not work for me. First I changed the flash driver to the generic one and modified the memory configuration.

(pic in word doc)

To reduce the clutter I have reverted to a small example code supplied with the SDK called evkmimxrt1020_igpio_led_output. With the aforementioned modifications this code runs on the eval board but not on my target.

Here are my processor settings:

(pic in word doc)

I have worked on this for a few days now to no avail. I know I must be missing a setting somewhere...

If you could point me in the correct direction please.

Thanks, Dave

[mjbcswitzerland]

Hi

I would certainly use NXP MCU Boot Utility to read back and view the memory that has been programmed.
Use it to then erase the memory and read it back as blank, and finally use it to program a reference binary file - read it back and verify that all operations are good.

In my experience the debugger views can't always be trusted when looking at QSPI flash memory.

If there are problems this way check carefully all your boot straps to ensure that the i.MX RT loader is correctly configuring the FlexSPI interface for you and your QSPI device: Make sure that it is not trying to use a different boot device.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or product development requirements

[davidagraham]

Mark, thank you for getting back to me so quickly

This was a road I did not want to travel just yet : )

• I do have a USB interface on my project so I will try this method first. Untested hardware – fingers crossed.
• I rearranged my bootmode inputs to 01 (was 10)
• Plugged in my USB and turned on the power. USB driver installed and my device enumerated as “SE Blank RT Family” USB Input Device 1fc9 0130 (Hardware seems OK!)
• I then ran NXP MCU Boot Utility v2.3.1 as you suggested.
• I leave everything default and press “Connect to ROM”
• I do see some commands run in the cmd shell
• I then get a “cannot find USB-HID device( vid=0x15A2, pid=0x0073) …” I assume the flashloader was installed and is looking for a new connection.
• I disconnect the USB and connect it again
• I get the “installing device driver software” window … USB COMPOSITE DEVICE
• Windows installer is looking to install a "Composite Device" ... I let it try for a while and then I get "Device Driver software was not successfully installed"
• When looking at the device manager see a USB Input Device 15A2 0073
• When looking at the device manager under Device Status I see “This device cannot start (Code 10) (it is a Windows 7 machine)
• Is there a USB driver for the flashloader that I could “update driver” with?
• Is there a different approach I should take?

Again, any guidance on this is appreciated.

[mjbcswitzerland]

David

I have only used this with Win 10 and, since it is quite a new program, I doubt that anyone has thought of Win 7 compatibility.

It should also work on a UART too (although I have only ever used it on the USB).

Regards

Mark

[davidagraham]

Hi Mark,

I moved to a Win 10 machine to try the MCU Boot Utility on my hardware with no success. I then moved back to my WIN 7 machine and moved back to the evaluation board. The Boot Utility works and I was able to erase, read and write the flash in the EVAL board. The difference in the boards is that I have isolation, a ADUM41060 chip, on my USB due to it being an industrial product. I pulled the isolation and wired the USB lines direct. Success! I suspect the ROM USB connection is a Full Speed connection and the Flash loader is a High Speed connection. My hardware does not support a High Speed connection. I will work through this later; maybe I will try the UART or dig into the flash loader a bit further.

OK, back to my emulation problem. After programming my hardware with the Boot Utility I rearranged my bootmode inputs to 10 and I was able to run the code without the debugger attached. With the debugger I was able “see” and debug the evkmimxrt1020_iled_blinky code by setting the GUI Flash Tool to Verify Only. At this point I feel that my flash, JTAG, ans USB are wired correctly.

I changed the code a bit, complied, and I was able to program and debug using the Universal FX. Now I am quite confused …

I now take another prototype board (I have 5) and set it up with bootmode inputs to 10. Just as before (what started this conversation) this new board will not program or debug with the Universal FX.

I will rework this second board’s USB see if programming with the Boot Utility somehow allows the Universal FX to work. In either case I will let you know.

[davidagraham]

Hi Mark,   

Just a quick update, I took the time to wire into the LPUART1 that I had exposed. I got the Boot Utility to run using a connection to the LPUART; I will probably use this for production programming.     

I found if I take a new PCB I cannot get the debugger to program or run (bootmode 10)

If I take the same PCB and program it with “any code” using the Boot Utility (bootmode 01) I can then run and debug any project using the debugger (bootmode 10)

I guess I am up and running enough to continue with my application. If you can think of any reason that in bootmode 10 the Pemicro FX would not program a new chip let me know …