Can not run normally on MIMXRT1061CVL5A SOC

[beiszhihao]

Describe the bug
I tried to run Zephyr on MIMXRT1061_EVK, but unfortunately there was a problem.
I used Jlink-SWD to debug and found that Zephyr had an error while initializing the BSS segment.
I checked the value of the cpu register before debugging, the PC register points to the NOR_FLASH address, 0x60000000 so it is correct

(gdb) info registers
r0             0x600033f9          1610626041
r1             0x0                 0
r2             0x3e75d             255837
r3             0x90f0              37104
r4             0x600033f9          1610626041
r5             0x20203a70          538983024
r6             0xc6f1bf4b          3337731915
r7             0xf0                240
r8             0x200300            2097920
r9             0x0                 0
r10            0x0                 0
r11            0x400f8000          1074757632
r12            0x1fe               510
sp             0x20200f70          0x20200f70
lr             0x215329            2183977
pc             0x600033fa          0x600033fa <z_arm_reset+2>
xpsr           0x41000000          1090519040
msp            0x20200f70          538972016
psp            0x0                 0
primask        0x0                 0
basepri        0x0                 0
faultmask      0x0                 0
control        0x0                 0
fpscr          0x0                 0

I started to continue debugging
Zephyr crashed when the execution reached the z_bss_zero(); function

z_arm_prep_c () at C:/Users/zhihao3x/work/zephyrproject/zephyr/arch/arm/core/aarch32/prep_c.c:183
183             z_bss_zero();

I tried to enter the z_bss_zero function for debugging, I found that it first executed the memset function to clear the bss base address
the base address starts at 0x80000000

memset (buf=0x80000030 <z_idle_threads>, c=c@entry=0, n=428) at C:/Users/zhihao3x/work/zephyrproject/zephyr/lib/libc/minimal/source/string/string.c:357
357             unsigned char c_byte = (unsigned char)c;

I think there is a problem here, I started to check my chip manual
I carefully observed my chip manual, and I found that the SOC used by my MCU is RT1061 CVL5A. As far as I know, there are two versions of MIMXRT1060. These two versions use different SOCs. One version uses RT1061 CVL5A and the other one. The RT1062 DVL6A is used, and Zephyr can run normally on the RT1062 DVL6A version.
So I continued to debug and troubleshoot. I found through the documentation that RT1061_ inherits the characteristics of RT1050. There is no RAM inside and no SDRAM is divided.

Memory division purpose:

ITCM: Store the function code that needs to run in RAM
DTCM: It is used to store variable data read and written by the kernel, such as stack, and the frequency is consistent with the dominant frequency
OCRAM: It is used for general variables, peripheral read-write cache, and the frequency is 1 / 4 of the dominant frequency

At the same time, I found that my SDRAM (0x80000000) is divided in the SEMC off-chip controller. If you want to access it, you must access it through SEMC. Zephyr cannot directly access this memory.

According to the RAM memory division in my manual, I changed the SDRAM in the Zephyr DTS file to the DTCM address

sdram0: memory@0x20000000 {
		/* Micron MT48LC16M16A2B4-6AIT:G */
		device_type = "memory";
		reg = <0x20000000 DT_SIZE_KB(128)>;
	};

Then I was surprised to find that Zephyr was running normally and the LED was blinking as I wanted
But there is a problem with this, that is, the data segment is too small, only 128K, if I want to use more memory space, I need to use SEMC, which is a bit inconvenient
In addition, there is another problem, which is the problem of XIP mode. The rt1061 uses NOR FLASH, which runs directly in FLASH, but it does not work if I burn the elf file into it, but I burn the bin file. Yes, I use the burning tool: NXP-MCUBootUtility

[dleach02]

@beiszhihao, is this a custom board?

I carefully observed my chip manual, and I found that the SOC used by my MCU is RT1061 CVL5A. As far as I know, there are two versions of MIMXRT1060. These two versions use different SOCs. One version uses RT1061 CVL5A and the other one. The RT1062 DVL6A is used, and Zephyr can run normally on the RT1062 DVL6A version.

The CV part designation is for the industrial versions and the DV are for the consumer versions of the RT106x parts. From the data sheets it looks like the difference between industrial and consumer is operating temperature ranges.

The primary difference between RT1061 & RT1062 is that the RT1061 does not have LCD/CSI/PXP IP blocks while the RT1062 does have this.

On the board you are having a trouble with, when doing a 'west debug' try issuing a 'monitor reset' from the debugger to see if it changes your observed results. Or 'west debug --reset-after-load'.

[beiszhihao]

The CV part designation is for the industrial versions and the DV are for the consumer versions of the RT106x parts. From the data sheets it looks like the difference between industrial and consumer is operating temperature ranges.

The primary difference between RT1061 & RT1062 is that the RT1061 does not have LCD/CSI/PXP IP blocks while the RT1062 does have this.

On the board you are having a trouble with, when doing a 'west debug' try issuing a 'monitor reset' from the debugger to see if it changes your observed results. Or 'west debug --reset-after-load'.

I tried, but it didn't work. It's still a problem with SDRAM, so is this a bug? At present, zephyr does not work on the CV version

[dleach02]

@beiszhihao, the board you have with the RT1061CVL5A part a custom designed board?

[manupalu]

Hi @beiszhihao ,

Are you using a custom board with the RT1061CVL5A SOC? It seems that our EVKs all have the RT1062DVL6A on it, so are you comparing our EVK (with a RT1062DVL6A) to your custom board?

Regarding the SDRAM and the SEMC controller, did you include an SDRAM chip on your custom board? If so, is it the same SDRAM as on our EVK? (IS42S16160J-6BLI)

I believe the SDRAM is setup through the Device Configuration Data block (DCD) in the ROM, independent of the Zephyr app. If you are using a different SDRAM chip, you might have to modify the DCD in order to match the specifications of your own hardware, which I believe you could do through MCUXpresso Config tools and looking at the reference manual.

In addition to the wider temperature range as mentioned, the Industrial parts also run at a lower clock frequency of 528MHz as opposed to the commercial parts at 600MHz.

Could you help check what frequency your chip is running at? You might have to modify some of the clocks to lower this frequency, as overclocking it could lead to issues. Although we would expect it to run fine at room temperature.

I'm glad to hear that you got your application running after changing the sdram address to 0x2000_0000. If the data segment is too small for you, could you use the OCRAM/FlexRAM regions at 0x2020_0000 or 0x2028_0000? There should be more space available there as part of the FlexRAM region (1MB), unless you've allocated that region for something else.
The RT106x has 1MB of FlexRAM in addition to the 512KB of ITCM and 512KB of DTCM.

I hope this helps,
-Manuel

[beiszhihao]

@beiszhihao, the board you have with the RT1061CVL5A part a custom designed board?

yes，However, the customized board is only the backplane, and the MCU has not changed, but the MCU uses rt1061 SOC

[beiszhihao]

Hi @beiszhihao ,

Are you using a custom board with the RT1061CVL5A SOC? It seems that our EVKs all have the RT1062DVL6A on it, so are you comparing our EVK (with a RT1062DVL6A) to your custom board?

Regarding the SDRAM and the SEMC controller, did you include an SDRAM chip on your custom board? If so, is it the same SDRAM as on our EVK? (IS42S16160J-6BLI)

I believe the SDRAM is setup through the Device Configuration Data block (DCD) in the ROM, independent of the Zephyr app. If you are using a different SDRAM chip, you might have to modify the DCD in order to match the specifications of your own hardware, which I believe you could do through MCUXpresso Config tools and looking at the reference manual.

In addition to the wider temperature range as mentioned, the Industrial parts also run at a lower clock frequency of 528MHz as opposed to the commercial parts at 600MHz.

Could you help check what frequency your chip is running at? You might have to modify some of the clocks to lower this frequency, as overclocking it could lead to issues. Although we would expect it to run fine at room temperature.

I'm glad to hear that you got your application running after changing the sdram address to 0x2000_0000. If the data segment is too small for you, could you use the OCRAM/FlexRAM regions at 0x2020_0000 or 0x2028_0000? There should be more space available there as part of the FlexRAM region (1MB), unless you've allocated that region for something else. The RT106x has 1MB of FlexRAM in addition to the 512KB of ITCM and 512KB of DTCM.

I hope this helps, -Manuel

Hi
The main frequency is 528mhz, and it can work normally in flash. My board is indeed a custom board

[beiszhihao]

Latest progress: I found that the SDRAM address can be accessed after I enter the main function, but it cannot be accessed before I enter it

[dleach02]

I am moving this issue to a discussion. If we later determine there is an actual bug instead of a question on how to do a custom board then we can move it back to the issues.

[manupalu]

Hi @beiszhihao ,

You should be able to configure the additional 1MB of OCRAM/FlexRAM that the RT1060 offers for your application. Keep in mind that it won't be as fast as ITCM/DTCM as those are Tightly-Coupled Memories close to the processor, but it should work if you're not able to get the sdram to work properly.

Let us know if you have any other concerns,
-Manuel

[DerekSnell]

Hi @beiszhihao ,

It sounds like the RT1061 you are using is not configured for accessing the SDRAM immediately after booting. And later, after the Zephyr startup code executes and configures more of the hardware, it is able to access SDRAM, like in main().

Some background on accessing the SDRAM in the i.MX RT1xxx family of MCUs: The SEMC is the memory peripheral in the SoC that is used to access any external SDRAM. Before accessing the SDRAM, the SEMC must be configured for that SDRAM, the pin muxes for all the pins must be configured, various clocks used in the SoC need to be configured, and the SDRAM must also be initialized. These MCUs also include a bootloader in ROM that executes after reset, before the application executes. The ROM can also configure all this hardware before the application executes using the Device Configuration Data (DCD). DCD is optional, but if used, a block of DCD commands are stored in the flash. When the ROM bootloader sees DCD is enabled, it loads the DCD commands from flash, and follows the DCD commands to configure the MCU hardware.

NXP leverages this DCD in our Zephyr port to have the ROM configure the SEMC and other hardware for SDRAM access. Our MCUXpresso SDK projects typically do the same. Therefore, as soon as the application code starts to execute, it can access the SDRAM. Based on what you have shared, it seems that the DCD you are booting with is not properly configuring the MCU on your board to access the external SDRAM. But then the startup code that Zephyr executes changes that configuration, so in main() you can access the SDRAM.

I think you have 2 options for accessing the SDRAM earlier in your startup code, like in z_bss_zero():
1) Update the DCD used in your application image, to enable SDRAM access
or
2) Add the function z_arm_platform_init() to your app, and configure the MCU in this routine, called early in the startup code. It can execute before the SDRAM is accessed.

Either way, I would use your current application to diagnose what part of the startup code needs to execute before main(), to enable the SDRAM access for you. If you narrow that down to a line of code or a function, it will help understand what needs to be changed in the 2 options above. Perhaps you will find a pinmux or clock setting is required first, and then you can access the SDRAM. You could use the debugger for this, to step through the code and test accessing the SDRAM. I think the code needed to enable your SDRAM is probably called from z_sys_init_run_level(). Zephyr uses this to initialize the enabled devices in the device tree, and other hardware initialization. You can learn more details about the Zephyr startup process in NXP's webinar.

For additional details on these 2 options to get you started, I am referring to the newly-released Zephyr v2.7.0.

For 1) updating the DCD, the MCU Reference Manual has details about the DCD format, and location in the image programmed to flash. The DCD used by Zephyr for the RT1060 is found at \zephyrproject\modules\hal\nxp\mcux\boards\evkmimxrt1060\dcd.c. If you edit this DCD, you can use the MCUXpresso Config Tool (also integrated in MCUXPresso IDE) to generate the DCD binary.

For 2) adding z_arm_platform_init(), this function is executed early in the startup code when the Kconfig symbol CONFIG_PLATFORM_SPECIFIC_INIT is selected. By default this is not used in the RT platforms. But when it is used, it is intended to initialize the hardware before the rest of the startup code, so before BSS is initialized. I used the attached main.c to prove this out. This uses z_arm_platform_init() to read/write SDRAM. This runs on our MIMXRT1060-EVK board, but sounds like this will not run on your board. Once you isolate the change needed for your board to access the SDRAM, you can add it to this startup function. I used the West command below to build and test this:

west build -b mimxrt1060_evk -d hello_RT1060 zephyrproject\zephyr\samples\hello_world --pristine -- -DCONFIG_PLATFORM_SPECIFIC_INIT=y

Let us know what you find, Best regards

[beiszhihao]

Thank you very much for answering my question. When I use your command, I am prompted with this: undefined reference to
undefined reference toz_arm_platform_init'`
Does this have anything to do with my SOC?, I opened dconfig according to your instructions_ PLATFORM_ SPECIFIC_ Init macro but failed to compile

Please help me. Thank you very much

[DerekSnell]

Thank you very much for answering my question. When I use your command, I am prompted with this: undefined reference to undefined reference toz_arm_platform_init'` Does this have anything to do with my SOC?, I opened dconfig according to your instructions_ PLATFORM_ SPECIFIC_ Init macro but failed to compile

Please help me. Thank you very much

Hi @beiszhihao ,

You need the function z_arm_platform_init() included in your build. With the NXP RT platforms, it is not there by default. I provided the modified main.c attachment in my response above. It modified the hello_world application, and added z_arm_platform_init().

Try using that main.c and see if it builds for you. Best regards