RT1170 EVKB fsl_romapi does not work

[johannzimmerman]

Hi there,

just looking at the RT1170 EVKB fsl_romapi CM7 Example... IAR1.50.1 flex_nor_debug , SDK 2.15
Built and debugged the project fine; it was able to successfully identify and erase/program the NOR Flash.

The example only runs when flashed and started via Debbuger.
After power on without IAR debugger, the board/CPU restarts when the function
ROM_FLEXSPI_NorFlash_GetConfig() is called.

I have not made any changes to the example.
All board jumpers are default.

What could be the problem?

Thank you,
Johann

[diego_charles]

Hi @johannzimmerman 

Thank you for your report!

Currently, the easiest way to get the demo working by  using SRAM debug, or link to RAM.

[johannzimmerman]

link to RAM has no positive effect.
This example works only in the debugger environment.

[diego_charles]

Hi @johannzimmerman  and @sandeepc 

Thank you for your reports. 

I reported this issue and the SDK team is now aware of this bug. 

The investigation started, but I yet I do not have an exact  date for getting this fixed.

@johannzimmerman after you link the example to RAM did you get it working, but after making a reset the image was lost?

Thank you.  

[johannzimmerman]

The fsl_romapi examples all work if you flash and start them in EWARM via SIMIS-DAP.
After a cold reset, the CPU starts (or resets itself) in the function ROM_FLEXSPI_NorFlash_GetConfig().
Regardless of whether it is stored in RAM as __ramfunc or in flash.
With “Attach to Runnig Target” the CPU is executed from the address 0x223104.

[sandeepc]

 even i tried with the example

status = ROM_FLEXSPI_NorFlash_GetConfig(FlexSpiInstance, &norConfig, &option);

while executing above line wireack fault occuring.

@diego_charles 

Regards

Sandeep C

[diego_charles]

@sandeepc 

Thanks for trying out, this issue  is already reported.

[sandeepc]

Any update?

[diego_charles]

Hi @sandeepc and @johannzimmerman 

Please replace the contents of the evkbmimxrt1170_flexspi_nor_config.c file with the contents of the attached file below and let me know your results. 

Or, from the current evkbmimxrt1170_flexspi_nor_config.c from the SDK 2.15 replace

#define FLASH_DUMMY_CYCLES 0x08
#define FLASH_DUMMY_VALUE  0x03

With 

#define FLASH_DUMMY_CYCLES 0x06
#define FLASH_DUMMY_VALUE  0x00

Diego

[sandeepc]

hi @diego_charles @johannzimmerman @kerryzhou 

Controller :MIMXRT1176AVM8A

SDK version: 2.14.0 and 2.15.100

IDE version: 11.8.0 and 11.9.1

I tried as you mentioned in the post but still it didn't worked for me.

We used Winbond W25Q64JVSSIQ but it does not supports, RWW(read while write),. so we are trying to use ROM API to write to the flash when in XIP.

1st try:

So for this I tried by importing the example: evkmimxrt1170_fsl_romapi_cm7.
before dumping code the code i modified evkmimxrt1170_flexspi_nor_config.c as below

.readSampleClksrc=kFlexSPIReadSampleClk_LoopbackInternally,
.serialClkFreq = kFlexSpiSerialClk_100MHz,

after this i dumped the code.

In debug mode ROM_FLEXSPI_NorFlash_GetConfig when this function is called got below fault:
Break address to 0x35052 with no debug information available or outside of program code.

try2:

I tried with as you suggested by replacing evkmimxrt1170_flexspi_nor_config.c with SDK version 2.14.0 still its not working.

Try 3:

i tried with as in the link mention SDK version 2.15.1 just by changing MACRO's still its not working .

Try 4:

by removing OCRAM region also still didn't worked out.

Working: When i link whole application to the RAM, but for our case it should work in XIP mode

Schematic:

I tried all the ways as you mentioned please look in to my shared files.

Can you share the working code.

Regards,

Sandeep c

[diego_charles]

Hi @sandeepc 

Thanks for reaching out. 

I see that you are using a similar NOR flash memory to the one in the EVK ( W25Q512NWEIQ). You need a bit different flash memory configuration to make the Boot ROM API work. So, I think your problem can be solved with another configuration to your flash memory. With the below steps I show you how to use a generic config using the MCUXpresso secure provisioning tool.

See my steps below.

1 Provide the flash an offset of 0x3000_2000.

2. Disable XIP header.  

This means that the QSPI flash config structure of your project will not longer added to the image 

3 build the image and create a binary.

4 Download and install the MCUXpresso Secure Provisioning Tool.

5 Create a new workspace for the RT1170. 

6 Connect your RT1170 to the SPT tool. You will need to be able to set the MCU to boot from serial downloader mode and use the UART1 or USB1 ports. 

7 Test  and adjust your memory configuration. 

If the test fails you may need to do any adjust to your memory configuration. Let me know if required to change any paramater to make test be succesfull. 

8. Provide your image to the SPT and build it. 

9.Write the image

10. Set the RT1170 to boot again to 'internal boot ' mode. Connect a serial terminal emulator. 

I was able to make the SDK 2.15 ROM API demo this way. The SPT generated a basic flash memory config that allowed the boot ROM APIs to write the application. I tested this with the W25Q512NWEIQ flash from the EVK.

I hope this could help you!

Diego

[sandeepc]

Thanks for the detailed reply, 

I tried as you suggested to follow step by step still its not working.

here i will share my modified example code can you check with your evk board, so that i can ask our hardware team to review our schematic.

here i attached complete description document, as well as two zip files.

1) Description with detailed iamges

2)1st try zip file description:

just imported the example and i modified according to your steps

3) 2nd try zip file

i modified core clock to 800MHz

       a)Option 0 clock to : 100 Mhz

       b)Option 0 clock to : 30 Mhz

Note: As per this link

RT1176 - flexSPI DQS connection for max R/W speed - NXP Community

Solved: SEMC_DQS and FLEXSPI_DQS signal in iMXRT117x - NXP Community

we have not left E14 pin as floating, E14 pin in our application used for one of the peripheral interrupt pin, so we cant left as floating. 

so we changed in xip file 

flexspi_nor_config_t :

from

.readSampleClksrc=kFlexSPIReadSampleClk_LoopbackFromDqsPad,

.serialClkFreq = kFlexSpiSerialClk_133MHz,

to

.readSampleClksrc=kFlexSPIReadSampleClk_LoopbackInternally ,

.serialClkFreq = kFlexSpiSerialClk_100MHz

but if disable According step2:Disable XIP header. 

readSampleClkSrc will be what? if i want change how can i change?

Regards, 

Sandeep C

[diego_charles]

Hi @sandeepc 

Thank you very much for testing according to my instructions and for your detailed PDF. I just want to ask some things.

Just to double check, the demo worked well, when you linked it to RAM, at least temporally, while the debugger is connected. Correct? Currently I do not know if this a bootROM issue or FlexSPI configuration issue on the FCB.

Secondly,  I understand that your design does not have the DQS floating, you need to use internal loopback. Correct? This means that if you  update the evkbmimxrt1170_flexspi_nor_config_214.c, that I shared here to use internal loopback, the failure is still there, right?

According to my investigation, our MCUXpresso Secure Provisioning Tool does not lets you to configure the DQS option ( readSampleClkSrc). 

Thank you for your efforts and patience.

Diego

[sandeepc]

Thanks for the reply @diego_charles .

Just to double check, the demo worked well, when you linked it to RAM, at least temporally, while the debugger is connected. Correct? Currently I do not know if this a bootROM issue or FlexSPI configuration issue on the FCB.

           Yes its working linked application to RAM.

Secondly,  I understand that your design does not have the DQS floating, you need to use internal loopback. Correct? This means that if you  update the evkbmimxrt1170_flexspi_nor_config_214.c, that I shared here to use internal loopback, the failure is still there, right?

       Yes, still not working.

We are going for the next version hardware, so we left DQS pin as floating, After that i will try and update you.

Regards,

Sandeep C

[diego_charles]

Hi @sandeepc 

Thanks for letting me know.

Feel free to create another post here in the community and reference this one, whenever your new board revision is ready.

All the best, 

Diego

[johannzimmerman]

Many, many thanks Diego,
the “fsl_romapi” works fine now.

I'm not sure if I should put it in here but the
"\flexspi\nor\polling_transfer" example works the other way around:
In the debug environment of IAR the example crashes.
After cold start everything works fine. So debugging impossible...

WBR

Johann

[diego_charles]

Hi @johannzimmerman 

Thanks for letting me know, I am glad to know that the demo is now working for you. SDK team is now aware, and a fix will be done in the future, I still do not have information of when will this be done. 

Regarding the \flexspi\nor\polling_transfer demo issue you are seeing, let me thank you  for the proactivity reporting issue, we will need to see if we can reproduce this issue as well. But could you create another post for that? Me or another colleague could help on that.

Thank you

Diego

[sandeepc]

It works only in debug mode that to when we use link application to ram.

We are trying to call ROM APIs to erase/write to same flash memory from which code is executing.
In this scenario, are we supposed to call ROM APIs only from RAM, or can it be called from main application running from flash (QSPI)?
If ROM APIs can be called from flash, can you please provide a example?

@diego_charles 

[diego_charles]

Hi @sandeepc 

Regarding my first response, where I said that the demo works when linked to RAM, this was  a quick workarroud to test the  APIs, while I was checking internally the issue. Thanks for checking out. SDK 2.15.1 and SDK 2.15.0 flash configuration, from below  produce issues when the ROM API tries to access to flash memory. 

#define FLASH_DUMMY_CYCLES 0x08
#define FLASH_DUMMY_VALUE  0x03

My previous comment provides a solution to let the demo to work linked to flash. 

#define FLASH_DUMMY_CYCLES 0x06
#define FLASH_DUMMY_VALUE  0x00

Therefore, if you update the demo according to it, you should be able to execute from flash and use the ROM API to erase and write the memory.  So, with this update we demonstrate that  ROM APIs can be called from flash execution.  

Let me know if you need any more help.

Diego