[QSPI]How to define the ADATSZ for AHB buffer

[Renjun]

Hello,

We're using S32G274A to access an external NOR flash via QSPI.

There's a "AHB abort error" invoked when accessing the external nor flash via AHB. Below is the details.

To configure the BUF0CR for A53-0(AHB master), the setting of MSTRID should be 0, but we got a problem when setting the ADATSZ.

Because we don't have any ideas what's the value should be set, by trying it with several values, and we found that if ADATSZ is < 8, the "AAEF"(AHB abort error flag) will be set and it's failed to read data from the external nor flash. If the ADATSZ is >= 8, the access is ok.

So we're wondering if there's any limitations/notifications regarding the setting of ADATSZ ? And what's the principle to select a reasonable size for it ?

Thanks in advance.

[Renjun]

Got the conclusion:

The Pre-fetch size(ADATSZ) should be greater than the AHB single burst size.

As to A53-0, the AHB single burst size is 64 bytes, so the ADATSZ should be >=8(64B).

Thank you all for the reply.

[kef2]

• ADATSZ should be >=8(64B).

ADATSZ is specified in bytes, not bits, so it's not clear what you mean with >=8(64B)

Perhaps you are right regarding AHB burst. See 55.4.1.10 System Bus Configuration (SBUSCFG)

It is little cryptic. [AHB Master Interface Burst Configuration] defaults to 011, which sets [AHB master transfer type sequence (or priority)] to [INCR16 burst, INCR8 burst, INCR4 burst, then single transfer]. So default transfer is INCR16, which according to BAWR/BARD fields description is 64 bytes. 

It is told about AHBBRST that "This chip is designed to support only 011b reset value for this field. Chip operation is not guaranteed for any other programmed values.". Bus since it is R/W register, I would try what happens changing BARD and perhaps AHBBRST, along with ADATSZ. Just to make sure it is really AHB burst size related.

Regards

Edward

[Renjun]

“ADATSZ is specified in bytes, not bits, so it's not clear what you mean with >=8(64B)”

According to the CH38.4.2.5, it's multiple of 8 bytes.

The setting in SBUSCFG looks interesting. I was thinking the AHB burst type, HSIZE are not configurable. and I'm also curious if it could cover all AHB master.

I'll have a try also for A53 and eDMA.

[Renjun]

I did a try by setting the ADATSZ as 4(32B) for A53-0 plus:

a. BARD is 7, and go through all settings of AHBBRST, NOK.

b. AHBBRST is 3, and go through all settings of BARD, NOK.

Probably, it's only used for the AHB request to USBOTG.

[kef2]

• “ADATSZ is specified in bytes, not bits, so it's not clear what you mean with >=8(64B)”
• According to the CH38.4.2.5, it's multiple of 8 bytes.

Thanks. Oh yeah, ADATSZ specifies multiplies of 8 bytes. In contrast read commands arguments in LUT table arguments specify number of bytes n, user has to ensure n is multiple of 8.

[kef2]

On Vybrid I used ADASZ=0 without any problems, which is "follow data size, specified in instructions LUT table". Different instructions may use different data sizes. 

[Renjun]

Thanks for the information.

yes, the size in LUT is used indeed, but it's same question, how many bytes should be defined ?

We did a try by LUT, the number less than 64 bytes is not working neither.

[kef2]

How many bytes - should be determined practically. Each transfer reads number of bytes specified, even though you may need not all of them. But if you do sequential read, with too low transfer size you will lose your time sending extra command and address bytes for new transfer. So for sequential transfers only you should set it to maximum (limited specific QSPI implementation, I don't what it is for S32G), for execute in place (XIP) it should be something between min and max. Take into account instruction and data cache, which may be applied to QSPI address space, so I think the only way to tell best number is to test performance using different settings.

On Vybrid ADATSZ of 8 to 128 worked well, I didn't try other numbers. 128 worked best for my VF3 XIP bare metal application.

Edward

[Renjun]

Really appreciate your sharing and I do agree it.

I have to correct the question to : why the number less than 64 is not working ? I'm wondering the principle behind it. 

I guess it's limited by the burst size requested by AHB master, but not sure.

By the way, according to the reference manual, the QSPI AHB region is non-cacheable.

[kef2]

I don't know why <64 isn't working. Perhaps some chip bug? 

• By the way, according to the reference manual, the QSPI AHB region is non-cacheable.

Yes, I see it in RM. I understand it may be not cacheable on Cortex-M, which caching is usually manufacturer fixed for different address spaces. But noncacheable on Cortex-A? Really? On Cortex-A user defined TLB defines which areas are cacheable and which not.

Edward

[bpe]

The recommended value for ADATSZ is the buffer size, BUFxCR[ADATSZ] = BUFxIND[TPINDX]

S32CT gives you actually no choice:

Here is how RTD code does it:

You can find the theory in S32G2RM, Section 38.6.2.2.

Hope this helps,
Platon

[Renjun]

Thanks for the reply.

Actually, the issue came with the configuration from RTD(same with your snapshot).

And then, we did try by the different value of the ADATSZ, because we assumed the buffer0 was "hit" by A53-0, and the size is problematic.

One more information, if we only changed the master ID of buffer0 to a number except "0", everything is fine.