Skip to content

Conversation

AndreHeinemans-NXP
Copy link
Contributor

@AndreHeinemans-NXP AndreHeinemans-NXP commented Oct 6, 2025

In the DDR LUT, the dummy cycles were not defined for READ_STATUS_REG and had a wrong value for READ. The default amount of dummy cycles on this chip are 20 (0x14). This means the LUT should contain the value of 0x28 (0x14*2) for DDR
at these entries.

Maximum speed is 200MHz according to the mx25um51345g datasheet and is adjusted in the driver code accordingly.

Both changes were tested with an imx95 m7 connected to a mx25um51345g.

edit: Just discovered that the ERASE_CHIP DDR entry in the LUT was also incorrect. I put the fix for that in this PR as well.

In the DDR LUT, the dummy cycles were not defined for READ_STATUS_REG
and had a wrong value for READ.
The default amount of dummy cycles on this chip are 20 (0x14).
This means the LUT should contain the value of 0x28 (0x14*2) for DDR
at these entries.

Signed-off-by: Andre Heinemans <[email protected]>
Maximum speed is 200MHz according to the mx25um51345g datasheet.

Signed-off-by: Andre Heinemans <[email protected]>
The DDR LUT entry for ERASE_CHIP was configured with an incorrect
kFLEXSPI_Command, resulting in the erase operation not being executed.

Signed-off-by: Andre Heinemans <[email protected]>
Copy link

sonarqubecloud bot commented Oct 6, 2025

@dleach02
Copy link
Member

dleach02 commented Oct 6, 2025

@AndreHeinemans-NXP which platform(s) did you see issues with? This driver has been in the tree for a while so curious how you identified these needed changes. Would like to coordinate with @hakehuang to confirm CI coverage.

@AndreHeinemans-NXP
Copy link
Contributor Author

@dleach02
I am working on the Navq95.

The difference is maybe in the rx-clock-source setting. At first I had the driver configured with rx-clock-source='3 # External input from DQS pad'. With this setting the driver worked without a problem.

But we encountered some issues with the DQS signal and for that reason I started using rx-clock-source='1 # Loopback from DQS pad'. With this setting the driver did not read the data correctly anymore as it requires the correct amount of dummy cycles in the lut.

@hakehuang
Copy link
Contributor

@AndreHeinemans-NXP which platform(s) did you see issues with? This driver has been in the tree for a while so curious how you identified these needed changes. Would like to coordinate with @hakehuang to confirm CI coverage.

200M is quick challenging, let me run a regression, and feedback.

@AndreHeinemans-NXP
Copy link
Contributor Author

@hakehuang
Actually I think the driver should get the frequency from the dts. All the boards using this driver in mainline zephyr (mimxrt595_evk_mimxrt595s_cm33 and mimxrt685_evk_mimxrt685s_cm33) have spi-max-frequency = <DT_FREQ_M(200)>; specified in the dts.

I am going to make this change and lower the spi-max-frequency for the boards that require 120MHz. Depending on the results of your tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants