flash init issues

[jakobczyk_woj]

I'm working with a custom board based on imx RT1062 and W25Q16 nor flash connected through SPI.

In MCU Expresso I'm testing the flexspi_nor_polling_transfer example, linked to RAM.

It is working fine, but only when I first run the GUI flash tool and do an operation (e.g. erase) there.

When I don't do it after power up, the call to flexspi_nor_get_vendor_id in my code returns vendor id 0xff and the next transaction hangs in FLEXSPI_GetBusIdleStatus (called from FLEXSPI_TransferBlocking).

I have to do this "fixup" with the flash tool every time I power up the board, otherwise the flash does not work.

What could be causing this issue? What is the driver in the flash tool doing with the flash (or flexspi peripheral) that sets it up correctly?

[Sabina_Bruce]

Hello ,

Hope you are doing well.

Could you please clarify if when you have to do the fixup is it in a debug session or is this when you flash your program but not debug it?

Also did you modify the configurations for your custom flash or are you using  the same from the example?

Best Regards,

Sabina

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

----------------------------------------------------------------------------------------------------------------------- 

[jakobczyk_woj]

It's just flashing that fixes the issue.

In regard to modifications, I needed one modification LUT - replace sector erase command 0xD7 with 0x20.

Some more observations... 

RT1062 in my setup is configured to boot from this flash. It seems the issue is caused by invalid data in the configuration block at 0x400. Apparently bootloader in ROM is ignoring lack of proper tag in the first word there.

And still the question is what the driver used by the GUI tool is doing to reset and "fix" flash access.

[Sabina_Bruce]

Hope you are well. I dont properly understand what you mean by "fix" flash access. Please describe the steps in how you do it in order to get this behavior.

From your description I understand that you do a mass erase or program using the flash gui tool. If its the first time you have connected the board then it is working ok. 

However if you press reset then it is not working any more is this correct? So you have to reflash it?

Or do you mean that if you press mass erase /program with the flash gui tool consecutively then it does not work?

Please confirm.

[jakobczyk_woj]

Let me describe the problem once again, now from a perspective of some new observations.

My MCU is configured (with fuses) to boot from SNOR flash.

From MCU Express I'm running an application based on flexspi_nor_polling_transfer example.

When I power on the MCU with flash empty (after chip erase) the application can't access flash, vendor id is 0xff and it hangs (as described in my initial post). The same happens when I power on with some random data written to flash.

As I understand, this is because the boot ROM is trying to boot from flash and it initializes flash/flexspi with configuration block in flash - which is not valid. This puts flash/flexspi in a sort of invalid state, causing issues when I run my application.

I found I can "fix" it by performing any flash operation from the GUITool - apparently it somehow resets/reconfigures the system so that my application can work with the flash correctly. Until next power cycle.

The issue does not happen when I write to flash a valid binary with a valid configuration block at 0x400.

My question now is what does the driver used by the GUITool do so that flash/flexspi is ok after its use? I would like to do the same from my application so that it can reliably access flash in all circumstances.

I hope this is clear now. :smileyhappy:
Thanks.

[Sabina_Bruce]

Thank you for clarifying. I believe I now understand what is going on. Based on your description, I tested on our evaluation board the "linked to RAM" option with it and without. If you have this option enabled, MCUXpresso IDE tells the managed linker script mechanism to simply ignore any flash regions listed in the project’s memory configuration. So you are not using the flash region, and when you power on the MCU again later on the application will be erased. In order to make sure that you are correctly writing to flash, you must disabled this option.

Flash your application again then restart it and it should be working correctly if everything was initialized properly. 

Could you please disable the "link to RAM" option and try again?

Let me know your results.

Best Regards,

Sabina

[jakobczyk_woj]

Hi Sabrina,

Thanks for the analysis. I'm afraid I need the "link to RAM" option enabled, because my application will not be run from flash. It is a bootloader kind of application that is injected into RAM by another MCU, via SWD connection. The application main functionality is to write actual firmware into flash.

My problem is in access to flash within the application, not the application flashing/execution itself.
I don't understand how linking to RAM can affect that.

[Sabina_Bruce]

Hope you are well. Yes, this is what I mean. For example the flexspi_nor example without any modifications and without the option "link to ram" is partitioned in the following way.

When you run the example this is running from flash, as you may see the address is at 0x60000000.

If I remove the debugger and power up the board again I will get the same results in tera term, because the application is in flash.

On the other hand if I select "link to RAM", then this means that I will be using the internal ram to run my application. Here is the memory partitioned:

The example will run without a problem, from this area which address is 0x20000000 and I can still access the flash operations as normal.

When I remove the debugger and power up the application is lost and will not run. 

Please take a screenshot of the GUI configuration tool, so I can see what you are doing to get it working. If you can take screenshot of the process you take, I'd appreciate it. 

Best Regards,

Sabina

[jakobczyk_woj]

I'm sorry but this is a wrong lead, let's not waste time on it :smileyhappy:. My issue has nothing to do with linking to RAM. Let me reconfirm - I want this application to be run from RAM and I know what it means. The application starts fine (from RAM, yes) both when I start it from the debugger and when it starts after being injected and executed by another MCU connected via SWD. This is all fine.

The problem is after application successfully starts, in the specific circumstances (that I described) it fails when trying to program flash, using functions taken from the flexspi flash example, such as flexspi_nor_get_vendor_id() - as I described earlier. Some hard reset/reinitialization is missing in the example code, that will bring back flash or flexspi peripheral after failed init by the ROM.

Can you consult it with someone specialized in flexspi peripheral?

[jakobczyk_woj]

In the meantime I found that this is caused by the chip erase operation (command 0xC7). When I execute it, after next powercycle of the board, flash does not respond. Until I do the "fixup" as described.

[Sabina_Bruce]

Hope you are well. I have discussed this with our team. Here are some follow up questions necessary to find the root cause:

1. How are you initializing the flexspi_nor_flash_init?

2. Is the LUT updated successfully and able to do a software reset after this?

[bp1979]

@jakobczyk_woj 

did you manage to fix this in the end? I have exactly the same problem on a 1021 evk board.

[jakobczyk_woj]

AFAIR the issue was caused by flash erase wiping out the FCB (FlexSPI Configuration Block), that then on reboot contained invalid data causing faulty initialization of the flash. Afterwards flash was permanently broken, until next run of the "fixup" procedure I described.

[bp1979]

Aha, alright. Thx for commenting. Will try your containment this evening. Bit concerning issue. 

Did you ever notice that if you pause the debugger, it is stuck in the function you mention ed, and when you then resume the app, it magically continues? 

Could be that it is not the same problem, but sure sounds rather similar.