S32R45 SptEcsIsrCb error!

[sinetech]

Search for the cause of the alarm is "AXI Read Error In PDMA." What reasons could cause this alarm?

SPT Error queue overflow! Only the first 10 errors are reported. Check last executed kernel!
SPT done
SptEcsIsrCb error!, Status: 0x11005, Error info: 0x10000
SptEcsIsrCb error!, Status: 0x11005, Error info: 0x10000
SptEcsIsrCb error!, Status: 0x11005, Error info: 0x10000
SptEcsIsrCb error!, Status: 0x11005, Error info: 0x10000
SptEcsIsrCb error!, Status: 0x11005, Error info: 0x10000
SptEcsIsrCb error!, Status: 0x11005, Error info: 0x10000
SptEcsIsrCb error!, Status: 0x11005, Error info: 0x10000
SptEcsIsrCb error!, Status: 0x11005, Error info: 0x10000
SptEcsIsrCb error!, Status: 0x11005, Error info: 0x10000
SptEcsIsrCb error!, Status: 0x11005, Error info: 0x10000
RsdkSptRun done. SPT processing done. Ready for next kernel.

[petervlna]

Hello,

Here are possible causes:

1. Mismatch Between SPT Input and S32DS Input

SPT kernel input did not match the expected S32DS configuration.

PDMA reads memory at addresses determined by the SPT kernel’s configuration. If buffer dimensions, cube base address, or channel count don’t align, PDMA may attempt to read invalid or unexpected memory locations → AXI read error.

2. Incorrect or Corrupted Work Register (WR_x) Configuration

If PDMA uses a work register pointing to an invalid or misconfigured buffer, the AXI fabric receives illegal read requests → triggers a bus error.

https://community.nxp.com/t5/Other-NXP-Products/SPT3-1-1024-128-16range-don-t-work/m-p/1621567

3. Synchronous vs. Asynchronous PDMA Execution Mode

.sync → .async

In .sync mode, PDMA waits for a condition that may never be met due to misconfiguration (e.g., buffer pointers, dependencies).
This can accumulate error flags and produce AXI errors if the PDMA engine attempts repeated invalid reads.

4. Wrong Data Width or Format (e.g., WR_16 vs WR_11)

If the PDMA expects 16‑bit complex data but the target register/buffer is configured for a different width/layout, AXI read bursts may misalign → protocol error → AXI Read Error.

5. AXI Protocol‑Level Errors (General Causes)

Even though not specific to S32R45, AXI read‑error mechanisms apply universally:

• Invalid burst length or size
• Attempts to read from unmapped or protected addresses
• Slave timeout or non‑responsive target
• Read response errors (SLVERR or DECERR) due to upstream issues

If PDMA generates malformed AXI transactions, the AXI interconnect will return SLVERR, which shows up as a PDMA read error.

Most Probable Causes in Your Case
Based on both your logs, the top suspects are:

1. Wrong WR_x register (especially WR_5 / WR_16 selection)
   Very commonly misconfigured and leads to invalid AXI read.
2. SPT kernel input mismatch with S32DS input
   Often overlooked and validated as the root cause in previous cases.
3. PDMA sync mode causing dependency deadlock
   Try switching .sync → .async for debugging.

Best regards,

Peter

[sinetech]

Hello peter,

After doubling the number of waveform sampling points in the radar front-end, the error no longer occurs, but the chirp buffer size has not changed. Please help analyze the issue further. Thank you very much.

[petervlna · Accepted solution]

Hello,

Likeliest root cause in your scenario:

1. Stride/alignment mismatch between the kernel’s expected chirp pitch and the actual buffer layout—doubling samples aligns the burst size and masks the bug. 
2. WR_x selection / data width mismatch (real vs complex, 16‑bit vs other), corrected by chance when the sample count changes.
3. Param order/type mix‑up in kernelParList (ADDR vs VALUE), only manifesting for certain sizes. The mirror thread shows a similar param sequence; it’s easy to slip an index.
4. WR 24‑bit offset edge that disappears with a different packing/layout after doubling

Best regards,

Peter

[sinetech]

Hello Peter,

thank you very much for your reply.

Following the reasons you listed, I have carefully checked the code, with a particular focus on

WR_5, and did not find any issues. Moreover, I have not modified the SPT kernel code.

code initial list:

AppMemAllocBuffer(pHeapMem, &gSdadcSampleBufferBufH[index], sizeof(uint16_t) * RSDK_SPT_RANGE512_4CH_IN_BUF_SIZE,

                          RSDK_SPT_DATA_ADDR_ALIGN_BYTES, RSDK_OALMEM_CHUNK_ID_CBRAM);

RelocSptCode(gSptModuleCodeRelocBufH.virtAddr, RsdkSptRange512smp128crp4ch, RSDK_SPT_GET_KERNEL_SIZE(RsdkSptRange512smp128crp4ch));

np = 0;

sptContext.kernelParList[np].paramType = RSDK_SPT_PARAM_TYPE_ADDR;

sptContext.kernelParList[np++].paramValue =(uintptr_t)gSdadcSampleBufferBufH[0].phyAddr;

sptContext.kernelParList[np].paramType = RSDK_SPT_PARAM_TYPE_ADDR;

sptContext.kernelParList[np++].paramValue = (uintptr_t)gRadarCubeResultsBufH.phyAddr;

sptContext.kernelParList[np].paramType = RSDK_SPT_PARAM_TYPE_ADDR;

sptContext.kernelParList[np++].paramValue = (uintptr_t(gFft512TwiddleFactorsBufH.phyAddr);

 sprintf(fileName, "%s%s", FILE_IN_PATH, "fft512_twiddle_factors.dat");

/* RSDK data is stored in files big-endian format for compatibility reasons with PPC architectures     Endianess conversion is done ONLY for reading and writing data to/from files. No transformation is necessary in the processing flow.*/

DbgReadFileConvert(fileName, 0, (char *)gFft512TwiddleFactorsBufH.virtAddr, gFft512TwiddleFactorsBufH.numBytes, ENDIAN_CHANGE, DATA_BUFF_IS_CACHED);

sptContext.kernelParList[np].paramType = RSDK_SPT_PARAM_TYPE_ADDR;

sptContext.kernelParList[np++].paramValue = (uintptr_t)gFft512BlackmanWindowBufH.phyAddr;

sprintf(fileName, "%s%s", FILE_IN_PATH, "fft512_win_blackman.dat");

DbgReadFileConvert(fileName, 0, (char *)gFft512BlackmanWindowBufH.virtAddr, gFft512BlackmanWindowBufH.numBytes, ENDIAN_CHANGE, DATA_BUFF_IS_CACHED);

sptContext.kernelParList[np].paramType = RSDK_SPT_PARAM_TYPE_VALUE;

sptContext.kernelParList[np++].paramValue = 3; /* no output shift */

sptContext.kernelParList[np].paramType = RSDK_SPT_PARAM_TYPE_LAST;

PRINT LIST:

gSptModuleCodeRelocBufH.phyAddr: 0x34000000

gSdadcSampleBufferBufH[0].phyAddr: 0x28000000

gSdadcSampleBufferBufH[1].phyAddr: 0x28003000

gSdadcSampleBufferBufH[2].phyAddr: 0x28006000

gSdadcSampleBufferBufH[3].phyAddr: 0x28009000

gRadarCubeResultsBufH.phyAddr: 0x34002000

gFft512TwiddleFactorsBufH.phyAddr: 0x340bd000

gFft512BlackmanWindowBufH.phyAddr: 0x340bf000