i.MX RT1176 burn eFuses FlexRAM - now no flash communication

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX RT1176 burn eFuses FlexRAM - now no flash communication

Jump to solution
4,240 Views
D_TTSA
Contributor V

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:

D_Tram23_0-1635243859654.png

I wanted to finalise this configuration, so I fused the FlexRAM fuses like this:

D_Tram23_1-1635243859924.png

However, now I can’t communicate with the board anymore.

I can’t write to the flash in ISP mode:
D_Tram23_2-1635243860003.png

I tried using the JTAG probe (ISP mode) to clear the flash with MCUXpresso IDE’s flash tool, but that also doesn’t work:

D_Tram23_3-1635243860106.png

Neither does trying to debug the board with the JTAG (normal mode):

D_Tram23_4-1635243860250.png

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:D_Tram23_5-1635243860274.png

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!

0 Kudos
1 Solution
4,138 Views
D_TTSA
Contributor V

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.

View solution in original post

0 Kudos
21 Replies
4,079 Views
kerryzhou
NXP TechSupport
NXP TechSupport

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.

kerryzhou_0-1635496417298.pngkerryzhou_1-1635496421763.png

 

 

 

Any updated information, just kindly let me know.

best Regards,

Kerry

0 Kudos
4,069 Views
D_TTSA
Contributor V

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.

  1. I put the jumper on the correct pins to ensure the board is in ISP mode (definitely correct pins - it worked before)
  2. Force probe re-discovery and click debug:
    D_Tram23_0-1635497480638.png

     

  3. Click OK to let the debug run. I get the following output:

    D_Tram23_1-1635497534713.png

    The console shows:

    D_Tram23_2-1635497571837.png

     

 

Additional information (showing DCD file from MCUXpresso Provisioning Tool and Vendor & Product ID):

D_Tram23_3-1635497750320.png

 

0 Kudos
4,065 Views
kerryzhou
NXP TechSupport
NXP TechSupport

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

 

0 Kudos
4,139 Views
D_TTSA
Contributor V

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.

0 Kudos
4,036 Views
kerryzhou
NXP TechSupport
NXP TechSupport

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

0 Kudos
4,027 Views
D_TTSA
Contributor V

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.

0 Kudos
4,019 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi  @D_TTSA ,

  Relocate the flashloader can check with this post:

https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/How-to-create-a-new-Flash-driver-of-the-MCUXPres...

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

 

0 Kudos
4,017 Views
D_TTSA
Contributor V

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.

0 Kudos
4,011 Views
kerryzhou
NXP TechSupport
NXP TechSupport

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.

kerryzhou_0-1635748993411.png

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

 

 

0 Kudos
3,989 Views
D_TTSA
Contributor V

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.

0 Kudos
3,978 Views
kerryzhou
NXP TechSupport
NXP TechSupport

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

0 Kudos
3,973 Views
D_TTSA
Contributor V

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. 

0 Kudos
3,962 Views
kerryzhou
NXP TechSupport
NXP TechSupport

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

  

0 Kudos
4,152 Views
Masmiseim
Senior Contributor I

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:

  • Establish a connection via JTAG
  • Load a Loader-SW to the internal RAM of the controller and start it.
    • The Loader Software is initializing the Memory interface to the flash
    • Communicating with the IDE via a memory-mapped protocol.
    • Receiving the application, you like to write to the external memory (via RAM)
    • Write the application to flash

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:

  • Recompile your loader to run from OCRAM
  • Do the reconfiguration of the FlexRAM not via fuses but reconfigure it on startup (SystemInitHook would be a good place to do this).

Best regards

0 Kudos
4,147 Views
D_TTSA
Contributor V

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.

0 Kudos
4,142 Views
Masmiseim
Senior Contributor I

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):

Masmiseim_0-1635261144755.png

Masmiseim_1-1635261144765.png

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

0 Kudos
4,122 Views
D_TTSA
Contributor V

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:

D_Tram23_0-1635338094345.png

 

0 Kudos
4,104 Views
Masmiseim
Senior Contributor I

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):

Masmiseim_0-1635421166552.png

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.

Masmiseim_1-1635421166554.png

 

Is this the case, or does it disconnect at some time?

 

Best Regards

0 Kudos
4,101 Views
D_TTSA
Contributor V

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:

D_Tram23_1-1635421563411.png

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

0 Kudos
4,084 Views
Masmiseim
Senior Contributor I

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

0 Kudos