-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
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
added
bug
The issue is a bug, or the PR is fixing a bug
area: Flash
platform: NXP
NXP
labels
Oct 23, 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
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)
toflash_mcux_read(addr, len)
calling the NXP HAL functionFLASH_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 givenaddr
, 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: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 simpleFLASH_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: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 inFaulting instruction address (r15/pc): 0x00001234
The backtrace as I could capture is:
(
thread_valid_cb
is the symbol closest to address 0 AFAICS).Environment (please complete the following information):
185432c96dd7
The text was updated successfully, but these errors were encountered: