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

spi_nxp_lpspi: Hardfault regression #87768

Open
decsny opened this issue Mar 27, 2025 · 4 comments · May be fixed by #86939 or #87789
Open

spi_nxp_lpspi: Hardfault regression #87768

decsny opened this issue Mar 27, 2025 · 4 comments · May be fixed by #86939 or #87789
Assignees
Labels
area: SPI SPI bus bug The issue is a bug, or the PR is fixing a bug platform: NXP Drivers NXP Semiconductors, drivers priority: low Low impact/importance bug Regression Something, which was working, does not anymore

Comments

@decsny
Copy link
Member

decsny commented Mar 27, 2025

Describe the bug

There is some hard fault in the LPSPI driver during device init on some platforms.. This is new since 4.1.0 release

To Reproduce

west build -b frdm_ke17z -p always tests\drivers\spi\spi_loopback
west flash -r jlink

Expected behavior

Test pass

Impact

Driver does not work for some platform due to hard fault in init

Logs and console output

E: ***** HARD FAULT *****
E: r0/a1:  0x4002c000  r1/a2:  0x00008d28  r2/a3:  0x00000303
E: r3/a4:  0x00000002 r12/ip:  0x00000753 r14/lr:  0x00002c6b
E:  xpsr:  0x21000000
E: Faulting instruction address (r15/pc): 0x0000824e
E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
E: Current thread: 0x20004688 (main)
E: Halting system

Additional context

I did not bisect but I did debug and it is hard fault on LPSPI_Reset in the init of the device, likely introduced on this commit: 9f10418

@decsny decsny added bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug area: SPI SPI bus platform: NXP Drivers NXP Semiconductors, drivers labels Mar 27, 2025
@decsny
Copy link
Member Author

decsny commented Mar 27, 2025

@PetervdPerk-NXP I should have thought more and block that PR , since I did mention something similar on the review comments about how there can be issues if accessing peripheral registers before hardware signal reset on some platforms. I think the cause of this fault is similar but instead of reset, it's because the peripheral is not clocked on some of the platforms due to the clocking being done on the HAL driver in the transceive (cc @mmahadevan108 , this is why we need to do clocking in zephyr driver)

I will post a PR to fix this and some other bug

@ehughes
Copy link

ehughes commented Mar 30, 2025

@decsny @PetervdPerk-NXP

FYI:

This is an issue w/ MCXA156. I was trying to retest #85081 with v4.1 and noticed BusFaults very early on w/ ozone.

It does seem timing dependent. Some of my test cases w/ 85081 we were as I think the order of init was slightly different.

Image

@decsny
Copy link
Member Author

decsny commented Mar 30, 2025

@ehughes I forgot to link the PR , it's actually a very simple bug, just has a bus fault on some platforms because the peripheral is not clocked. I'm making a PR which is going to fix multiple regressions going on in main since after the 4.1 release.

@decsny decsny linked a pull request Mar 30, 2025 that will close this issue
@ehughes
Copy link

ehughes commented Mar 31, 2025

@decsny sound good. please ping me when you want me to check it out and retest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: SPI SPI bus bug The issue is a bug, or the PR is fixing a bug platform: NXP Drivers NXP Semiconductors, drivers priority: low Low impact/importance bug Regression Something, which was working, does not anymore
Projects
None yet
2 participants