Hello,
I'm trying to reset the RT1062 MCU via software. Some tests with different methods failed:
After calling one of the them, the MCU hangs, maybe in the ROM bootloader.
The firmware image resides in the external NOR flash. The internal ROM bootloader loads the boot image into OCRAM and will be executed from this location.
How is a software reset performed on RT1062 MCUs?
Solved! Go to Solution.
Hi,
We have received a lot of questions about this lately (maybe because of this discussion) so we have released an example project for software reset, you can download our latest patched SDK from here: http://imx.embeddedartists.com/#imxrt1062
Direct link: http://imx.embeddedartists.com/imxrt/eaimxrt1062_sdk_2.9.3_2021-05-10.zip
The project can be found in this path: \boards\evkmimxrt1060\ea\software_reset
The reset code implements a JEDEC reset for the external serial flash before executing the system reset.
Hope this helps.
Kind Regards,
Anders Rosvall
Embedded Artists AB
Hi,
We have received a lot of questions about this lately (maybe because of this discussion) so we have released an example project for software reset, you can download our latest patched SDK from here: http://imx.embeddedartists.com/#imxrt1062
Direct link: http://imx.embeddedartists.com/imxrt/eaimxrt1062_sdk_2.9.3_2021-05-10.zip
The project can be found in this path: \boards\evkmimxrt1060\ea\software_reset
The reset code implements a JEDEC reset for the external serial flash before executing the system reset.
Hope this helps.
Kind Regards,
Anders Rosvall
Embedded Artists AB
Check the base url: http://imx.embeddedartists.com/#imxrt1062 to access the latest uploads.
Hello,
after investigating several hours, the reason for the behavior is the missing reset of the external flash chip. (as @Masmiseim suggested) Without flash chip-reset the internal ROM boot loader can't start from the flash chip and boots into the serial download mode. Some flash chips are able to perform an in-band reset (JEDEC Hardware reset), like the one on Embedded Artist RT1062 OEM board (Adesto ATXP032).
The JEDEC reset might be supported by a RT1062 fuse, but there is no documentation in the processor reference manual. At the time now, I've no access to the security manual, it might be documented there.
Another idea (that was working) is to reset the flash chip before calling NVIC_SystemReset(). The flash chip pins have to re-programmed to GPIOs and the JEDEC reset has to be performed via bit-banging. The code that performs the reset has to run from RAM, because the flash is not accessible in this time.
Here is a C++ sample:
constexpr uint8_t CS = 6;
constexpr uint8_t SCLK = 7;
constexpr uint8_t D0 = 8;
gpio_pin_config_t gpio_config = {kGPIO_DigitalOutput, 1, kGPIO_NoIntmode};
// CS
IOMUXC_SetPinMux(IOMUXC_GPIO_SD_B1_06_GPIO3_IO06, 0);
IOMUXC_SetPinConfig(IOMUXC_GPIO_SD_B1_06_GPIO3_IO06, 0x10B0u);
GPIO_PinInit(GPIO3, CS, &gpio_config);
// SCLK
IOMUXC_SetPinMux(IOMUXC_GPIO_SD_B1_07_GPIO3_IO07, 0);
IOMUXC_SetPinConfig(IOMUXC_GPIO_SD_B1_07_GPIO3_IO07, 0x10B0u);
gpio_config.outputLogic = 0;
GPIO_PinInit(GPIO3, SCLK, &gpio_config);
// DATA0
IOMUXC_SetPinMux(IOMUXC_GPIO_SD_B1_08_GPIO3_IO08, 0);
IOMUXC_SetPinConfig(IOMUXC_GPIO_SD_B1_08_GPIO3_IO08, 0x10B0u);
GPIO_PinInit(GPIO3, D0, &gpio_config);
// CS:1 SCLK:0 DATA0:0
GPIO_PinWrite(GPIO3, SCLK, 0);
GPIO_PinWrite(GPIO3, CS, 0);
nop<10>();
GPIO_PinWrite(GPIO3, D0, 0); // 0
nop<10>();
GPIO_PinWrite(GPIO3, CS, 1);
nop<10>();
GPIO_PinWrite(GPIO3, D0, 1); // 1
nop<10>();
GPIO_PinWrite(GPIO3, CS, 0);
nop<10>();
GPIO_PinWrite(GPIO3, CS, 1);
nop<10>();
GPIO_PinWrite(GPIO3, D0, 0); // 0
nop<10>();
GPIO_PinWrite(GPIO3, CS, 0);
nop<10>();
GPIO_PinWrite(GPIO3, CS, 1);
nop<10>();
GPIO_PinWrite(GPIO3, D0, 1); // 1
nop<10>();
GPIO_PinWrite(GPIO3, CS, 0);
nop<10>();
GPIO_PinWrite(GPIO3, CS, 1);
for(uint32_t n=0; n<100; n++) { // give time to flash chip to reset
nop<100>();
}
NVIC_SystemReset();
The nop<N>() template function performs NOP's (GCC):
template<int N> __attribute__((always_inline)) inline void nop()
{
nop<N-1>();
asm volatile ("nop");
}
template<> __attribute__((always_inline)) inline void nop<0>() {}
The number of NOP's has to be set according to the timings for the flash chip.
Regards, Sven
Hi,
Thanks for your reply.
@Masmiseim is right, after setting the 0x6e0[6] bit, the ROM boot can execute the JEDEC standard reset (as below shows). So I'd like to suggest you take the @Masmiseim 's advice if your board is suitable.
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hello TIC,
where can I find the documentation about the 0x6e0[6] fuse?
Regards,
Sven
Hi,
1) Where can I find the documentation about the 0x6e0[6] fuse?
-- Please check the following figure.
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi,
Thanks for your reply.
I was wondering if you can upload your testing code and introduce the testing steps in brief, as I'd like to replicate the phenomenon.
Looking forward to your reply.
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi Svenifax
I'm also using the same board as you and trying to do a software reset without any luck. My only difference is that I'm running code direct from Flash (XiP). Other than that I seem to have tried everything you have.
The only success I've had is with the watchdog. Did you manage to get this working?
I believe I still need to perform a software reset as I'm trying to use non initialised RAM to communicate with a bootloader and a watchdog reset seems to reset the RAM too.
Regards
Hallo Gra67,
the watchdog does not reset the RAM.
Sadly, the schematics of the Embedded Artist board are not publicly available, but I guess they do it like it is done on the evaluation board of the iMXRT1060.
When the watchdog is triggered, the whole controller gets a power-on-reset. Compare the Schematics from the Evaluation-Board below. As a side-Effect you are also not able to read the reset-reason on start-up.
You could try to configure the Pin GPIO_B1_13 to GPIO to avoid the POR. At least if it is done the same way as the evaluation-Board.
Regarding the original problem. Check the application-Note AN106A1 from Adesto:
Regards
Hello Svenifax,
do you use the NXP Evaluation-board or an own design? If you are using your own design which Flash model do you use?
regards
Hello Masmiseim,
we are using the Embedded Artists iMX RT1062 OEM board.
https://www.embeddedartists.com/products/imx-rt1062-oem/
The Flash used on SOM is a ATXP032 (4 MByte EcoXiP from Adesto)
https://www.dialog-semiconductor.com/sites/default/files/ds-atxp032.pdf
Software reset doesn't work ether on our custom board using the OEM board or the Embedded Artists developer board.
Regards, Sven
Hello Svenifax,
this is what I thought. The .MX RT1xxx boot ROM needs to reset the Flash via JEDEC-Reset on boot otherwise it loses synchronization and the controller hangs. To solve this, a i.MX RT1xxx boot ROM option must be enabled to automatically apply a JEDEC reset to the Adesto Flash right after the MCU reset. Adesto has published an application note for this:
https://cdn2.hubspot.net/hubfs/5196899/AN106A1.pdf
regards
Hi Sven
Try this on your board:
https://www.utasker.com/iMX/iMX_RT1062_OEM.html
It contains commands in it administration menu to reset and test watchdog - if it works on your HW it points to a SW issue. I can then give you the exact code to avoid difficulties.
Se also https://www.youtube.com/watch?v=o7hQbOqhJoc for a complete secure loader concept for Embedded Artist users.
Regards
Mark
Hello Mark,
the binaries you pointed out are working well. Reset functionality controlled by the menu works as expected.
So it seems to be a software issue in my application.
I tested the NXP eaimxrt1062_freertos_hello example, a reset does also not work. Maybe an configuration issue in Flash or DCD config?
Regards,
Sven
Hi Sven
Are the references that you are testing running from RAM or are they programmed in QSPI flash?
If they run I RAM it may be normal that they don't work because, as you suggest, they have no valid flash configuration and so will cause the ROM loader to be entered after each reset.
Regards
Mark
P.S. In case you need a complete solution for your EA based development (Ethernet, TCP/IP, WiFi, file systems in SD card and Adesto EcoXiP flash, TFT and touch, Modbus, dual HSUSB host/device classes, secure OTA and field programming, fastest operation with lowest power consumption and lowest radiation, FreeRTOS option, i.MX RT 1062 based project simulation in Visual Studio and one-on-one developer support) also consider the uTasker project as fast, reliable and complete product development route.
Sven
DCD should be of no relevance but if you are booting example SDK projects from EcoXiP you need to see whether they can boot themselves (without debugger) first to see whether they are operational (and therefore can also handle a SW reset or watchdog case).
In some cases, when the flash configuration is not correct, a download with the debugger may work since it sets the SP and PC accordingly but the ROM loader fails since it doesn't configure the EcoXip as needed for it to boot.
Check the evkmimxtr1060_flexspi_nor_config.c and h that are being used and ensure that it has the following in it:
" /* This is a Serial NOR Configuration Block definition for Adesto's EcoXiP
* flash (ATXP032). Among other parameters it configues the system to operate
* with:
* - Octal-SPI
* - Double Data Rate (DDR)
* - SCLK = 133MHz
*/"
Check also that your own application can start without the debugger and that your issue is not restricted to commanded and watchdog resets, but may be more general.
Regards
Mark
Hello Mark,
the EA examples I've used have the following proprieties:
To test the Flash configuration, I replaced the flash section of the sample binary with the one from uTaskerSerialLoader_i.MX-RT1062_OEM_USB-MSD_Kboot-HID_SREC-UART_SD-Card_AES256.bin. A software reset is also not possible with the patched example.
Are there some prerequisites before calling NVIC_SystemReset() ?
Sven
I think you have excluded that there is an issue with the flash configuration therefore the problem must be with the SW reset code.
- Check that it is not being optimised out
- put SW delays before and after the instructions (I have a number of users of the uTasker loader who need to reset SDK developed applications to it and remember at least one saying that the reset would only work if delays were added somewhere in the related code)
uTasker applications on the EA boards reset to the loader via a RAM mailbox as follows (or standard SW reset if mailbox not set):
*BOOT_MAIL_BOX = RESET_TO_SERIAL_LOADER; // put a message in the boot mailbox and reset the board (if the serial loader is installed and uses the mailbox it will cause the loader to start)
fnResetBoard();
and uses
// This routine is called to reset the processor
//
extern void fnResetBoard(void)
{
uDisable_Interrupt();
APPLICATION_INT_RESET_CTR_REG = (VECTKEY | SYSRESETREQ); // request cortex core reset, which will cause the software reset bit to be set in the mode controller for recognition after restart
IOMUXC_GPR_GPR16 = (IOMUXC_GPR_GPR16_RESERVED | IOMUXC_GPR_GPR16_INIT_ITCM_EN | IOMUXC_GPR_GPR16_INIT_DTCM_EN); // set the FlexRAM layout back to that taken from the eFuse setting (default configuration) - although the reset is commanded before executing this line it still operates and avoids the RAM layout being changed when the code is still running
FOREVER_LOOP() {}
}
The FlexRAM restore is only needed when using dynamically configured FlexRAM settings.
Regards
Mark
Hello Mark,
could please tell me the predefined values of your sample code?
Is APPLICATION_INT_RESET_CTR_REG the SRC Control Register (SRC_SCR) / 400F_8000?
What's the value of VECTKEY? Is SYSRESETREQ bit 13 of SRC_SCR (core0_rst)?
What's the value of IOMUXC_GPR_GPR16_RESERVED?
Thanks, Sven