TMS570LC4357: TMS570LC4357: SCI DMA RX without IRQ and variable packet lengths

Hi Surabhi,

Apologies for the delayed response!

We have one internal AI tool which can analyze all the collaterals related to this controller, i got some useful tips from it after feeding this issue.

Could you please verify whether any one of these solutions is feasible at your end?

You've correctly identified that the TMS570LC4357's DMA controller doesn't inherently support receiving variable packet lengths without some additional mechanism. Here's my analysis of your observations:

1. WCP CTCOUNT register: This does update when DMA receives bytes, but as you noted, it only updates when a new DMA trigger occurs, making it unreliable for real-time tracking.

2. Port A/B TR Count: These values reflect the planned transfer size rather than the actual received bytes count, which isn't helpful for dynamic packet reception.

3. FIFOSTAT registers: You've found these don't update during DMA reception.

Possible Solutions

Since you specifically want to avoid protocol-based approaches, here are some potential workarounds:

1. Polling-Based Solution with WCP CTCOUNT

You could implement a polling mechanism that:

• Configures the DMA for a maximum expected packet size
• Periodically checks the WCP CTCOUNT to detect when new bytes arrive
• Uses a timeout mechanism to determine packet completion

// Configure DMA for maximum expected packet size
// ...

uint32_t last_count = dmaREG->WCP[channel].CTCOUNT;
uint32_t timeout_counter = 0;
const uint32_t TIMEOUT_THRESHOLD = 1000; // Adjust based on baud rate

while(1) {
    uint32_t current_count = dmaREG->WCP[channel].CTCOUNT;
    
    if(current_count != last_count) {
        // New data received
        last_count = current_count;
        timeout_counter = 0;
    } else {
        timeout_counter++;
        if(timeout_counter >= TIMEOUT_THRESHOLD) {
            // No new data for a while, assume packet complete
            uint32_t bytes_received = MAX_PACKET_SIZE - current_count;
            process_packet(bytes_received);
            // Reset DMA for next packet
            break;
        }
    }
    // Small delay
}

2. Hybrid Approach with Minimal Interrupts

While you mentioned avoiding interrupts, a minimal interrupt approach might be more reliable:

• Configure the SCI RX with a timeout interrupt
• Use the timeout interrupt to detect end-of-packet conditions
• Keep DMA running for data transfer

3. Frame-Based Reception

If your communication allows it, you could:

• Use fixed-size frames with header information indicating actual payload size
• Configure DMA to transfer these fixed-size frames
• Process only the valid bytes indicated in the header

Recommendations

1. Most Reliable: Implement a protocol with packet delimiters or length fields, despite your preference to avoid this.

2. Next Best: Use the hybrid approach with minimal interrupts, particularly the SCI RX timeout interrupt.

3. If Constraints Prevent Above: Your approach with WCP CTCOUNT polling could work, but will be less efficient and may miss edge cases.

The fundamental limitation is that the DMA controller is designed for fixed-length transfers. Any variable-length solution will require some additional mechanism to determine packet boundaries.

--
Thanks & regards,
Jagadish.

Thank you for your response.

I find your solution "Hybrid Approach with Minimal Interrupts" interesting. Could you elaborate a bit on how to implement SCI RX with a timeout interrupt?

Also it would be good to know: How would we know the number of bytes received (or the number of bytes to copy) if the timeout IRQ was able to detect end of packet condition?

Thanks,
Surabhi