TMS570LS3137: TMS570LS3137 FreeRTOS emif access fpga

Hi Links,

Let's break down your code and the potential issues, especially considering the EMIF access to an FPGA.

Analysis of Your Code:

1. tx_cfg(): This looks like a standard setup for the RCL (Radio Core Library). RCL_Schedule_Now means the command should execute immediately. txCallback is set, but your tx_service routine uses RCL_Command_pend, which is a blocking call, so the callback might not be the primary mechanism for completion in this specific flow.

2. tx_service():

   • RCL_Command_submit(rclHandle, &rclPacketTxCmdGenericTx);
   • RCL_Command_pend(&rclPacketTxCmdGenericTx);
     • Critical Point: RCL_Command_pend will block the current FreeRTOS task until the RF command completes or times out internally. If the RF command fails or takes an unusually long time, this pend call will be the source of your delays. You are not checking the return value of RCL_Command_pend, which is crucial for understanding why it might be delayed or failing.
   • usleep(PACKET_INTERVAL);
     • Major Red Flag in FreeRTOS: usleep() is typically a busy-wait function or a very coarse delay that is not FreeRTOS-aware. In a FreeRTOS environment, you should almost always use vTaskDelay() or vTaskDelayUntil() for task delays. If PACKET_INTERVAL is 1 second (1,000,000 microseconds), usleep will block the CPU for that entire duration, preventing other tasks from running efficiently and potentially causing your observed delays if the RF transmission itself is also delayed.

Potential Causes and Solutions:

Given your description and the code, here are the most likely culprits and debugging steps:

1. Incorrect Delay Mechanism (usleep)

• Problem: usleep is not designed for FreeRTOS and can cause significant scheduling issues and CPU hogging. If the RF transmission fails or is delayed, the usleep will still add its full duration, leading to *** delays.
• Solution: Replace usleep(PACKET_INTERVAL); with a FreeRTOS-aware delay.
  • First, define PACKET_INTERVAL in milliseconds (e.g., 1000 for 1 second).
  • Then, use vTaskDelay(pdMS_TO_TICKS(PACKET_INTERVAL));
  • pdMS_TO_TICKS() converts milliseconds to FreeRTOS ticks.

2. RCL_Command_pend Blocking/Failure

• Problem: The RF command might be failing, timing out, or taking longer than expected due to various reasons (channel busy, interference, internal RF module issues, or even contention for shared resources). If pend waits for a long time, it will cause your observed delays.
• Solution:
  • Check Return Value: Always check the return value of RCL_Command_pend. It will tell you if the command succeeded, failed, or timed out.
    RCL_CommandStatus_t cmdStatus = RCL_Command_pend(&rclPacketTxCmdGenericTx); if (cmdStatus != RCL_CommandStatus_Done) { // Log or display the error status Display_printf(display, 0, 0, "RF Tx Failed! Status: %d\n", cmdStatus); // Consider error recovery or re-submission } else { // RF Tx successful }
  • Timeout: Does RCL_Command_pend have a timeout parameter? If so, use it to prevent indefinite blocking. If it times out, you know the RF command didn't complete within the expected time.
  • Asynchronous Approach: For better responsiveness, consider using the txCallback more actively. Submit the command, then the task can do other work or vTaskDelay for a short period, and the callback can signal completion (e.g., via a FreeRTOS semaphore or queue). This makes the task non-blocking.

3. EMIF/FPGA Interference (The most likely cause given your specific mention)

This is where it gets tricky. The TMS570LS3137 is a complex MCU, and EMIF access can conflict with other system operations.

• Bus Contention:

  • Problem: The RF module (RCL) likely uses internal memory and/or DMA to prepare and send packets. If the CPU or DMA is heavily accessing the FPGA via EMIF at the same time, there could be bus contention on the system bus or memory bus. This contention can delay the RF module's access to its required resources, causing the RCL_Command_pend to block for longer.
  • Debugging:
    • Isolate: Temporarily disable or significantly reduce EMIF/FPGA access. Does the RF transmission become reliable? If yes, you've confirmed the interference.
    • Profiling: Use a logic analyzer or the MCU's internal profiling tools (if available) to observe bus activity. Look for periods where both EMIF and RF-related memory accesses are high.
    • Prioritization: If you're using DMA for EMIF, ensure its priority is lower than any internal DMA used by the RF module, if possible.
    • Scheduling: Can you schedule EMIF access and RF transmission to avoid overlap? For example, complete all EMIF transfers before initiating an RF transmission.

• Memory Protection Unit (MPU) Configuration:

  • Problem: The TMS570LS3137 has an MPU. Incorrect MPU settings for the EMIF region or for memory areas used by the RF module could lead to bus errors, access violations, or unexpected behavior, especially if caching or buffering policies are misconfigured. The provided EMIF#4 document specifically mentions MPU configuration for external asynchronous memory.
  • Debugging: Review your MPU configuration carefully. Ensure that:
    • The EMIF region is configured correctly (e.g., "device" or "strongly-ordered" type as suggested in EMIF#4 workaround).
    • Any memory buffers used by the RCL (for packets, internal state) are accessible and not being inadvertently cached or buffered in a way that conflicts with the RF module's direct memory access.

• Clocking Issues:

  • Problem: While less common, if the EMIF clock (VCLK3) or the system clock is unstable or experiences glitches due to heavy load (e.g., from EMIF), it could affect other peripherals.
  • Debugging: Verify clock stability under load.

• FPGA Responsiveness:

  • Problem: Is the FPGA always ready to respond to EMIF requests? If the FPGA is busy with its own internal processing, it might not respond promptly, causing the EMIF to stall, which could indirectly affect the MCU's overall performance and resource availability for the RF module.
  • Debugging: Monitor the FPGA's status. Ensure it's not causing excessive delays on the EMIF bus.

--