Hi there,
I'm using a MX RT1064 EVK board. Are there any examples on how to use the internal Flash of the RT1064 as non-volatile memory that can be written to/read from at runtime?
I know for example that for the KW41Z there are NVM drivers provided in the SDK.
Thank you for your help.
Hi Victor:
You said:
One important thing that I forgot to mention in that post is that you cannot write/erase/read the internal memory while making XiP from that memory as well. You will need to execute your application from a different memory i.e. the internal RAM memory or the external flash memory.
I am making Xip mode and execute the code from internel flash directly. There is some memory space left and I need some user data save. Can I use the space left save my data?
You said that you cannot write/erase/read the internal memory while making Xip. Is all the code cannot be executed in the internal flash or only the code that reads and writes the flash cannot be executed in the flash?
Hi Mingzhe,
Regarding your questions please see my comments below.
Can I use the space left save my data?
Yes, you can do this.
Is all the code cannot be executed in the internal flash or only the code that reads and writes the flash cannot be executed in the flash?
Only the code that reads, writes or erases the flash.
Please refer to the following community document to see how to make this work.
https://community.nxp.com/docs/DOC-347195
If you have further questions please create a new community thread.
Regards,
Victor
Hello all,
Please refer to the following community document, here you will find a detailed explanation of all the modifications that you need to make to one of the SDKs examples to use the on-chip flash as NVM.
https://community.nxp.com/docs/DOC-347195
Have a great day,
Victor
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct"button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hello all,
I'm currently checking this internally, I will provide an update as soon as possible. Thanks for your patience and understanding.
Best Regards,
Victor
I also have this question. I have an RT1064 with XIP enabled(?), executing off internal 4MB flash (WINBOND W25Q32JV). I'm trying to use the last sectors for non-vol data storage. I've got some rookie questions.
So from reading above I understand I have to
1.)disable XIP
2.)reconfigure flexspi2 to read/write to flash sector?
3.) Reconfigures flexspi2 back to the way it was?
I XIP enabled by default? Would disabling XIP consist of setting XIP_EXTERNAL_FLASH to 0?
With XIP disabled the 'entirety' of the executable code is moved to RAM for execution, right? (This is our text section correct?)
If this is true, then assuming XIP is off and no other external memory, flexspi2 configuration and reconfiguration within main() becomes unnecessary (Get rid of steps 2 and 3, or replace with one configuration call).
Thus all I need to do is disable XiP, and then the program will automatically relocate to RAM? Or are further specifications needed?
Ideally my code resides in flash, and when the device is powered the code is moved over to ram for execution freeing up flexspi2 for memory write operations.
Any insight on how to accomplish this would be greatly appreciated!
Thank you both for your replies.
I also tried now to use the external QSPI Flash on MX RT1064 EVK board.
I followed the example of the flash_component_nor project from the SDK. However, I observed some strange behaviour when integrating it into my project.
Generally the access to external QSPI Flash works well. But I encountered strange behaviour when deleting some unused code from my project. In the below snippets the function controll_task is unused and does not appear in the resulting .axf file.
When using the project with snippet 1, everything works fine. The sha256sum of the resulting .axf file is equal to hash_1.
/* Snippet 1 */
#define USE_CONTROL_TASK (0)
static void controll_task(void *pvParameters)
{
#if USE_CONTROL_TASK == 1
some_functions();
more_functions();
#else
vTaskSuspend(NULL);
#endif /* USE_CONTROL_TASK == 1 */
}
When commenting out the two functions inside the preprocessor #if (snippet 2) everything works fine too. Also the sha256sum of the resulting .axf file is equal to hash_2 = hash_1
/* Snippet 2 */
#define USE_CONTROL_TASK (0)
static void controll_task(void *pvParameters)
{
#if USE_CONTROL_TASK == 1
//some_functions();
//more_functions();
#else
vTaskSuspend(NULL);
#endif /* USE_CONTROL_TASK == 1 */
}
However, when deleting the internal functions (snippet 3) there arises a hardfault when executing (more on that below). The sha256sum of the resulting .axf file equals hash_3 which is different from hash_1/2.
1) So. first question: how can the resulting .axf files be different when changing code that should be transparent to the compiler/linker?
/* Snippet 3 */
#define USE_CONTROL_TASK (0)
static void controll_task(void *pvParameters)
{
#if USE_CONTROL_TASK == 1
#else
vTaskSuspend(NULL);
#endif /* USE_CONTROL_TASK == 1 */
}
Coming now the hardfault: As in the flash_component_nor demo project I configure the clocks for the SPI as follows:
/* Configure Clock for FlexSPI */
const clock_usb_pll_config_t g_ccmConfigUsbPll = {.loopDivider = 0U};
CLOCK_InitUsb1Pll(&g_ccmConfigUsbPll);
CLOCK_InitUsb1Pfd(kCLOCK_Pfd0, 24); /* Set PLL3 PFD0 clock 360MHZ. */
CLOCK_SetMux(kCLOCK_FlexspiMux, 0x3); /* Choose PLL3 PFD0 clock as flexspi source clock. */
CLOCK_SetDiv(kCLOCK_FlexspiDiv, 2); /* flexspi clock 120M. */
But when executing CLOCK_InitUsb1Pdf(...) function the hardfault is caused by the last assignment in the this code:
void CLOCK_InitUsb1Pfd(clock_pfd_t pfd, uint8_t pfdFrac)
{
uint32_t pfdIndex = (uint32_t)pfd;
uint32_t pfd480;
pfd480 = CCM_ANALOG->PFD_480 &
~(((uint32_t)((uint32_t)CCM_ANALOG_PFD_480_PFD0_CLKGATE_MASK | CCM_ANALOG_PFD_480_PFD0_FRAC_MASK)
<< (8UL * pfdIndex)));
/* Disable the clock output first. */
CCM_ANALOG->PFD_480 = pfd480 | ((uint32_t)CCM_ANALOG_PFD_480_PFD0_CLKGATE_MASK << (8UL * pfdIndex));
/* Set the new value and enable output. */
/* Hardfault originates here */
CCM_ANALOG->PFD_480 = pfd480 | (CCM_ANALOG_PFD_480_PFD0_FRAC(pfdFrac) << (8UL * pfdIndex));
}
The debugger reported an error reading from inaccessible memory region:
And the corresponding fault view:
After this fault, the MX RT1064 is no longer acessible to flash new firmware and one has to change to "Serial Download" boot option. The corresponding flashing error is:
MCUXpresso IDE RedlinkMulti Driver v11.1 (Feb 24 2020 13:57:55 - crt_emu_cm_redlink build 11)
Found chip XML file in /home/pascal/workspace/evkmimxrt1064_i2c_sensor_read/Debug/MIMXRT1064xxxxA.xml
Reconnected to existing LinkServer process.
============= SCRIPT: RT1064_connect.scp =============
RT1064 Connect Script
DpID = 0BD11477
APID = 0x04770041
Error: No Halt Confirmation
Disabling MPU
Configure FlexRAM for 768KB OC RAM, 128KB I-TCM, 128KB D-TCM
Finished
============= END SCRIPT =============================
Probe Firmware: DAPLink CMSIS-DAP (ARM)
Serial Number: 02320000151211d400000000000000000000000097969905
VID:PID: 0D28:0204
USB Path: /dev/hidraw0
Using memory from core 0 after searching for a good core
debug interface type = Cortex-M7 (DAP DP ID 0BD11477) over SWD TAP 0
processor type = Cortex-M7 (CPU ID 00000C27) on DAP AP 0
number of h/w breakpoints = 8
number of flash patches = 0
number of h/w watchpoints = 4
Probe(0): Connected&Reset. DpID: 0BD11477. CpuID: 00000C27. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Content of CoreSight Debug ROM(s):
RBASE E00FD000: CID B105100D PID 000008E88C ROM (type 0x1)
ROM 1 E00FE000: CID B105100D PID 04000BB4C8 ROM (type 0x1)
ROM 2 E00FF000: CID B105100D PID 04000BB4C7 ROM (type 0x1)
ROM 3 E000E000: CID B105E00D PID 04000BB00C Gen SCS (type 0x0)
ROM 3 E0001000: CID B105E00D PID 04000BB002 Gen DWT (type 0x0)
ROM 3 E0002000: CID B105E00D PID 04000BB00E Gen (type 0x0)
ROM 3 E0000000: CID B105E00D PID 04000BB001 Gen ITM (type 0x0)
ROM 2 E0041000: CID B105900D PID 04001BB975 CSt ARM ETMv4.0 type 0x13 Trace Source - Core
ROM 2 E0042000: CID B105900D PID 04004BB906 CSt type 0x14 Debug Control - Trigger, e.g. ECT
ROM 1 E0040000: CID B105900D PID 04000BB9A9 CSt type 0x11 Trace Sink - TPIU
ROM 1 E0043000: CID B105F00D PID 04001BB101 Sys (type 0x0)
NXP: MIMXRT1064xxxxA
DAP stride is 1024 bytes (256 words)
Inspected v.2 External Flash Device on SPI using SFDP JEDEC ID MIMXRT1064.cfx
Image 'iMXRT1064_SFDP_QSPI Feb 17 2020 13:59:06'
Opening flash driver MIMXRT1064.cfx
Sending VECTRESET to run flash driver
state - running or following reset request - re-read of state failed - rc Nn(05). Wire ACK Wait in DAP access
state - running or following reset request - re-read of state failed - rc Nn(05). Wire ACK Wait in DAP access
AFTER driver startup timeout (302 5ms retries)
Driver Addresses
Start: 20000000
Entry: 2000009D
End: 2000075C
Stack: 20002760
Mailbox:2000A760
Driver Register State
R0: 402A4000
R1: FFFF8011
R2: F1AE8124
R3: 0F1A23A2
R4: 200004EC
R5: 402A4000
R6: 00000004
R7: 00000001
R8: 00000001
R9: 00000000
R10: 00000000
R11: 00000001
R12: 00000000
SP: 20002628
LR: 00211FBF
PC: 002140E2
xPSR: 81000000
MSP: 20002628
PSP: 20002760
CFBP: 00000001 (CONTROL=0x0, FAULTMASK=0x0, BASEPRI=0x0, PRIMASK=0x1)
Flash Driver V.2 startup failed - rc Ef(34): Timed-out initializing flash.
chip initialization failed - Ef(34): Timed-out initializing flash.
failed to initialize flash driver MIMXRT1064.cfx
Hence, the second question is:
2) Do you have any idea why the change above in snippet 3 causes the Init function of UsbPdf1 to access inaccessible memory region?
Thanks for your support.
Hi Pascal,
I also had same problem while porting flash_component_nor to original code.
CLOCK_InitUsb1Pll(&g_ccmConfigUsbPll);
CLOCK_InitUsb1Pfd(kCLOCK_Pfd0, 24); /* Set PLL3 PFD0 clock 360MHZ. */
CLOCK_SetMux(kCLOCK_FlexspiMux, 0x3); /* Choose PLL3 PFD0 clock as flexspi source clock. */
CLOCK_SetDiv(kCLOCK_FlexspiDiv, 2); /* flexspi clock 120M. */
Instant of above clock source use :
CLOCK_SetMux(kCLOCK_FlexspiMux, 0x2); /* Choose PLL2 PFD2 clock as flexspi source clock. 396M */
CLOCK_SetDiv(kCLOCK_FlexspiDiv, 2); /* flexspi clock 133M. */
This is work for me.
Regards,
Vasu
Unfortunately this did not help in my case. The error is caused by the line
CLOCK_InitUsb1Pfd(kCLOCK_Pfd0, 24); /* Set PLL3 PFD0 clock 360MHZ. */
which is one line before your suggested changes.
Hi Pascal,
flash_component_nor original code working fine if we integrate our main project not working writing and reading data is not proper.
Still i have same issue not solved.
This is my new thread - How to set flexspi1 clock source.
Modify flash_component_nor code :
int main(void)
{
status_t status;
BOARD_ConfigMPU();
BOARD_InitPins();
BOARD_BootClockRUN();
BOARD_InitDebugConsole();
//const clock_usb_pll_config_t g_ccmConfigUsbPll = {.loopDivider = 0U};
//CLOCK_InitUsb1Pll(&g_ccmConfigUsbPll);
//CLOCK_InitUsb1Pfd(kCLOCK_Pfd0, 24); /* Set PLL3 PFD0 clock 360MHZ. */
//CLOCK_SetMux(kCLOCK_FlexspiMux, 0x3); /* Choose PLL3 PFD0 clock as flexspi source clock. */
//CLOCK_SetDiv(kCLOCK_FlexspiDiv, 2); /* flexspi clock 120M. */
//CLOCK_InitSysPfd(kCLOCK_Pfd2, 29); /* Set PLL2 PFD2 clock 328MHZ. */
//CLOCK_SetMux(kCLOCK_FlexspiMux, 0x2); /* Choose PLL2 PFD2 clock as flexspi source clock.*/
//CLOCK_SetDiv(kCLOCK_FlexspiDiv, 3); /* flexspi clock 82M. */
CLOCK_SetMux(kCLOCK_FlexspiMux, 0x2); /* Choose PLL2 PFD2 clock as flexspi source clock. 396M */
CLOCK_SetDiv(kCLOCK_FlexspiDiv, 2); /* flexspi clock 133M. */
/* Initialize FLEXSPI */
flexspi_config_t config;
/* Get FLEXSPI default settings and configure the flexspi. */
FLEXSPI_GetDefaultConfig(&config);
/*Set AHB buffer size for reading data through AHB bus. */
config.ahbConfig.enableAHBPrefetch = true;
config.ahbConfig.enableAHBBufferable = true;
config.ahbConfig.enableReadAddressOpt = true;
config.ahbConfig.enableAHBCachable = true;
config.rxSampleClock = kFLEXSPI_ReadSampleClkLoopbackFromDqsPad;
FLEXSPI_Init(EXAMPLE_FLEXSPI, &config);
PRINTF("\r\n***NOR Flash Component Demo Start!***\r\n");
PRINTF("\r\n***NOR Flash Initialization Start!***\r\n");
status = Nor_Flash_Init(&norConfig, &norHandle);
if (status != kStatus_Success)
{
PRINTF("\r\n***NOR Flash Initialization Failed!***\r\n");
ErrorTrap();
}
PRINTF("\r\n***NOR Flash Initialization Success!***\r\n");
PRINTF("\r\n***NOR Flash Erase Chip Start!***\r\n");
status = Nor_Flash_Erase_Chip(&norHandle);
if (status != kStatus_Success)
{
PRINTF("\r\n***NOR Flash Erase Chip Failed!***\r\n");
}
}
Regards,
Vasu
Thank you very much for the hint. I will try this the next time I encounter the hardfault with the USB1 clock. At the moment I made some changes in other parts of the code and the hardfault did not appear.
Regards,
Pascal
Hi Pascal,
Regarding your questions please see my comments below.
1) So. first question: how can the resulting .axf files be different when changing code that should be transparent to the compiler/linker?
Did you verify that the compiler is not optimizing this function? Based on the information that you provided it seems to me that the compiler might be optimizing this function.
2) Do you have any idea why the change above in snippet 3 causes the Init function of UsbPdf1 to access inaccessible memory region?
At this point, it's difficult for me to determine what might be the root cause of this behavior. Could you please provide a guide on how can I reproduce this behavior on my side? This way I can make some tests to try to find what might be causing this.
Regards,
Victor
Hi victorjimenez,
Sorry for the late response.
1) The compiler optimization is turned off ( compile flag -O0). I also verified the function "controll_task" is not contained in the binary file, since it is not used. The problem is, the 3 snippets above (should) look exactly the same for the compiler. Only the preprocessor sees a difference in the 3 snippets but this should not have any effect on the compilation result, should it?
Therefor, I was suspicious why the hash value of the 3 snippets changed, when making changes that are completely invisible to the compiler. Do you have any ideas?
2) Yes I see the difficulty in this task. Unfortunately I cannot provide you any guide on how to reconstruct this behavior. A strange this that I observed: I went on coding in a completely other part of the code and tried again and then there was no hardfault while initializing the QSPI clock. But I also encountered the same issue again when making further changes to other parts of the code. For me there is no rational behind it when the hardfault appears and when not.
Regards,
Pascal
Hi Pascal,
Please refer to the following community thread: Internal Flash of IMXRT1064. One important thing that I forgot to mention in that post is that you cannot write/erase/read the internal memory while making XiP from that memory as well. You will need to execute your application from a different memory i.e. the internal RAM memory or the external flash memory.
Have a great day,
Victor
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct"button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi
There are two internal storage types:
- OTP (eFUSEs) - OCOTP - there are a number of general purpose storage locations if 'real' OTP is required
- Internal W25Q32JV - can be used for file system, data logging and parameter storage but is not real 'OTP' but modifiable.
For W25Q32JV modifications the BOOT ROM of the i.MX RT 1064 contains ROM API that allows these to be performed without needing user code. I haven't used this because the uTasker project contains a generic solution for all chips and internal/external QSPI programming and performs the operations from RAM but I expect that these APIs can be used without needing to relocate to RAM since it is the BOOT ROM doing the actual work.
Regards
Mark
[uTasker project developer for Kinetis and i.MX RT]