Communciating with RT1064 Flashloader (from MCUXpresso)

[CK3]

Hi,

I want to establish communication with the RT1064 MCU Bootloader. Now, I know the MCU Bootloader is implemented in 3 ways: ROM-based, flashloader, flash-resident bootloader. I want to communicate with the flashloader.

For Communication, I use the MCU Flashloader command API (as documented in the MCU Flashloader Reference Manual). Meaning I wrote several of those commands in source code and execute this.

What am I currently able to do:

Using Ubuntu 18.04, I connect via USB-HID on the USB-OTG socket and send the getProperty command to the flashloader. This happens in Internal Boot Mode. I am able to send the message but I do not get any response. Also the PID of the RT 1064 is 309 and it is named "SE Blank RT Family".

Interestingly, when I additionally connect a Windows PC via the Debug Socket and execute MCUXpresso RT1064 Flashloader example from the SDK in Debug mode, I am able to communicate with the Flashloader from Ubuntu. By this I mean, I get a response to my getProtery command. In this scenario the PID is 115 and the name "USB COMPOSITE DEVICE".

What I tried so far:

I tried the MCUXpresso and the NXP-MCUBootUtility to upload applications to the RT1064. Right now I have 2 projects: LED Blinky and the 1064_Flashloader from the SDK.
The LED Blinky is always flashed, the flashloader is only uploaded successfully with the NXP-MCUBootUtility and not with the MCUXPresso (Why is that?). Communication never works in either way.

Reading into the AN12238 as well as the blhost and sdphost user Guide, I found out about the bootable image that are necessary for the BootROM in order to start a flashloader. However, the NXP-MCUBootUtility is already doing this from what I see on the log file and the commandline.

What I would like to know:

1. Why can I establish communication with the flashloader, when it is running in Debug mode on the MCUXpresso but not in any other case?
2. Why is MCUXpresso not flashing the flashloader from the SDK? (This was comfirmed by checking the memory addresses where the flashloader is supposed to be, which were empty)

Thanks in advance!

[victorjimenez]

Hello, 

The flashloader examples that we provide within the SDK cannot be loaded to the board directly from MCUXpresso IDE. First, you need to use the elftosb tool to generate the bootable image. Once you do this you need to use the sdphost tool to flash the image. Once you do this you'll be able to communicate with the flashloader. I just made the test on my end with the RT1064-EVK and I didn't face any problems. 

I compiled the flashloader project in MCUXpresso. After, I used the binary utilities inside the IDE to generate an s19 file with the axf. 

From there, I took the s19 file and executed the corresponding commands. Everything went fine, here are the commands that I used: 

Regards,
Victor 

[CK3]

Hello,

thanks four your advice. However, if I understand this correctly, then all this steps should already been done by the MCUBootUtility https://github.com/JayHeng/NXP-MCUBootUtility, meaning I should be able to communicate with the Flashloader on Ubuntu. Right now, I cannot do this.

Any idea what could cause this?

Thanks again!

[victorjimenez]

Hello, 

Yes, MCUBootUtility does this for you. I just made a couple of tests on my end, and I didn't face any problems. The tool recognizes the board without problems. I just put the EVK into serial downloader mode and everything went fine. 

Are you able to see if the tool recognizes your RT like shown below? Are you using a custom board or our EVK? 

Regards,
Victor 

[CK3 · Accepted solution]

Hi,

thanks a lot for the help. I am using the EVK. I can create and upload the flashloader via the command-line tools (elftosb, sdphost and blhost) and I am able to communicate via the blhost tool. Still, if I reset afterwards and then try to communicate via the blhost (or on Ubuntu via my code) it is not working anymore.

However, I think I understand now why this is: What the command-line tools (and MCUBootUtility) are uploading is a flashloader = a "one-time-bootloader" that resides in FLASH. Since the bootloader area will be overwritten by the application, i cannot communicate with it afterwards. Is this correct? I found that explanation here: https://mcuoneclipse.com/2017/07/12/getting-started-rom-bootloader-on-the-nxp-frdm-kl03z-board/ 

So if I want to change update for example a 1Hz blinking LED application to 5Hz I need to use the sdphost tool to upload the flashloader again and then use the blhost tool to flash the LED application. I am doing this right now and it works that way.

Now my question is, what is best-practice for a Serial Product upadting mechanism? Using:

• -a one-time-bootloader that has to be uploaded everytime before the application is updated via sdphost and blhost
• -a flash-resident bootloader? if so, is there an available flash-resident bootloader for the RT1064, or do I have to port it from another board? For example the rt1062 like here: https://community.nxp.com/t5/MCU-Bootloader/Flash-resident-bootloader-for-i-MX-RT1064/m-p/1053581 

(On a side-node, I always need to execute the "fill-memory" and "configure-memory" commands before I can use "flash-erase-region" and "write-memory" without errors. Why is that?)

[victorjimenez]

Hello, 

Thanks for your reply. I'm glad to hear that you can create and upload the flashloader via the command-line tools. Keep in mind that the flashloader resides in RAM, this is why when you reset the board, the flashloader goes away. 

Both options that you suggested for updating the firmware are good, which one to use will depend on your needs. 

Regarding the flash resident bootloader, we have an application note that goes through this. You can check it at the following link. Additionally to this, we provide the software of this app note. 

Implement second bootloader on i.MXRT10xx series (nxp.com)

https://www.nxp.com/docs/en/application-note-software/AN12604SW.zip

I always need to execute the "fill-memory" and "configure-memory" commands before I can use "flash-erase-region" and "write-memory" without errors. Why is that?

These commands are needed to write the flashloader into the internal RAM of the RT. 

Regards,
Victor