NXP RT1060-EVK faults with update of FlexSPI LUT #56967

ofirshe · 2023-04-18T09:10:54Z

ofirshe
Apr 18, 2023

Hello,

I'm encountering a Usage fault on the RT1060-EVK board. This issue happens during the boot of the application, specifically in the mcux_igpio_configure() function. It's worth noting that this is a deterministic bug with a clear symptom.

The problem occurs when the ethernet driver calls the eth_phy_reset() function, which in turn executes the mcux_igpio_configure() function on line 982:

/* pull up the ENET_INT before RESET. */ err = gpio_pin_configure_dt(&context->int_gpio, GPIO_OUTPUT_ACTIVE);

Unfortunately, the gpio_cfg_reg pointer is assigned a corrupted value of 0x4294191a, as seen in the variables table on the right side during debugging. I've placed a conditional breakpoint on this line with the condition of cfg_idx == 10 (which is the numeric value of int_gpio). However, when I tried to read the memory value stored in config->pin_muxes[cfg_idx].config_register (0x6001f02c) with gdb at the same time I caught the bug with the debugger, the retrieved value was the valid address of the configuration register (0x401f82d4).

When I toggled several breakpoints before the line of the bug with the same condition of cfg_idx == 10 to slow down the run, the error was not reproduced, and the value retrieved into gpio_cfg_reg was the valid one (which seems like a race condition).

Usage fault output:
[00:00:00.000,000] <err> os: ***** USAGE FAULT *****
[00:00:00.000,000] <err> os:   Unaligned memory access
[00:00:00.000,000] <err> os: r0/a1:  0x0000000a  r1/a2:  0x00000108  r2/a3:  0x6001ee88
[00:00:00.000,000] <err> os: r3/a4:  0x4294191a r12/ip:  0x401f82a8 r14/lr:  0x60010f35
[00:00:00.000,000] <err> os:  xpsr:  0x41000000
[00:00:00.000,000] <err> os: Faulting instruction address (r15/pc): 0x6001b9b2
[00:00:00.000,000] <err> os: >>> ZEPHYR FATAL ERROR 31: Unknown error on CPU 0
[00:00:00.000,000] <err> os: Current thread: 0x80004ed8 (unknown)
[00:00:00.029,000] <err> os: Halting system

If I run the same executable elf without a debugger, I get a bus fault at a different instruction, but still in the mcux_igpio_configure() function (this bug is also deterministic).

Bus fault output:
[00:00:00.000,000] <err> os: ***** BUS FAULT *****
[00:00:00.000,000] <err> os:   Precise data bus error
[00:00:00.000,000] <err> os:   BFAR Address: 0xd7ffaf8d
[00:00:00.000,000] <err> os: r0/a1:  0x0000000a  r1/a2:  0xd7ffaf8d  r2/a3:  0x6001ee88
[00:00:00.000,000] <err> os: r3/a4:  0x00000000 r12/ip:  0x401f82a8 r14/lr:  0x60010f35
[00:00:00.000,000] <err> os:  xpsr:  0x21000000
[00:00:00.000,000] <err> os: Faulting instruction address (r15/pc): 0x6001ba30
[00:00:00.000,000] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:00.000,000] <err> os: Current thread: 0x80004ed8 (unknown)
[00:00:00.035,000] <err> os: Halting system

Disassembly of mcux_igpio_configure() function:

6001b98c <mcux_igpio_configure>:
6001b98c:	b5f0      	push	{r4, r5, r6, r7, lr}
6001b98e:	4615      	mov	r5, r2
6001b990:	6842      	ldr	r2, [r0, #4]
6001b992:	b087      	sub	sp, #28
6001b994:	460e      	mov	r6, r1
6001b996:	7c57      	ldrb	r7, [r2, #17]
6001b998:	4608      	mov	r0, r1
6001b99a:	2300      	movs	r3, #0
6001b99c:	429f      	cmp	r7, r3
6001b99e:	dc44      	bgt.n	6001ba2a <mcux_igpio_configure+0x9e>
6001b9a0:	7c13      	ldrb	r3, [r2, #16]
6001b9a2:	4283      	cmp	r3, r0
6001b9a4:	dd4c      	ble.n	6001ba40 <mcux_igpio_configure+0xb4>
6001b9a6:	2314      	movs	r3, #20
6001b9a8:	6891      	ldr	r1, [r2, #8]
6001b9aa:	07ac      	lsls	r4, r5, #30
6001b9ac:	fb03 1100 	mla	r1, r3, r0, r1
6001b9b0:	684b      	ldr	r3, [r1, #4]
6001b9b2:	681b      	ldr	r3, [r3, #0]
6001b9b4:	bf4c      	ite	mi
6001b9b6:	f443 6300 	orrmi.w	r3, r3, #2048	; 0x800
6001b9ba:	f423 6300 	bicpl.w	r3, r3, #2048	; 0x800
6001b9be:	f015 0f30 	tst.w	r5, #48	; 0x30
6001b9c2:	d044      	beq.n	6001ba4e <mcux_igpio_configure+0xc2>
6001b9c4:	06e8      	lsls	r0, r5, #27
6001b9c6:	bf56      	itet	pl
6001b9c8:	f423 4340 	bicpl.w	r3, r3, #49152	; 0xc000
6001b9cc:	f443 4420 	orrmi.w	r4, r3, #40960	; 0xa000
6001b9d0:	f443 5400 	orrpl.w	r4, r3, #8192	; 0x2000
6001b9d4:	6857      	ldr	r7, [r2, #4]
6001b9d6:	4668      	mov	r0, sp
6001b9d8:	2218      	movs	r2, #24
6001b9da:	f7fb fde1 	bl	600175a0 <memcpy>
6001b9de:	2200      	movs	r2, #0
6001b9e0:	2101      	movs	r1, #1
6001b9e2:	4668      	mov	r0, sp
6001b9e4:	9405      	str	r4, [sp, #20]
6001b9e6:	f000 f97a 	bl	6001bcde <pinctrl_configure_pins>
6001b9ea:	f405 3340 	and.w	r3, r5, #196608	; 0x30000
6001b9ee:	f5b3 3f40 	cmp.w	r3, #196608	; 0x30000
6001b9f2:	d025      	beq.n	6001ba40 <mcux_igpio_configure+0xb4>
6001b9f4:	0329      	lsls	r1, r5, #12
6001b9f6:	d504      	bpl.n	6001ba02 <mcux_igpio_configure+0x76>
6001b9f8:	2201      	movs	r2, #1
6001b9fa:	4631      	mov	r1, r6
6001b9fc:	4638      	mov	r0, r7
6001b9fe:	f001 fb84 	bl	6001d10a <GPIO_PinWrite>
6001ba02:	036a      	lsls	r2, r5, #13
6001ba04:	d504      	bpl.n	6001ba10 <mcux_igpio_configure+0x84>
6001ba06:	2200      	movs	r2, #0
6001ba08:	4631      	mov	r1, r6
6001ba0a:	4638      	mov	r0, r7
6001ba0c:	f001 fb7d 	bl	6001d10a <GPIO_PinWrite>
6001ba10:	2101      	movs	r1, #1
6001ba12:	03ab      	lsls	r3, r5, #14
6001ba14:	f04f 0000 	mov.w	r0, #0
6001ba18:	fa01 f606 	lsl.w	r6, r1, r6
6001ba1c:	6879      	ldr	r1, [r7, #4]
6001ba1e:	bf4c      	ite	mi
6001ba20:	430e      	orrmi	r6, r1
6001ba22:	ea21 0606 	bicpl.w	r6, r1, r6
6001ba26:	607e      	str	r6, [r7, #4]
6001ba28:	e00c      	b.n	6001ba44 <mcux_igpio_configure+0xb8>
6001ba2a:	68d1      	ldr	r1, [r2, #12]
6001ba2c:	eb01 0443 	add.w	r4, r1, r3, lsl #1
6001ba30:	f811 1013 	ldrb.w	r1, [r1, r3, lsl #1]
6001ba34:	42b1      	cmp	r1, r6
6001ba36:	d808      	bhi.n	6001ba4a <mcux_igpio_configure+0xbe>
6001ba38:	7864      	ldrb	r4, [r4, #1]
6001ba3a:	4421      	add	r1, r4
6001ba3c:	42b1      	cmp	r1, r6
6001ba3e:	dd03      	ble.n	6001ba48 <mcux_igpio_configure+0xbc>
6001ba40:	f06f 0085 	mvn.w	r0, #133	; 0x85
6001ba44:	b007      	add	sp, #28
6001ba46:	bdf0      	pop	{r4, r5, r6, r7, pc}
6001ba48:	1b00      	subs	r0, r0, r4
6001ba4a:	3301      	adds	r3, #1
6001ba4c:	e7a6      	b.n	6001b99c <mcux_igpio_configure+0x10>
6001ba4e:	f423 5400 	bic.w	r4, r3, #8192	; 0x2000
6001ba52:	e7bf      	b.n	6001b9d4 <mcux_igpio_configure+0x48>

Project configuration file:

CONFIG_CPP=y
CONFIG_BUILD_OUTPUT_S19=y
CONFIG_I2C=y
CONFIG_MAIN_STACK_SIZE=65536
CONFIG_ONOFF=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_RING_BUFFER=y
CONFIG_EVENTFD=y
CONFIG_JSON_LIBRARY=y

#in case we're getting errno=12, we should increase it.
CONFIG_EVENTFD_MAX=32

#in case we're getting errno=23, we should increase it.
CONFIG_POSIX_MAX_FDS=64

#Flash
CONFIG_SPI=y
CONFIG_FLASH=y
CONFIG_FLASH_MAP=y

#Networking 
CONFIG_NETWORKING=y
CONFIG_NET_UDP=y
CONFIG_NET_TCP=y
CONFIG_NET_IPV4=y
 
CONFIG_INIT_STACKS=y

CONFIG_NET_LOG=y
CONFIG_LOG=y

CONFIG_NET_CONFIG_SETTINGS=y
CONFIG_NET_CONFIG_NEED_IPV4=y
CONFIG_NET_CONFIG_MY_IPV4_ADDR="192.0.2.1"
CONFIG_NET_L2_ETHERNET=y
CONFIG_NET_CONTEXT_RCVTIMEO=y

CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_POSIX_NAMES=y

CONFIG_NET_PKT_RX_COUNT=16
CONFIG_NET_PKT_TX_COUNT=16
CONFIG_NET_BUF_RX_COUNT=64
CONFIG_NET_BUF_TX_COUNT=64
CONFIG_NET_MAX_CONN=64

Build output:

memory region         Used Size  Region Size  %age Used
           FLASH:      146616 B         8 MB      1.75%
             RAM:      137159 B        32 MB      0.41%
            ITCM:        3600 B       128 KB      2.75%
            DTCM:       13908 B       128 KB     10.61%
           OCRAM:          0 GB       768 KB      0.00%
        IDT_LIST:          0 GB         2 KB      0.00%

I'm aligned with the lastest commit of zephyr at this moment 129291f
Zephyr version: 3.3.99 (C:/Users/ofirs/epu-bsp/zephyr), build: zephyr-v3.3.0-2803-gf4b4045fb6fa

I would appreciate any assistance provided.

Best regards,
Ofir.

Answered by danieldegrasse

May 19, 2023

Hi @ofirshe- I believe I have replicated your issue, and found a resolution. It appears that the root cause is likely due to the LUT array that is programmed into the FlexSPI being placed in the FLASH region. This means that while the LUT array (which is used to configure the commands the FlexSPI uses to interact with the flash) is being programmed, flash read operations will be ongoing. This can result in the LUT values that are being programmed being incorrect.

To verify this, I first reproduced the FlexSPI issue. Once I had the issue reproduced, I created a duplicate LUT array in RAM, and ensured that array was linked in at build time. With the duplicate array, the FlexSPI fault still …

View full answer

DerekSnell · 2023-04-18T13:08:51Z

DerekSnell
Apr 18, 2023
Collaborator

Hi @ofirshe ,
This sounds like a frustrating issue. Sorry you are stuck dealing with this.

The final address being read for this pointer at 0x6001f02c is in flash. And the config pointer is also in flash at 0x6001EE88. Since these are constant, I would not expect a race condition when reading those addresses. But this line of code config->pin_muxes[cfg_idx].config_register is doing a long chain of reads, some of which appear to be in RAM like cfg_idx. Are you able to break down these reads in the debugger, using the disassembly and the registers view, to find where exactly the invalid read is located?

Another thought, you mention adding delay with breakpoints avoids the issue. Are you able to add delay in the source code to avoid the issue? This could be helpful to understand where the delay is required. If you can insert delay and get this working, then moving that delay around in the source may expose what read and/or write is causing a race condition.

Do you have steps to replicate this on the EVK? And specifically what is the full part number of the RT1060 EVK you are using? There are multiple versions of this EVK.

Good luck with the troubleshooting

0 replies

ofirshe · 2023-04-19T11:37:47Z

ofirshe
Apr 19, 2023
Author

Hey @DerekSnell,
As you requested, I used the disassembly to examine these reads in the debugger, focusing specifically on the code block below:

Let's explain this code section below:

 77       		(volatile uint32_t *)config->pin_muxes[cfg_idx].config_register;
6001b9a6:   movs    r3, #20 // set in r3 the size of the pinctrl_soc_pinmux structure (which is the pointer type of pin_muxes)
6001b9a8:   ldr     r1, [r2, #8] // Assign to R1 the memory address of the beginning of the array config->pin_muxes. (=0x6001ef60), r2 is assigned with the address of config pointer(0x6001ee88). 
 81       	if ((flags & GPIO_SINGLE_ENDED) != 0) {
6001b9aa:   lsls    r4, r5, #30 //can disregard this instruction as it is just an artifact of ARM reordering.
 77       		(volatile uint32_t *)config->pin_muxes[cfg_idx].config_register;
6001b9ac:   mla     r1, r3, r0, r1 // In this step, we compute the memory location of config->pin_muxes[cfg_idx] and store it in r1. The calculation is done by multiplying r3 (which represents the size of the structure) with r0 (which holds the index cfg_idx), and adding the result to the current value of r1 (which holds the address of config->pin_muxes)
 76       	volatile uint32_t *gpio_cfg_reg =
6001b9b0:   ldr     r3, [r1, #4] // retrieve the memory location of config_register from an offset of 4 bytes within the pinctrl_soc_pinmux structure, and store it in register r3.
 78       	uint32_t reg = *gpio_cfg_reg;
6001b9b2:   ldr     r3, [r3, #0] //access the memory location pointed to by register r3 (gpio_cfg_reg) and read it's value.

The problem lies with the instruction "ldr r1, [r2, #8]" at address 6001b9a8. If I set a breakpoint after this instruction instead of before, r1 takes on the value of 0x40 inexplicably, while all other registers remain valid. I don't know why r1 is being overwritten with this value instead of the address of config->pin_muxes (which is 0x6001ef60) as in a valid run. Subsequently, at instruction 6001b9ac (mla r1, r3, r0, r1), r1 will have a value of 0x108.

Subsequently, upon accessing the memory location 0x10C (which corresponds to 0x108 + 4), I notice that the value stored at that address, 0x4294191a, matches the corrupted value we saw earlier in the Usage Fault message, and has been assigned to r3. This leads to a usage fault taking place at 0x6001b9b2, as previously explained.

I included a delay just before the problematic code section. This modification resolved the issue in both scenarios - with or without a debugger.

Regarding the board version, I have observed that the microcontroller present on the board is SOC part MIMXRT1062DVL6B. To compile the code, I use the command "west build -b mimxrt1060_evk."

Best regards,
Ofir.

0 replies

ofirshe · 2023-04-20T12:20:38Z

ofirshe
Apr 20, 2023
Author

Hey @DerekSnell,

As I continue to debug the problem, I have gone through all the initialization functions at INIT_LEVEL_POST_KERNEL level (where the ethernet driver is initialized), and I have observed that if I slow down the run from the initialization of __device_dts_ord_539 (flash_mcux_flexspi_nor), the bug is not reproduced. Therefore, I have set a conditional breakpoint on line 252 with a condition of entry==0x6001e5d0(__init___device_dts_ord_539).

Please refer to the following image:

As mentioned in my previous message, I had written that in the mcux_igpio_configure() function at address 6001b9a8, register r1 was being assigned with 0x40 instead of the address of the beginning of the array config->pin_muxes. From the moment the flash_mcux_flexspi_nor device was initialized and the conditional breakpoint was triggered, I set a watchpoint on register r1 to catch the times it was being assigned with 0x40. I caught two places in the debugger:

The first one was in the _NVIC_SetPriority function which was triggered by spi_mcux_config_func##n:

The second place was in spi_context_unlock_unconditionally:

I have no idea why slowing down the initialization of the flash_mcux_flexspi_nor driver has an effect on the problem. Additionally, the problem is not reproduced every time, and if I add or remove some variables and code lines to my code, it raises the error (apparently because the size of the elf and the addresses are being changed in the flash, and again, I don't know why slowing down the run helps to solve the problem). I can guess that during the mcux_igpio_configure() function, an interrupt occurred and modifies r1 register, but I'm not entirely sure.

Could you kindly offer me your insights and ideas on why this problem occurs based on what I have shared with you, as well as your understanding of how the system is designed and the drivers' functionality? Your input would be much appreciated.

Thanks in advance,
Ofir.

0 replies

ofirshe · 2023-04-24T14:58:07Z

ofirshe
Apr 24, 2023
Author

Hi @DerekSnell,

I hope you had a good weekend. We have been struggling with this issue for quite some time. Would you happen to have any insights or ideas regarding this issue?

Thank you,
Ofir.

0 replies

DerekSnell · 2023-04-25T12:07:04Z

DerekSnell
Apr 25, 2023
Collaborator

Hi @ofirshe ,

Thank you for sharing all this detailed info from your debugging efforts. I suspect, this is an issue related to reading from the flash. And since you found the issue is related to the flash_mcux_flexspi_nor driver initializing, I wonder if flash_flexspi_nor_init() is changing something in the FlexSPI configuration, which is causing this.

The FlexSPI is the interface to the XIP flash. When you boot from flash, the ROM bootloader initializes the FlexSPI, and configures it in a safe mode to read the Flash Configuration Block from the flash. Based on that FCB, the ROM reconfigures the FlexSPI for that external flash, and boots the application.

If flash_flexspi_nor_init() makes a change to the FlexSPI config while the app is XIPing from the flash, perhaps this leads to an issue reading the data from flash at that time. I suspect the problem is not in mcux_igpio_configure() itself, that just happens to be where you notice the issue. The FlexSPI has a prefetch buffer, plus the cache is enabled. So the wrong data is likely read after flash_flexspi_nor_init() is called, and before you find it in mcux_igpio_configure().

We recommend you try removing portions of the flash_flexspi_nor_init() function, and see if some portion of the configuration is causing issues. The memc_flexspi_set_device_config() should not be called if memc_flexspi_is_running_xip() returns true, but it would be helpful if you can verify this in your case.

Best regards

0 replies

ofirshe · 2023-04-27T15:46:01Z

ofirshe
Apr 27, 2023
Author

Hello, @DerekSnell,

After using the debugger, I confirmed that memc_flexspi_set_device_config() is not being executed when CONFIG_FLASH_MCUX_FLEXSPI_XIP=y. However, simply modifying the source code by adding or removing lines can sometimes obscure the underlying problem (as I've experienced with similar development work), possibly due to causing some addresses in the Flash to be shifted. Therefore, I don't think that randomly disabling sections of flash_flexspi_nor_init() is an effective solution without first understanding the root cause of the issue. To support my argument, I disabled the following section, which is irrelevant for my situation since I'm executing from the Flash:

if (!memc_flexspi_is_running_xip(data->controller) &&
	    memc_flexspi_set_device_config(data->controller, &data->config,
					   data->port)) {
		LOG_ERR("Could not set device configuration");
		return -EINVAL;
	}

and the problem was "resolved". Unfortunately, I didn't manage to understand the root cause for the problem even after quite time debugging this issue.

Do you want me to provide you some additional debugging information to understand better the root cause ?

Thanks,
Ofir.

0 replies

DerekSnell · 2023-04-27T20:03:56Z

DerekSnell
Apr 27, 2023
Collaborator

Hi @ofirshe ,
Thanks for sharing these details. I understand diagnosing this issue is challenging, since slight changes make the issue go away. We have some theories we want to test out. But I do not want to burden you with this work. It would be best if we can replicate the issue, so we can test it further.

If the code and steps to replicate this is not something you can share here in this public forum, can you message me on Discord at Derek.Snell#9539, and we can privately discuss how to help each other there. Thanks

0 replies

danieldegrasse · 2023-05-19T21:57:28Z

danieldegrasse
May 19, 2023
Collaborator

Hi @ofirshe- I believe I have replicated your issue, and found a resolution. It appears that the root cause is likely due to the LUT array that is programmed into the FlexSPI being placed in the FLASH region. This means that while the LUT array (which is used to configure the commands the FlexSPI uses to interact with the flash) is being programmed, flash read operations will be ongoing. This can result in the LUT values that are being programmed being incorrect.

To verify this, I first reproduced the FlexSPI issue. Once I had the issue reproduced, I created a duplicate LUT array in RAM, and ensured that array was linked in at build time. With the duplicate array, the FlexSPI fault still occured. At this point, I updated the call to memc_flexspi_update_lut to use the LUT array in RAM instead of the array in the FLASH region:

this change resolved the fault.

I verified that this change did not affect the alignment of any code or data placed in the FLASH or RAM section of the image by checking the MAP files from builds using each call of the memc_flexspi_update_lut. Since alignment was not affected, I believe that the change here would not mask any underlying issue, and the fact that the change fixes the issue suggests that it is the root cause. Finally, MCUX SDK moves the FlexSPI LUT array to SRAM before programming it, which further supports the assertion this driver bug is the root cause: https://github.com/nxp-mcuxpresso/mcux-sdk-examples/blob/b3ba7106f96069742bdb2f96fd5028d365ef1108/evkbmimxrt1060/driver_examples/flexspi/nor/polling_transfer/flexspi_nor_flash_ops.c#L574

If you'd like to reproduce this on your end, I have attached a flexspi-ram-lut.patch file, which you can apply to your Zephyr repo with git apply. This should allow you to duplicate the steps I took here by changing the call to memc_flexspi_update_lut to use the LUT array in SRAM.
flexspi-ram-lut.patch

Edit: I have also created a PR to fix the issue: #58096

0 replies

mlaventure · 2023-09-27T17:13:12Z

mlaventure
Sep 27, 2023

Hi,

Sorry to revive this discussion, but I believe that I am hitting a similar issue despite using Zephyr v3.4.0 (356c8cb) which has the patch discussed in the previous message.

I am using a board based of the mimxrt1060_evk and trying to get MCUBOOT_SERIAL update working.

Whenever I send data to the configured zephyr,uart-mcumgr the device crashes due to trying to execute code at address 0x0. This occurs because 4 entries (including the one for the uart configured for MCUBOOT_SERIAL) of the _sw_isr_table start being read as zero. The changes are not permanent as resetting the board shows the original value in the debugger.

Similar to the original author, if I break through or slowdown the code of flash_flexspi_nor_init , the issue goes away. In my case, it's making a breakpoint before the memcpy of the LUT that solves it.

I've gone through the FLEXSPI section of the datasheet but haven't found a clue yet. I was hoping someone may have a better idea.

Best,

EDIT: Some additional details, we're running XIP mode and using a GD25Q64E flash.

8 replies

mlaventure Oct 2, 2023

@DerekSnell ignore my previous message, it's properly executed from outside the flash area. I got confused running different tests.

danieldegrasse Oct 2, 2023
Collaborator

Hi @mlaventure- have you been able to get this flash chip working with other flash samples in Zephyr on the RT1060 EVK? For example, what is the output when running tests/drivers/flash/common on your custom board?

The GD25Q64E present on your custom board uses bit 9 in status register 2 as the quad enable bit, and the IS25WP064 present on the RT1060 EVK uses bit 6 of status register 1. I'm assuming that you have already set the quad enable bit manually since it is nonvolatile. If not, this could cause issues when using the LUT present in the flash driver, since that LUT uses quad output read commands.

Beyond that, are you aware of any differences between the LUT you are using for your custom board and the LUT used by the RT1060 EVK? I don't see anything else significantly different between the GD25Q64E and the IS25WP064, but I may be missing something

mlaventure Oct 3, 2023

Hi Daniel,

I haven't tried running the example. I'll try to do so to compare.

I hadn't realized the QE Bit was at a different position for my flash. I was expecting to find a DTS property for it, but turns out it's hardcoded within the value. Unfortunately switching this value does not affect the behavior I am seeing.

As far as I can tell, the LUT seems compatible with my flash, it's the first thing I've checked.

danieldegrasse Oct 3, 2023
Collaborator

I hadn't realized the QE Bit was at a different position for my flash. I was expecting to find a DTS property for it, but turns out it's hardcoded within the value. Unfortunately switching this value does not affect the behavior I am seeing.

Yeah, this is a known issue with the driver- we do have a fix for it, but it likely won't merge until after this Zephyr release. One very unlikely problem you could be facing is that status bit 6 in your flash sets a block protect value, which is non-volatile. You may want to try explicitly writing a 0 to this bit, to make sure that is cleared.

Another thing to check-it looks like in order to set status bit S9 (QE bit) you need to issue instruction 0x31. The driver will currently issue instruction 0x01, which can only write bits S0~S7.

Would you be willing to share the LUT you use at boot? That may help diagnose the issue.

mlaventure Oct 3, 2023

Yes, once I noticed the BP was set, I made sure to unset it. Fortunately the code is not big enough to reach that far and nothing has ever been written to that part so far.

Just double checked the LUT, looks like our vendor copied the one provided by the NXP HAL (https://github.com/zephyrproject-rtos/hal_nxp/blob/master/mcux/mcux-sdk/boards/evkmimxrt1060/xip/evkmimxrt1060_flexspi_nor_config.c#L38).

I think I'll go ahead and restart the zephyr custom board process from scratch. Just occurred to me that we may need DCD that we were not provided.

mlaventure · 2023-09-28T14:53:39Z

mlaventure
Sep 28, 2023

Hi Derek, Unfortunately I'm traveling at the moment, I want to say that moving the breakpoint after the memcpy shows the issue from memory, but I should be able to confirm this coming Friday or Monday.

…

On Thu, Sep 28, 2023, 4:53 AM Derek Snell ***@***.***> wrote: Hi @mlaventure <https://github.com/mlaventure> , that sounds troubling. Can you confirm, if you move the breakpoint right after the FlexSPI LUT is updated, do you still see the issue? Thanks — Reply to this email directly, view it on GitHub <#56967 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD2SE7XRQZXJFUAUUVIBZXTX4VQM5ANCNFSM6AAAAAAXCKSGGI> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

0 replies

NXP RT1060-EVK faults with update of FlexSPI LUT #56967

Uh oh!

Uh oh!

ofirshe Apr 18, 2023

Replies: 10 comments · 8 replies

Uh oh!

DerekSnell Apr 18, 2023 Collaborator

Uh oh!

Uh oh!

ofirshe Apr 19, 2023 Author

Uh oh!

Uh oh!

ofirshe Apr 20, 2023 Author

Uh oh!

Uh oh!

ofirshe Apr 24, 2023 Author

Uh oh!

DerekSnell Apr 25, 2023 Collaborator

Uh oh!

ofirshe Apr 27, 2023 Author

Uh oh!

DerekSnell Apr 27, 2023 Collaborator

Uh oh!

Uh oh!

danieldegrasse May 19, 2023 Collaborator

Uh oh!

Uh oh!

mlaventure Sep 27, 2023

Uh oh!

mlaventure Oct 2, 2023

Uh oh!

danieldegrasse Oct 2, 2023 Collaborator

Uh oh!

mlaventure Oct 3, 2023

Uh oh!

danieldegrasse Oct 3, 2023 Collaborator

Uh oh!

mlaventure Oct 3, 2023

Uh oh!

mlaventure Sep 28, 2023

ofirshe
Apr 18, 2023

Replies: 10 comments 8 replies

DerekSnell
Apr 18, 2023
Collaborator

ofirshe
Apr 19, 2023
Author

ofirshe
Apr 20, 2023
Author

ofirshe
Apr 24, 2023
Author

DerekSnell
Apr 25, 2023
Collaborator

ofirshe
Apr 27, 2023
Author

DerekSnell
Apr 27, 2023
Collaborator

danieldegrasse
May 19, 2023
Collaborator

mlaventure
Sep 27, 2023

danieldegrasse Oct 2, 2023
Collaborator

danieldegrasse Oct 3, 2023
Collaborator

mlaventure
Sep 28, 2023