S32K396 QSPI timeout

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K396 QSPI timeout

810 Views
ferencvalenta
Contributor III

I'm trying to update my bare-metal S32K148 QSPI driver for the S32K396.

Clocks should be OK, MUX_0_DC_6 and MUX_10_DC_0 are enabled. LUTs are configured properly according to the new layout. MDAD/TGDAD are also configured, I can see that the IPCR register is written, the IP_ACC and BUSY bits are set in SR, and then... nothing happens! No other bits in SR/FR are set.

After quite some seconds the transaction times out. I can see the bits setting in FLSEQREQ.

The sequence I'm trying is only sending the command 0x9f on one line, reading back 8 bytes and then stop.Works on the S32K148. Did not check the signals with a scope yet.

What can be the issue that causes the timeout, what should I check? I believe, the code largely follows the flow of the "official" driver, but my hardware and the configuration can be slightly different.

Edit:

Measured with scope: signals are OK. Command goes out properly. As a test, added an address command to the LUT, that works too.

However, when I add a read command, SCK keeps running continuously, BUSY and IP_ACC remain set, and no TFF interrupt is generated. Any idea?

Tags (3)
0 Kudos
7 Replies

730 Views
ferencvalenta
Contributor III

Hi David,

Thanks for looking into this issue. Please let me know what details could help with tracking down this issue.

The board is an NXP XS32K396-BGA-DC, the MCU mask set is 0P40E. We're using ARMGCC 10 and Trace32, not the NXP toolchain. All drivers are our bare-metal implementation, not using NXP drivers. It's a non-AUTOSAR (but automotive) project.

Clocks are configured as described in the reference manual, A+ for the S32K388. Do not have the S32K396 datasheet, that's another problem. Peripheral initialization and QSPI programming are performed as described in the manual and also following the flow in the NXP drivers.

The symptoms are still the same: command and address work, SPI signals are correct, and I get the TFF interrupt at the end. All good. But when I add a read command to the LUT, something breaks. The transfer never finishes, I can see SCK running forever, even when I stop execution with the debugger. Register contents are as described above, let me know what else could be interesting. Meanwhile SCK keeps running forever (or until the timeout - actually I haven't checked whether clock stops at the timeout).

I'm now double-checking all the clocks as from other messages here I have the feeling that QSPI might not work if the ratio of the clocks is not correct. Let me know what else can I check.

Best regards, Ferenc

0 Kudos

658 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

At first I would recommend to download S32K396RM and DS. Both are available as secure file on the product webpage:

https://www.nxp.com/products/processors-and-microcontrollers/s32-automotive-platform/s32k-auto-gener...

How to get secure access you may find out here:

https://www.nxp.com/support/support/secure-access-rights:SEC-ACCESS

You may use RTD drivers also under other environment than S32DS.

0 Kudos

598 Views
ferencvalenta
Contributor III

Hi David,

Finally received the manual, datasheet and board schematics for S32K396. Unfortunately, I found nothing new that could be relevant for my issue. There are some bits in MCR that were missing from the docs of other derivatives, but no combination of settings worked for me so far.

Again, when the LUT is configured to send a QSPI command (1), address (2) and the write instruction (8), it works. If I add a read instruction (7) with either 1 or 4 pads, the BUSY and IP_ACC bits remain set indefinitely, the QSPI_SCK keeps running, and after some (quite long) time there is a timeout. The TFF flag is never set, there is no interrupt generated (timeout interrupt is not enabled for now). There is of course a stop instruction (0) too at the end of the LUT sequence.

The same driver works well on the S32K148 (of course adjusted for the different LUT layout etc...).

Since read is not working, is it possible that there is something wrong with DQS?

SOCCR=0x0e as recommended, QuadSPI_MCR_DQS_FA_SEL tested with all possible values, DQS_EN/DQS_OUT_EN all variations etc... Even configured the INTA pin and executed the pin toggling init sequence as described in the documentation to no avail. Btw I can't see that in the NXP driver. For clock init I'm using the code from the NXP example as it is. What can be wrong with my driver?

Best regards, Ferenc

0 Kudos

554 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

There is a new example for the device and QuadSPI, I believe it helps you to solve your issue.

davidtosenovjan_1-1699964928071.png

Hope it helps

 

0 Kudos

743 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

Could you provide more details about your issue? Thanks

0 Kudos

694 Views
ferencvalenta
Contributor III

Hi David,

Could you please suggest further debugging steps and describe what information could be helpful here? Spent a lot of time with experimenting but it simply does not work as expected.

Thanks, Ferenc

0 Kudos

724 Views
ferencvalenta
Contributor III

Hi David,

Provided more details in my previous comment. Meanwhile switched to using the sys_init.c as it is from the examples, so clocking issues can now be excluded.

Symptoms are the same - nothing changed. When trying to read, the QSPI peripheral locks up. Any help would be appreciated.

Ferenc

0 Kudos