Hi everyone,
I am doing a project in my company with MIMXRT1024, and I am facing problems with getting the module to enter serial download mode.
I needed to make some changes in the code to solve some I/O problems with the following lines:
After that, my module never entered serial download mode. This is correct, but I needed to revert this condition, and I couldn´t.
The way that I tried to revert this condition was to clear the flags that I had set before, but the result is the same: the module doesn´t enter serial download mode anymore. The lines below are the lines that I changed in my code:
Hi @alvarolopes
Thank you for reaching out!
I have some questions for you to understand better your scenario. Please help me with them.
When you say I/O issues, what do you mean? Are you not able to set the status of the boot_mode and boot_config pins externally?
Are you dealing with this problem during development or production stage?
Which functionalities/features of the serial downloader you need? For example you need to only program fuses, write flashloader and then write custom application?
As a quick suggestion...
I would recommend calling the runbootloader function as a workarround, but RT102xs do not support it . However you could implement a secondary bootloader. See this thread Jump to ROM bootloader from application in i.MX RT1024
All the best,
Diego
Hi Diego,
For some reason, the default state of a specific I/O pin was causing the non-initialization of my software. For this reason, I made this change that I found in:
https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/How-to-burn-BT-FUSE-SEL-on-RT1050/td-p/809577
I believed that all my problems were solved with this solution. Now, I have entered another step of the project, where I need to be able to execute the update of the software in Serial Download mode. It was the reason that I posted my problem.
Regards!
Hi @alvarolopes
I am sorry for the delay! Thank you for the additional context.
Would you be able to read the following two registers over SWD after a failed serial downloader boot attempt and share a picture?
Best regards,
Diego
Hi Diego,
Follow my registers state using Debug Probe running in Debug mode, not Flash by GUI Tool.
Brest regards,
Alvaro
Hi @alvarolopes
I am sorry for my delayed response.
I corroborated with your snapshot from SRC_SBMR2 that your code is able to burn registers, as the BT_FUSE_SEL is burned . So if you burned as well the FORCE_INTERNAL_BOOT fuse, the boot to serial downloader mode will not longer work, eventought your boot mode pins are set to 0x01 to boot in this mode.
I noticed that the post is quite old, as it discuss about MFG tool and manually programming fuses from the application, during that time there was nothing else, but today is outdated. In case you have not use it already, we recommend you to use the MCUXpresso Secure Provisioning Tool (SEC tool or SPT for short), it is a easy to use. The SEC tool uses our Secure Provisioning SDK (SPSDK) by running scripts.
Good news here are that you could still do your update on that board! Yet, I have not test it, but in theory I think it will work to at least help you to continue with your development. Let me explain below.
When you boot in serial downloader mode, the bootROM will execute and wait for host commands. However the bootROM can NOT do update process by itself, it needs another program, to be loaded and then executed, that could do RW operations on the flash, or burn fuses. This is the flashloader. The SEC tool, allows you to do SW updates once you are able to build an application (it provides sample images). To do the SW updates the SEC tool creates a bootable version of the flashloader, and loads it to internal RAM, by communicating with the bootROM in serial downlaoder mode, this is the main point of serial downlader boot mode. To salvage your board you could manually program the flashloader into RAM using SWD/JTAG and then do the rest of the operations to update your image. Below overal idea describing this.
Also, the SEC tool allows you to manually burn fuses, see below snapshot.
I wonder, if you burned the BT_FUSE_SEL to avoid caring of the state of the boot config pins.
Let me know if this helps!
Diego
Hi Diego,
I didn´t understand how to read those registers because the software is running in release mode instead of debug mode.
Should I put the software in debug mode and be able to read those registers?
Best regards,
Alvaro
Hi Alvaro,
Thanks for letting me know! I would expect that to read those registers the optimization level does not care, but lets check, sometimes code variables are optimized out and you can't read them. Are you using MCUXpresso IDE or which IDE? Which debug probe?
The important thing is to get the content of the address of the registers.
All the best,
Diego
Hi Diego,
I am using MCUXpresso IDE, and my debug probe is MCU Link Debug Probe. Follow the link:
Talking about register content. When I am running the code using the debug tool in Debug Mode
, I can see the registers, put breakpoints, etc. But when I flash the program, using GUI Flash Tool
the code runs, and I don´t have control of the code running through Debug tool. The only way that I can see the registers is in Debug mode through the Debug tool.
Best regards,
Alvaro