Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nxp/lpc55s36: failure reading from internal Flash via flash_read() #80325

Closed
pillo79 opened this issue Oct 23, 2024 · 0 comments · Fixed by #80351
Closed

nxp/lpc55s36: failure reading from internal Flash via flash_read() #80325

pillo79 opened this issue Oct 23, 2024 · 0 comments · Fixed by #80351
Assignees
Labels
area: Flash bug The issue is a bug, or the PR is fixing a bug platform: NXP Drivers NXP Semiconductors, drivers platform: NXP NXP priority: low Low impact/importance bug

Comments

@pillo79
Copy link
Collaborator

pillo79 commented Oct 23, 2024

Describe the bug

I am having trouble reading from internal Flash on the LPC55S36 on current main.
I traced the issue from flash_read(addr, len) to flash_mcux_read(addr, len) calling the NXP HAL function FLASH_IsFlashAreaReadable, which jumps to an hardcoded ROM/bootloader function address (which is sadly not accessible by the debug probe) and in a few instructions to the given addr, causing a panic.

To Reproduce

This is reproducible on my end building and running the unmodified samples/drivers/flash_shell sample on an LPCXpresso55S36 eval board:

west build -p -b lpcxpresso55s36 samples/drivers/flash_shell/
west flash -r linkserver

Executing flash read flash-controller@34000 0 1 on the uart console that pops up triggers a fault at address 0 and crashes Zephyr.

Expected behavior
A proper Flash read on this SOC.

Note that a quick test of replacing the body of flash_mcux_read with a simple FLASH_Read() HAL API call results in the expected behavior, including detection of non-available pages.

Impact
Blocker for Flash API access on this platform.

Logs and console output
Running a valid command on the flash_shell sample shows the following console output:

Flash shell sample
*** Booting Zephyr OS build v3.7.0-4863-g185432c96dd7 ***
uart:~$ flash read flash-controller@34000 0 1
[00:00:09.488,000] <err> os: ***** USAGE FAULT *****
[00:00:09.488,000] <err> os:   Illegal use of the EPSR
[00:00:09.488,000] <err> os: r0/a1:  0x00000076  r1/a2:  0x40000000  r2/a3:  0x00000001
[00:00:09.488,000] <err> os: r3/a4:  0x13028c41 r12/ip:  0x0000bf4d r14/lr:  0x0000bf69
[00:00:09.488,000] <err> os:  xpsr:  0x80000000
[00:00:09.488,000] <err> os: Faulting instruction address (r15/pc): 0x00000000
[00:00:09.488,000] <err> os: >>> ZEPHYR FATAL ERROR 35: Unknown error on CPU 0
[00:00:09.488,000] <err> os: Current thread: 0x20000630 (shell_uart)
[00:00:09.551,000] <err> os: Halting system

Note the Faulting instruction address (r15/pc): 0x00000000 changes to mimic the requested address (0 in the command above). E.g. flash read flash-controller@34000 0x1234 4 results in Faulting instruction address (r15/pc): 0x00001234

The backtrace as I could capture is:

#0  z_arm_usage_fault () at zephyr/arch/arm/core/cortex_m/fault_s.S:80
#1  <signal handler called>
#2  thread_valid_cb (cthread=0x76 <_irq_vector_table+54>, user_data=0x40000000) at zephyr/subsys/shell/modules/kernel_service/thread/thread.c:31
#3  0x0000bf68 in flash_mcux_read (dev=<optimized out>, offset=<optimized out>, data=0x20009d2c <shell_uart_stack+1628>, len=23567)
    at zephyr/drivers/flash/soc_flash_mcux.c:210
#4  0x0000d7d4 in shell_uart_backend ()

(thread_valid_cb is the symbol closest to address 0 AFAICS).

Environment (please complete the following information):

  • OS: Linux
  • Toolchain: Zephyr SDK 0.16.8
  • Commit SHA: 185432c96dd7
@pillo79 pillo79 added bug The issue is a bug, or the PR is fixing a bug area: Flash platform: NXP NXP labels Oct 23, 2024
@pillo79 pillo79 added the platform: NXP Drivers NXP Semiconductors, drivers label Oct 25, 2024
@mmahadevan108 mmahadevan108 added the priority: low Low impact/importance bug label Oct 29, 2024
pillo79 added a commit to pillo79/zephyr that referenced this issue Nov 5, 2024
As other targets in the LPC55xxx series, the LPC55S36 has a Flash
controller that raises ECC errors when reading erased pages directly.
To avoid this, there is special code for this platform that calls the
HAL FLASH_IsFlashAreaReadable() function. However, this in turn calls a
function at an hardcoded address in ROM that _always_ causes an
instruction fault, making the situation worse.

This patch reworks the read operation to use the FLASH_Read() HAL
function for this target to gracefully handle error conditions and
properly emulate accesses to erased pages. The preprocessor is required
since some targets do not define the FLASH_Read() function.

Fixes: zephyrproject-rtos#80325

Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
pillo79 added a commit to pillo79/zephyr that referenced this issue Nov 7, 2024
As other targets in the LPC55xxx series, the LPC55S36 has a Flash
controller that raises ECC errors when reading erased pages directly.
To avoid this, there is special code for this platform that calls the
HAL FLASH_IsFlashAreaReadable() function. However, this in turn calls a
function at an hardcoded address in ROM that _always_ causes an
instruction fault, making the situation worse.

This patch reworks the verify operation to use the FLASH_VerifyErased()
HAL function for this target to gracefully handle error conditions and
properly emulate accesses to erased pages. The preprocessor is required
since some targets do not define the FLASH_VerifyErased() function.

Fixes: zephyrproject-rtos#80325

Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
mmahadevan108 pushed a commit that referenced this issue Nov 7, 2024
As other targets in the LPC55xxx series, the LPC55S36 has a Flash
controller that raises ECC errors when reading erased pages directly.
To avoid this, there is special code for this platform that calls the
HAL FLASH_IsFlashAreaReadable() function. However, this in turn calls a
function at an hardcoded address in ROM that _always_ causes an
instruction fault, making the situation worse.

This patch reworks the read operation to use the FLASH_Read() HAL
function for this target to gracefully handle error conditions and
properly emulate accesses to erased pages. The preprocessor is required
since some targets do not define the FLASH_Read() function.

Fixes: #80325

Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
JA-NXP pushed a commit to nxp-upstream/zephyr that referenced this issue Nov 19, 2024
As other targets in the LPC55xxx series, the LPC55S36 has a Flash
controller that raises ECC errors when reading erased pages directly.
To avoid this, there is special code for this platform that calls the
HAL FLASH_IsFlashAreaReadable() function. However, this in turn calls a
function at an hardcoded address in ROM that _always_ causes an
instruction fault, making the situation worse.

This patch reworks the read operation to use the FLASH_Read() HAL
function for this target to gracefully handle error conditions and
properly emulate accesses to erased pages. The preprocessor is required
since some targets do not define the FLASH_Read() function.

Fixes: zephyrproject-rtos#80325

Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Flash bug The issue is a bug, or the PR is fixing a bug platform: NXP Drivers NXP Semiconductors, drivers platform: NXP NXP priority: low Low impact/importance bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants