Hello Hector,
Please refer below feedback from i.MXRT product team, wish it helps.
======================Feedback from RT product team=====================
It sounds like their MSD update failed, although it also sounds like it's not going back into USB MSD mode either so that may not be the case.
If they try to put the kit back into MSD mode is it capable of doing so?
If that's the case, I would ask what the flash address they are using for the binary they have created and to try creating and flashing a binary for the other bank -- if the binary they are using is for flash bank A (0x60300000), reconfigure it for bank B (0x60D00000) and vice versa. Details on doing this can be found in the Developer's Guide in section 5.3.
Unfortunately, the MSD flashing behavior can be kind of opaque in my opinion as there are two application flash banks on our chip (for redundancy purposes in case an update fails), but no way to tell which application bank we are currently running from. This is an issue because the board will only allow you to flash a binary for the application bank that is not currently being executed from, and does not make this clear when a binary fails to flash. For example, if after bootstrapping and bootloading the bootloader normally (when not jumping to MSD or OTW mode) jumps to "application flash bank A" (0x60300000), this means MSD mode would only accept a binary for "application flash bank B" (0x60D00000) so as not to erase the flash bank A which is currently set to be used when MSD is not triggered. The only indication that the board did not flash properly is that the the binary will fail to copy in a similar fashion to failing to copy a regular file in Windows.
Probably the easiest way to resolve this issue is to go reset back to the factory defaults and work from there.
As MSD cannot flash the bootloader or bootstrap, there are two options to do this:
1. Using a J-Link w/ 9-pin Cortex M Adapter
2. Using the Ivaldi automated flashing tools that come with the kit
Both of these methods will require flashing the bootloader, bootstrap, and userid_oobe applications.
Using J-Link:
I created a document a while back and have just updated it to make sure the content is relevant to the latest version of the software which may be helpful to the customer if they want to try erasing and reflashing their board if they have access to a J-Link. It's not formatted very nicely, so if that's an issue you may prefer to read through these steps and walk the customer through them instead. I can help clear up any confusion you or the customer may have.
Using Ivaldi:
This is a little bit more involved, but there are instructions in section 6 of the Developer's Guide which may be of use. I used instructions very similar to these to get up and running with those tools and have created the instructions in the DG to closely resemble the original instructions I used. This can be a good test to see if the instructions are clear to others or if they need to be reworked for clarity. These tools come included in the software package they downloaded and can be found in the "Tools" folder of the software collateral. I would recommend they use open boot programming to reset their board back to factory. The binaries they need should already be in there, so they will only need to setup their Python Environment, CA, etc. found in the instructions in the DG.
==================================End of the feedback=================================
Could you help to provide what changes you made to your project and the "MCU Settings" you are using for your binary?
Please check attached file about how to use J-Link update firmware image.
Thanks for the attention.
Best regards,
Mike
