I'm using a custom board designed after the NXP 1170EVK board, the main differences are we removed unused peripherals (ethernet, camera, etc...), it doesn't have the M4 core, and it only has 1 external SDRAM chip instead of 2 (same chip is used though Winbond W9825G6KH-5I). The board works great when only using the QSPI Flash and the internal memory. I've been able to get several examples from the SDK to work with the board with little to no modification. What I haven't been able to do is get any of the demos that use the SDRAM as the primary RAM, I'm unsure what configuration (if any) so that the board knows there's only 1 SDRAM chip instead of 2. I've taken screenshots to show some of my successes and issues below.
Successfully executing the usb_msd_fatfs_freertos_cm7 demo, our main program will be running FreeRTOS and be using the USB to save log files:
SDRAM is circled in red to show that it successfully runs because nothing is put into it.
The semc_cm7 demo also surprisingly runs when modifying one line of code:
Once again, circled in red you can see the one line that needed to be edited to read and write to the SDRAM, but also circled in red no program data is in SDRAM, all internal.
Finally I try to get the lvgl_guider_cm7 demo to work, it requires having an external RAM as primary due to the size of the library and the screen buffers, it cannot fit internally.
Now that SDRAM is set as the primary RAM, the debugger gets a hard fault before reaching main(), I'm unsure of where to go, I've scoured forums looking for answers but haven't found anything fruitful. I'm curious if anyone know what configurations need to be set, either in the code or in the MCU settings for this lvgl demo to work with my setup.
Hi @CMoran ,
I want to follow up to see if you were ever able to find a solution to this? I seem to be having the exact same problem that started from MIPI examples.
Thanks!
No we never found a solution to this issue. We ended up pivoting our project to use the Embedded Artists iMX RT1176 uCOM SoM and swapping our custom board to just be a carrier board instead.
I see. Do you have any ideas as to what may have been the root cause? Or even what the problem may have been? I am just apprehensive about getting a new board and having this happen again.
Thanks for your help!
Do you have the same size sdram of the original project ??. Or is ti smaller ?. Because if it's half the definition must changed not only in the memory map ( no problem when you compile in case the project it's not so big ) but also in the BOARD_ConfigMPU.
If you have half of the ram you cannot set the Ncache at that address..
regards.
The SDRAM chip itself is of the same size, 4M x 4 banks x 16-bit = 256Mb. The evk has 2 of these so it would have 512Mb SDRAM, so yes our custom board does have less SDRAM total, but the chips are the exact same. The thing is though is the memory map (default to the SDK example) only uses 64Mb of SDRAM. You can see here:
The SDRAM is defined to be 48Mb from 0x80000000 - 0x82ffffff and the non-cache region is the remaining 16Mb of the 64Mb total from 0x83000000 - 0x84000000.
Inside BOARD_ConfigMPU it setups up the SDRAM and non-cache to be of size 64Mb:
And the non-cache region is calculated off of the base and top of the region set in the memory map (I believe):
The sizes shouldn't be the issue if only 64Mb is ever assigned in the memory maps. Besides that my code hard faults before even making it to the main() to even be able to run BOARD_ConfigMPU(). The only difference I can think of is that since the EVK has 2 SDRAM chips that take 16-bit input (for 32-bit total). Then on the EVK say the upper 16-bits of a DWORD would into one SDRAM chip and the lower 16-bits would go into the other SDRAM chip. Since our custom board only has 1 SDRAM chip all 32-bits would need to go into 1 chip, which is where the port size change comes in. I'm just unsure if there are other configs needed to make the single chip behave. In the meantime I'll look into changing the sizes of usable memory to see if anything works.
Hi @CMoran ,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
I think I need more information prior to sharing some advice.
Firstly, I hope you can upload the schematic of the custom board, next, I'd like to confirm with you whether you hadn't modified any codes in the semc demo except the below line.
Have a great day,
TIC
-------------------------------------------------------------------------------
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 @jeremyzhou ,
Thank you for the reply, I've got the information you've requested. I just double checked and yes the evkmimxrt1170_semc_cm7 demo will run (and get succeed messages) after only changing the sdramconfig.portSize to 16-bit instead of the default 32-bit, no other changes were made. If it matters this SDK demo came from the SDK_2.x_MIMXRT1172xxxxx SDK version 2.12.1. Secondly I've taken some screenshots of the schematics involving the SEMC unit (including our NAND flash).
Here's the SDRAM:
The NAND:
MCU 1:
MCU 2:
For reference here are links to the datasheets of the SDRAM and the NAND:
SDRAM
https://www.mouser.ca/datasheet/2/949/w9825g6kh_a04-1489735.pdf
NAND
https://www.macronix.com/Lists/Datasheet/Attachments/8863/MX30LF2G28AD,%203V,%202Gb,%20v1.3.pdf
Hi @CMoran ,
Thanks for your reply.
If you only use a single W9825G6KH-5I, it means the size is 32 MB, so the memory assignment should be adjusted, and the MPU configuration should change too.
In addition, the DCD also needs to be modified to conform to your hardware design.
Have a great day,
TIC
-------------------------------------------------------------------------------
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 @jeremyzhou ,
I've just what you've suggested and I still get a hard fault below I'll outline exactly the changes I made to the SDK example, these will be the only modifications I have made, perhaps I'm missing something?
Step 1: Load fresh lvgl_guider_cm7 SDK demo.
Step 2: Change the memory map so that SDRAM + Non-cache Region = 32Mb.
The above figure shows an SDRAM of size 0x1800000 (24Mb) and a Non-cache Region of size 0x800000 (8Mb).
Step 3: Adjust the memory size of SDRAM in the BOARD_ConfigMPU (I still think that the Non-cache is calculated using the code below the SDRAM part).
Step 4: Make changes to the DCD to reflect 16-bit port size and 32Mb memory size for SDRAM.
These are the only changes made from the SDK example.
Step 5: Compile and Debug.
Compilation works perfectly fine, but I get this hard fault before reaching main().
The hard fault occurs in this function. Also all the Registers being 0x00000000 seems off.
We can see that it is clearing memory for lvgl and calls on lvgl's custom memset function (posted below).
Now this function says it's optimized for 4 byte operation, maybe that has something to do with it? Since our SDRAM is only 2 bytes wide for it's data. I'll look into this and report back if I can get anything to work, otherwise I'll await your reply.
To quickly rule out the LVGL function potentially causing an issue I loaded up the mipi_compliant_test_cm7 demo, which also uses SDRAM and Non-cache Region for it's program data but doesn't have LVGL or it's libraries. I made the exact DCD, memory map, and BOARD_ConfigMPU changes and still got a hard fault, this time from Undefined Instruction instead of Invalid State. I removed the VGLite component (from the lvgl_guider_cm7 demo I previously modified) by changing the define LV_USE_GPU_NXP_VG_LITE to 0, recompiled, starting debugging and got a slightly different hard fault than before.
This time there's actually information in the registers.
Hi @CMoran ,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
I think I need more information prior to sharing some advice.
Firstly, I hope you can upload the schematic of the custom board, next, I'd like to confirm with you whether you hadn't modified any codes in the semc demo except the below line.
Have a great day,
TIC
-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------
I've made some progress on getting it to work, but ran into more errors/faults. After a bunch more research I looked into modifying the DCD file using the DCD configuration tool (never done this before), I was able to find the register that has SDRAM setup as a 32-bit port, and changed it to 16-bit (like in the SEMC demo). This allowed me to get passed the first hard fault. Now what happens is sometimes it hard faults from either invalid state, bus fault error, usage error. On the other hand, sometimes it makes it to the main(), when it makes it to main it crashes in the BOARD_ConfigMPU() in the part where it tries to setup the non-cacheable region. I'm unsure if there are more changes required for this demo to execute properly on my board.
Hi @CMoran ,
Thanks for your reply.
Whether you can replicate the issue while debugging other demos that use the SDRAM as the primary RAM.
BR,
Jeremy
Have a great day,
TIC
-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------
Yes, I have tried to run the mipi_compliant_test_cm7 (mainly because I'm trying to get a TFT panel to work with my custom board). It also has SDRAM as primary RAM and it also hard faults. To triple confirm I also loaded up the fmstr_example_can_cm7 demo (first one I clicked on with SDRAM as primary RAM) and it also exhibits the same behaviour.
Hi @CMoran ,
Today, I did the same testing as you show on the MIMXRT1170 EVK board, following the above modifications, the lvgl_guider_cm7 and mipi_dsi_compliant_test_cm7 both can work well.
I attached the modified lvgl_guider_cm7 demo, you can check it.
Have a great day,
TIC
-------------------------------------------------------------------------------
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 @jeremyzhou ,
I just tested the demo you attached and unfortunately I'm still receiving hard faults. Sometimes it reaches main() and will get a usage fault in the BOARD_ConfigMPU() at this particular line:
/* The MPU region size should be 2^N, 5<=N<=32, region base should be multiples of size. */
assert(!(nonCacheStart % size));
Sometimes it won't make it to the main() and hard fault in the SystemInitHook(), either return invalid state or undefined instruction. Other times it hard faults and can't trace back to what triggered it and returns Bus Fault Address Register (BFAR) along with IMPRECISERR and PRECISERR at the same time.
If all that should be needed to be changed for a different external memory configuration to work with the RT1176 is the DCD, the MPU, and the memory map, then perhaps the error doesn't reside in the configuration.
Hi @CMoran ,
Thanks for your reply.
Sorry to hear the issue still exist, I'd like to suggest you to do the same testing on the MIMXRT1170 EVK, it can help you to figure out whether the issue is related to the hardware.
Have a great day,
TIC
-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------