Good day
I am using NXP's i.MX RT1176 processor on Embedded Artists' uCOM carrier board.
We wanted to use 512kB DTCM, 0kB ITCM and 0kB OCRAM as our FlexRAM configuration.
The IMXRT1170RM gives this table:
I wanted to finalise this configuration, so I fused the FlexRAM fuses like this:
However, now I can’t communicate with the board anymore.
I can’t write to the flash in ISP mode:
I tried using the JTAG probe (ISP mode) to clear the flash with MCUXpresso IDE’s flash tool, but that also doesn’t work:
Neither does trying to debug the board with the JTAG (normal mode):
I thought it may be that the RT1176 doesn’t have any OCRAM for the bootloader to run in. This was based on the assumption that the bootloader runs in the OCRAM. Anyway, I believe there is OCRAM that is not part of the FlexRAM in the RT1176, so this isn’t the problem:
I did not burn any of the other fuses.
Does anyone know why I can’t communicate with the board after burning the FlexRAM fuses?
Thanks in advance!
解決済! 解決策の投稿を見る。
Hi @kerryzhou
We have decided to move away from our 512kB DTC FlexRAM configuration.
It seems to be causing many more problems than the worth it provides.
We needed to fuse this configuration because we were getting a hardfault when doing the FlexRAM using the registers.
Anyway, since we are no longer using the FlexRAM, this is no longer an issue, so I'm going to close this thread.
Thank you @Masmiseim and @kerryzhou for your suggestions.
Hi @D_TTSA ,
Do you mean, you enter the serial download mode, and can't connect the board?
If yes, do you have debugger on your side, eg, Segger JLINK, then you use the JLINK command to connect your board through the SWD interface at first, whether you can find the ARM core or not?
Except the com port, whether your board also leave the USB for the RT1170 USB HID connect in the serial download mode?
If you just burn the flexRAM fuse, it won't influence the external flash.
Please also use the MCUbootUtility to connect your board in the serial download mode, whether the same result or not, you can try the USB HID method, as the COM may not be stable in your board.
https://github.com/JayHeng/NXP-MCUBootUtility/archive/refs/tags/v3.3.1.zip
the related user manual is:
https://github.com/JayHeng/NXP-MCUBootUtility
Please also note, in your app code, don't use the whole OCRAM1, as that is the ROM used area.
Any updated information, just kindly let me know.
best Regards,
Kerry
I'm going to step through the process of trying to debug the board with the JTAG debugging probe.
I'm not sure if I fully understand what you are asking, so hopefully this will answer your questions.
Click OK to let the debug run. I get the following output:
The console shows:
Additional information (showing DCD file from MCUXpresso Provisioning Tool and Vendor & Product ID):
Hi @D_TTSA ,
What's the board you are using? NXP official board or your own designed board?
What's the external flash you are using?
Just from your debug log, the CMSIS DAP also find the ARM core, but seems can't load the flashloader.
So, this should also related to the flashloader which used the RAM memory which you have disabled.
Now, MCUbootUtility also can't be connected, right? If yes, please try this:
close MCUbootUtility, power off your board.
open the MCUbootUtility, configure the right flash, then use the USB connect, then if failed connect, share me your whole log, I need to check it. Seems it also related to the MCUbootUtility flashloader which is loaded to the internal ITCM area, but you already disabled.
So, if it is confirmed, I think, you need to use the blhost and sdphost, download the flashloader file to the opened DTCM, then jumpt to that area, then run it, that method should be OK.
In fact, if you still in the design phase, why you write the fuse? Normally, we will use the GPR register modify the flexRAM for testing, after you already in the product phase, then you can burn fuse to disable the OCRAM and the ITCM.
Just check it at first, if you still in design phase, it is a little complicate to you now in both the GUI tool download and the IDE, as the IDE related flashlaoder should also modify the source code and relocate the RAM to your opened DTCM.
Best Regards,
Kerry
Hi @kerryzhou
We have decided to move away from our 512kB DTC FlexRAM configuration.
It seems to be causing many more problems than the worth it provides.
We needed to fuse this configuration because we were getting a hardfault when doing the FlexRAM using the registers.
Anyway, since we are no longer using the FlexRAM, this is no longer an issue, so I'm going to close this thread.
Thank you @Masmiseim and @kerryzhou for your suggestions.
Hi @D_TTSA ,
Thanks so much for your effort.
When you meet any issues to do the register configuration, eg, hardfault.
This is still the IDE flashloader location issues, and we need to rebuild the flashloader to the used area.
Eg, flashloader use the ITCM, but when you register disable it, it may have the download or debug issues.
In fact, it is also easy to solve it, just move flashloader to the DTCM.
Anyway, if you need this area help in the future, just create the post and let me know, we will help you.
Best Regards,
Kerry
Thank you @kerryzhou .
"Easy" is a relative term... because I have not found how to "just move the flashloader to the DTCM" described anywhere.
If you could describe this process for future use, that would be great.
To give more context on the reason I tried to burn these fuses:
If "Project Properties -> C/C++ Build -> Settings -> Managed Linker Script -> Stack -> Location" is set to "Start", the no_padding.bin file generated by MCUXpresso Secure Provisioning Tool is too large to fit into the FLASH (it is 262MB). The default setting for this is "End", but if I set it to "End" then setting the FlexRAM via the GPR in the ResetISR() causes a hard fault (this is the reason for why we changed it to "Start").
So my thoughts were that if I could fuse the flexRAM for the config we wanted (512kB DTCM), then we wouldn't need this code in the ResetISR(), which would mean we wouldn't get a hardfault there with Stack location = "End". And if stack location = "End", the .bin file size is normal (358 kB) and it can be uploaded to the board.
Hi @D_TTSA ,
Relocate the flashloader can check with this post:
But, until now, the MCUXpresso IDE didn't share the RT1170 flashloader source code in folder now:
C:\nxp\MCUXpressoIDE_11.4.1_6260\ide\Examples\Flashdrivers\NXP\iMXRT
About the fuse, I still don't recommend you modify it in the design phase. After everything works OK, then you can modify the fuse.
Best Regards,
Kerry
Thanks @kerryzhou
Do you know anything about the Stack location setting messing up the binary file then?
Other than burning the eFuses, I don't see a solution.
Hi @D_TTSA ,
When do the register flexRAM modification, we also modify the stack from end to start in the MCUXpresso IDE, this is the know issues.
BTW, when debug, the script .scp also need to add the register reconfiguration.
This post also have the detail talking about the flexram reconfiguraiton.
https://community.nxp.com/t5/i-MX-RT/FlexRAM-and-Linker-Problem/m-p/990512
Best Regards,
Kerry
Hi @kerryzhou
So you're saying that it is a known issue that one cannot load a program via ISP mode (using the .bin file) to the processor's flash if you use FlexRAM....
Because if you use FlexRAM, you need to change the stack start from "End" to "Start" and this results in a .bin too big to fit in the external flash memory....
If so, that is extremely frustrating. Why is this not stated anywhere? What is the point in providing FlexRAM as a feature if NXP knows it will fail when uploading a program to flash without the JTAG probe?
Surely this is something that needs to be fixed.
Hi @D_TTSA ,
In fact, about your flexRAM use issues after you disable the ITCM, DTCM or the OCRAM. It is not the issues, just the usage experience.
As you know, when debugger or download in serial download mode, it need to load the flashloader at first to the internal RAM, if you don't disable the ITCM, DTCM, it's OK, but when you disable one, it will related to where you put your flashloader, if your flashloader orginally put in the ITCM, and you disable the ITCM, it will has issues, the flashloader can't download to the ITCM anymore, at this time, customer need to move the flashload to the DTCM or others which didn't disabled, so it is not the issue, just the usage experience.
Wish it helps you!
Best Regards,
Kerry
I am talking about the necessity to move the Stack location to "Start" instead of "End", which is supposedly required to use FlexRAM.
This necessity means you can't upload programs to the board's flash because of the size of the .bin file, NOT because of the inability to run the flashloader.
Hi @D_TTSA ,
Please take easy!
Now, let create a new topic about the stack position for the flexRAM reconfiguration.
Could you please create a new post about it?
Then, let's just use the case which didn't modify the fuse, just modify the flexRAM register as the example, I will help you test(prepare the related flashdriver) and do more deep checking, and about the mcuxpresso IDE stack position why must neet to put to the "start', I will also check with our internal expert team.
In your new post, please also tell me your desired flexRAM configuration again.
I would like to help you do more checking.
Best Regards,
Kerry
Hey D_Tram23,
you should still be able to load and execute an application to OCRAM, right? You have this problem only when trying to load an application to the external flash?
When trying to load a software to the external memory, the following is done:
I think your loader-SW is build for the default memory configuration. If you change this configuration the IDE is not able anymore to write to this memory areas. In your case to the ITCM.
What you can do:
Best regards
Hi @Masmiseim
Thank you for your quick response!
I don't think I can load and execute an application from OCRAM.
To test this, I imported the eaimxrt1176_hello_world_demo_cm7 SDK example project (a basic, single-core hello world) to my workspace.
In MCUXpresso, I enabled "Link application to RAM" to place the program in, and run it from, RAM.
I made an OCRAM section the first RAM block, as this will be the block that the program is loaded into (stated in MCUXpresso IDE User Guide).
However, this also generated a hardfault (IMPRECISERR) during loading via the JTAG probe (same for both ISP & normal mode).
I also tried loading the program into the BOARD_SDRAM & into SRAM_ITC_cm7.
Using BOARD_SDRAM returns "Target error from Write Memory - Debug port inaccessible after access at location 0x80000000".
The SRAM_ITC_cm7 block returns a "Load-failed" error.
With regards to your two suggestions:
1. "Recompile your loader to run from OCRAM" - I'm quite certain that the boot loader runs from OCRAM. I have attached the .map file of the bootloader SDK example.
2. "Do the reconfiguration of the FlexRAM not via fuses but reconfigure it on startup" - Unfortunately this isn't an option for my application - I need to burn the eFuses.
Hello D_Tram23,
you are correct. The Loader from the MCUXpresso IDE is located in the DTCM only, at least the one I have checked. So, this should not be the problem.
However, in your script for writing to the flash you are accessing the ITCM (Address 0x2000):
You could also try to change the Boot Mode to “Serial Downloader” and try to write to the flash.
Have you already tried to use the NXP-MCUBootUtility (https://github.com/JayHeng/NXP-MCUBootUtility.git)?
Best Reagrds
Hi @Masmiseim
I can't access the board's flash from MCUXpresso's loader or the Secure Provision Tool's loader. So I'm not entirely sure if this is the issue?
I have tried putting the board in ISP mode (I think this is the same as Serial Download mode?), but this doesn't change the results.
I am pretty sure that NXP-MCUBootUtility uses the same underlying components - but I tried it anyway. I got this error message when trying to connect to the ROM:
Hello D_Tram23,
the Bootmode can be configured with the two pins GPIO_LPSR_02 (Boot Mode 0) and GPIO_LPSR_03 (Boot Mode 1):
Compare the schematics of the evaluation board.
According to your screenshot it looks like the MCU Boot Utility can not detect the USB device ID of your board.
Is this the case, or does it disconnect at some time?
Best Regards
Hi @Masmiseim
Thank you for your reply.
I am aware of the Boot mode pin settings, but since I cannot program the board right now, I cannot change their values.
If I un-tick the "One step" setting in MCU Boot Utility, I can connect to the board:
But then if I click on "Connect to Flashloader", the board loses connection and I end up with the view you have shown - the vendor & product ID is not detected.
Kind regards
Hello D_Tram23,
MCU Boot Utility opens a console-window when started. Could you check if there is any access to the ITCM done via blhost.
Beside this I do not have any additional ideas. Maybe NXP can help here better.
Best regards