We have a custom i.MXRT1170 board which we are able to load code onto and it functions correctly. However this is only the case if we load and execute code from RAM. When attempting to load code into FLASH the stack seems to be completely missing (0B used) and then it tries to return and gets a stack overflow. Loading the same code onto the EVK results in it working correctly.
Attached are photos of the code in the same place on the working EVK and the custom board with the stack overflow.
Both boards have IS25WP QSPI flash connected to FlexSPI_A
Solved! Go to Solution.
We were able to solve our problem it had to do with incorrect boot config pins being read in at reset. By fixing the problem we now have correct code execution.
Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
Firstly, I'd like to know the memory configuration of the demo project,
further, I'd like to suggest you use the tool to build a connection with the QSPI flash to verify the hardware connection.
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.
-------------------------------------------------------------------------------
RE memory configuration: I am using the same memory configuration that is in the SDK example "evkmimxrt1170_iled_blinky_cm7". I have also attached a screenshot of the MCU Settings showing the memory details.
Using the NXP MCU Boot Utility I am able to load the same hex file (generated in MCUXpresso) onto both the EVK and my board. After loading I am able to read back the flash and the two are almost identical. The only difference is at address 0x30000450, I have attached a picture of the comparison with my board on the left and the EVK on the right. After the code is loaded I reboot each device to boot from QSPI Flash and the EVK works but my board does not blink and seems to be exhibiting the same behavior as when I loaded code over SWD. I believe this shows that the two bards are both having code loaded correctly and are able to communicate with the FLASH.
I also see that my RT117x is "RT1176AVM8A" while the EVK has "RT1176DVMAA" the differences being temp range and core clock frequency. I attempted to turn the core clock down to 792MHz using MCUXpresso however that did not make any difference and it still had no stack.
Hi,
Thanks for your reply.
It seems a bit weird, whether the phenomenon happens in your all custom boards, and maybe you can try to read whole image out of the EVK board, then program the custom board for testing.
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.
-------------------------------------------------------------------------------
I am using the same HEX file to program both our custom board and the EVK. The only difference is on byte at 0x30000450. I have attached a text file copied out of the "boot device memory" tab in NXP MCU Boot Utility for both the EVK and our board.
I do not know how to program a board with an image read out from the tool. I can save it to a .dat file but the tool doesn't allow me to program with the .dat file.
Hi,
Thanks for your reply.
Actually, you can modify the .dat to .bin directly, then you can MCU Boot Utility tool to write the .bin file back to the QSPI.
Further, you can clarify my previous inquiry: whether the phenomenon happens in your all custom boards.
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,
Please follow the below steps to program this bin file.
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.
-------------------------------------------------------------------------------
Ok, I did that, and it behaves the same as before... no blinking light. I can read back the memory and it is the same as what I read out of the EVK.
Without the ability to debug I can't say for sure what is happening but when I do have debug, by loading code through MCUXpresso. I am able to see that the stack pointer register does not decrement.
Hi,
Thanks for your reply.
It seems a bit weird and I also have no idea yet.
Maybe you can send me a custom board, it can help me to dig deeper into the phenomenon.
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.
-------------------------------------------------------------------------------
We were able to solve our problem it had to do with incorrect boot config pins being read in at reset. By fixing the problem we now have correct code execution.