I would recommend checking the Look up table (LUT) for your new memory. Since I do not know if the bigger size flash uses, for example, the same R/W OP codes.
Then, check the linker and the MPU settings. Adapt the linker to fit your new flash and make sure that the MPU initialization covers the flash region. This step may depend on your application and may or not have impact, but is good to consider this. Try running simplest demo available, for example, the led_blinky.
It sounds that you are trying to boot and execute from this memory, let now otherwise. We have the MCUXpresso Secure Provisioning Tool, with this tool you could generate and write a bootable image. As another suggestion : build a led blinky sample image , provided by the tool, and check results.
The tool does not consider flash size, but you can customize flash settings. The advantage of this is that you can skip first recommendation of checking the LUT, since the tool generates and writes a "generic" flash configuration, including the LUT.
That is all I can think for now, if there is another detail to consider, about your new flash, let me know.
I hope this could help you.
Diego
Thank you for your patience.
According to my understanding:
The 0xE000ED08 is the VTOR register on the M7 CPU. This is normally used on SDK examples.
According to the ARM Cortex M7 documentation the register at 0xE000ED88 ( Coprocessor Access Control Register) belongs to the FPU. Below an example. However, I do not why your application uses this register.
The 0xE000ED08 is used accross SDK examples, so I think this address is ok.
You let me know that you had failures when running the Led_blinky demo. But what are your modifications to run this demo? Did you used the MCUXpresso Secure Provisioning Tool to generate and load a bootable image or did you modified the XIP folder in your project?
Thank you very much for your patience. Please let me know if you find anything else in the meantime.
Diego
.png){kind=link}
.png){kind=link}