TMS570LC4357: emif 32bits access produce one 16bits access, debug?

Hi Marvin,

I never see this issue before.

However, we have one internal TI AI tool which can access all the old e2e data base and also can access all the documents related to this device, when i use this tool i got some good suggestions. Could you please check them once:

Based on the information from e2e.ti.com and technical documentation, I can explain the behavior you're experiencing with your TMS570LC4357 EMIF configuration.

Root Cause: Dataline Buffer and 64-bit Alignment

The issue you're encountering at offset 0x8 is related to the EMIF dataline buffer behavior and 64-bit alignment boundaries. Here's what's happening:

(1)The TMS570LC4357 EMIF uses a dataline buffer that operates on 64-bit boundaries. According to the technical documentation:

"Any 16-bit or 32-bit read which misses the dataline buffer initiates a 64-bit access to the EMIF and stalls the CPU until the four 16-bit access completes and refills the buffer (on a 16-bit SDRAM or ASRAM). This means that sequential accesses have better performance."(1)

"The width of line buffer is 64 bits and has an associated valid bit (Vx) and address tag (ATAGx). ATAGx is a 64-bit aligned address of the data being held in the dataline buffer."(1)

Why Offset 0x8 Behaves Differently

Your access pattern is:

• Offset 0x0: Works correctly (within first 64-bit buffer line: 0x0-0x7)
• Offset 0x4: Works correctly (still within first 64-bit buffer line: 0x0-0x7)
• Offset 0x8: Fails on first read (crosses to second 64-bit buffer line: 0x8-0xF)
• Offset 0x8 (second read): Works correctly (buffer now populated)

The first access to offset 0x8 crosses a 64-bit boundary, causing a buffer miss. The incomplete 16-bit access you're observing is likely due to the buffer management logic attempting to handle the boundary crossing.

Registers to Inspect

1. PMCR (Peripheral Memory Control Register) - 0xFCFFE818

   • Your current value: 0xC4600301
   • Bit fields to verify:
     • Bits [31:30]: Data bus width (should be 10b for 32-bit)
     • Bit [8]: SS (Select Strobe mode) - you have this enabled

2. ASYNCWAIT Register - 0xFCFFE804

   • Your current value: 0x000000FF
   • Maximum wait states configured

3. Memory Dataline Buffer Configuration (if accessible)

   • Check if dataline buffer is enabled for your CPU
   • Register address varies by device configuration

Recommended Solutions

Solution 1: Disable Dataline Buffer for EMIF Region (Preferred)

Configure the MPU (Memory Protection Unit) to mark the EMIF CS4N region as a peripheral region where reads are not buffered:

// Configure MPU region for EMIF CS4N space
// Set memory attributes to disable buffering
// TEX=0, C=0, B=0 for strongly-ordered/device memory

This ensures that "reads are not buffered in DLB" for peripheral space(1), preventing the buffer alignment issues.

Solution 2: Adjust Access Pattern

Ensure your first access aligns with 64-bit boundaries:

• Start reading from offset 0x0, then 0x8, 0x10, etc.
• Or perform a dummy read to populate the buffer before your actual read

Solution 3: Add Memory Barriers

Insert memory barrier instructions (DSB/DMB) between accesses to ensure completion:

__asm(" DSB");  // Data Synchronization Barrier
// Perform your EMIF read
__asm(" DSB");

Solution 4: Verify Timing Parameters

Your PMCR configuration (0xC4600301) should be verified against your external device timing:

• R_SETUP, R_STROBE, R_HOLD
• W_SETUP, W_STROBE, W_HOLD
• TA (Turnaround time)

The incomplete access might also indicate timing issues during the buffer refill operation.

E2E Thread Reference

Your exact issue was discussed on e2e.ti.com: (1) https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrolle

The thread confirms this is a known behavior related to dataline buffer management across 64-bit boundaries.

--
Thanks & regards,
Jagadish.