I'm currently attempting to test the iMXRT1060-EVB with the Serial Downloader, but I'm not getting very far. I can seemingly flash the loader to the board without issue, but I can't see the loader over serial / USB connection, nor does the device appear as an MSD to load programs onto the board.
What am I doing wrong?
I've been following from the document here:
1. Place the device in serial downloader mode (SW4: Off, Off, Off, On)
2. Connect to the device over USB-HID and flash using MCU Boot Utility
2a. The file I'm using "uTaskerSerialLoader_i.MX RT 1060_USB-MSD_Kboot-HID_Kboot-UART.bin " from https://www.utasker.com/iMX/RT1060.html
3. Reset the device
4. Change out of serial download mode (SW4: Off, Off, On, Off)
5. Reset the device
I've also tried flashing the bin to the board with the DAP-Link "Drap and Drop". The flashing parts appears to work without issue (see screenshot)
Attached some screenshots.
I just loaded the version from the web site (performing a mass-erase before doing so to be absolutely sure there was nothing in Flash that could disturb) and it worked normally on my MIMXRT1060-EVK.
If I compare the read-back code with yours the data is identical but I do however see a difference:
Notice that the block size is displayed as 32.0k but yours is displayed as 64k.
Does this means that you have modified the HW to use the MX25UM51345 Hyperram instead of the IS25WP128 QSPI flash? If that is the case it is not possible to boot with that code since it doesn't contain the correct flash configuration.
Otherwise I don't see that you have done anything wrong with the loading and that reference has been used for the last 2 or 3 years without any known issues.
The only other thing I can suggest is making sure that you have nothing connected on the Arduino connectors. Sometimes a pin is defined to hold the boot loader in its reset sequence so that a debugger can be attached before it continues and in case there were such an input held low it may be running but looping waiting for the pin to go high again.
Hope you identify the issue quickly.
No, the board is straight out of the box and the Boot_Cfg Dip is set up for QSPI.
That's also the configuration I tried to define in MCU_Boot_Utility
I can write my own code and flash to the board with MCU_Boot_Utility or DAP-Link and the code works as expected.
Any ideas to how I should go forward?
That looks the same as my set up in NXP MCU Boot Utilit v3.4.0 so it looks like the same QPI flash is being used.
Did you check the Arduino pins to be sure that not are held to GND? Usually J24-10 held to GND causes the boot loader to loop until the debugger has been connected which is the only explanation that I have at the moment seeing that it looks like we have identical EVK HW and I don't have issues with that binary file.
You could post a binary from your own code that runs so i can check its Flash configuration in case there is a difference that might help explain something.
Also you could "attach" the debugger (without loading code) and pause it to see where the program counter is. If in 0x6000xxxx area it would mean the primary loader is running. If in the 0x000xxxxx range it means the serial loader is running. If in 0x020xxxx (if I remember correctly) it means the ROM loader is running. This may help to get a better idea of what is actually happening.
I have no leads attached to any headers. The soldering also looks ok.
On my board, J24 only has 8 pins, but nothing attached, seemingly no chance to ground.
I've attached my generated bin and the source files.
Unfortunately I have the MCU-Link as a debugger, which requires an adapter board to connect to the SWD-Header on the EVB. I've ordered some cables and the adapter. Currently waiting on delivery.
Cheers for the help, I appreciate it,
What I see is that you have an EVKB, which is a newer model and is not identical. The connector J24 (10-pin) is now called J17, for example.
I checked your binary and the flash configurations are almost identical, with just some slight differences like the FlexSPI bus speed.
Your binary runs on my older board.
Therefore it is still a mystery.
Attached is a more modern serial loader for the1060EVK (it only has USB-MSD and UART loading) but again operates on my board. If this one were to run it might give more clues.
The new file flashed to the board without issue and it enumerates as "Upload_Disk".
But I can't flash files to the board with USB_MSD. I tried with .bin
I followed the instructions here.
I also can't access the μTasker Serial Loader menu over UART (UART, EVB DAP-Link or MCU-Link).
I attached a video of how it looks.
Once Serial Loader is on the chip, should I see the device over Device Manager?
I have serial output on the debugger's VCOM at 115200 Baud on my board.
It is normal that the USB-MSD loader is ignoring your binary file since it needs to have credentials and optionally encrypted.
See the guides at https://www.utasker.com/iMX/developers.html which show how to use it with MCUXpressor projects (in XiP or in SRAM, with or without encryption) and the i.MX RT videos at https://www.youtube.com/watch?v=GXztWg9m6_8&list=PLWKlVb_MqDQEOCnsNOJO8gd3jDCwiyKKe
Once you add the conversion step it will then be able to operate.
I have attached a small encrypted application that will work - it enumerates as 2 x VCOMs with a CLI on one (with various menus that can be used) and the second just echos received data.
You can always see the USB interfaces in the device manager.
P.S: I still don't understand why the first serial loader binary didn't run on your board but you can build the loaders yourself and the one I posted yesterday was build quite recently so you could reproduce that anyway.
I attempted to build my own from the supplied files in GIT but there are errors during the build. I've attached an error log.
I followed the instructions here:
I did perform the update to the linker scripts.
Any idea where the issue may lay?
There is a bug in the GCC version that MCUXpresso V11.5 and V11.6 uses that causes this. It is also pointed out in the introductory email you received when you registered for the project.
I thought that maybe the case.
For information sake, the warnings in the email and on the website only mention 11.5. Therefore I first assumed it was resolved with 11.6.