• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 152 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TSWDC155EVM: ADC3683EVM EFUSE Reload and FPGA Export Memory Failure (Bit Mapper & Memory Write Issue)

yonggi lee
Prodigy 10 points
Part Number: TSWDC155EVM
Other Parts Discussed in Thread: ADC3683EVM, ADC3683, ADC3664, , ADC3668

Tool/software:

Dear TI Support Team,

I’m currently evaluating the ADC3683EVM and trying to integrate it with TSWDC155 reference design

While following the standard Python-based configuration flow (using adc3683evm.py and adc3683_api.py),

I encountered some issues related to EFUSE loading, memory export, and waveform visibility in HSDC Pro.

I’ve attempted several debugging steps and would like to share the symptoms, current setup, and specific questions for your guidance. Your help would be greatly appreciated.

  • What are possible root causes for intermittent efuse reload failure?
    → Could this relate to internal power/reset sequencing or timing issues?

  • If manual bit mapping is applied after efuse reload, is it possible that
    efuse re-overwrites bit mappings at a later point?

  • When the message Writing to memory failed appears during adc_export_to_memory(),
    → What exact conditions (e.g., DDR mapping, buffer size, export config) should be validated?

  • Does the TI-provided bitfile (adc3664_bd_wrapper.bit) already include DDR controller logic,
    → or do we need to instantiate and configure a MIG manually?

System Configuration

ADC: ADC3683EVM

  • Interface: 2-wire LVDS

  • Sampling rate: 40 MSPS

  • Resolution: 16-bit

  • Decimation Mode: Bypass (No DDC)

  • Python SDK: Provided by TI (adc3683evm.py / adc3683_api.py)

Issue Summary

Q1. After calling adc.config_output_mode(), the subsequent efuse_reload() call intermittently fails.
→ Sometimes the efuse_load_done flag does not become 1 (completion not detected).

Q2. After calling adc.config_output_mode(), the subsequent efuse_reload() call intermittently fails.
→ Sometimes the efuse_load_done flag does not become 1 (completion not detected).

Q3. The following error is seen in msps_server.py output:

***Exporting data to memory
Writing to memory failed

Troubleshooting and Actions Taken

  • Added time.sleep(1) before calling efuse_reload() to stabilize timing.

  • Verified bit mapper address values are correctly written for DA0/DA1 channels.

  • Enabled toggle test pattern using:

  • 0
    TI__Intellectual 1440 points

    Hello,

    Thank you for your detailed post. It looks like your post got cut off after "Enabled toggle test pattern using:". Feel free to share if you have additional information.

    To answer some of your questions:

    • What are possible root causes for intermittent efuse reload failure?
      → Could this relate to internal power/reset sequencing or timing issues?

      Yes, it is possible this could be caused by triming issues. In the API, there is a timeout for polling the efuse relaod. You can try increasing this value to see if the efuse load completes after a longer duration.

    • If manual bit mapping is applied after efuse reload, is it possible that
      efuse re-overwrites bit mappings at a later point?

      Yes, the efuse load will overwrite bitmapping.

    • When the message Writing to memory failed appears during adc_export_to_memory(),
      → What exact conditions (e.g., DDR mapping, buffer size, export config) should be validated?

      There are many causes for the "writing to memory failed" message.

    • Does the TI-provided bitfile (adc3664_bd_wrapper.bit) already include DDR controller logic,
      → or do we need to instantiate and configure a MIG manually?

      This is not a reference design, it is a bitfile that is only intended for use with the ADC3683EVM and TSWDC155EVM for the purpose of evaluating the performance of the ADC. The data is written to the memory on the TSWDC155EVM and is dumped to the PC's memory via JTAG. From there, it is saved as a .csv file and loaded into HSDC Pro for display. All of this is handled automatically by the adc3683evm.py script included in the software package.

    To help you target the cause of the issue, could you please clarify the following:

    1. Just to clarify, you are using the ADC3683EVM and TSWDC155EVM?
    2. Are you running the adc3683evm.py script as is? Or have you made some modifications, or created your own script? I would recommend we try getting things working with the unmodified script first.
    3. Have you ever been able to capture data sucessfully? Do you see the "writing to memory failed" message only when the efuse reloadd fails?

    Best,

    Luke Allen

  • +1 in reply to Luke Allen
    Prodigy 10 points

    Dear Luke,

    Thank you for your reply and clarification.

    To answer your questions:

    1. Hardware Setup
      Yes, I am using the ADC3683EVM in combination with the TSWDC155EVM.

    2. Script Usage
      I am running a slightly modified version of adc3683evm.py for debugging purposes.
      Specifically, I replaced the default bitfile with adc3668_parallel_bd_wrapper.bit to evaluate a customized setup aligned with our hardware configuration.

    3. Issue Observation
      Initially, I was able to capture data successfully right after powering on the system.
      However, after performing additional operations — including an efuse reload — the message
      "Writing to memory failed" started to appear consistently.

    To mitigate this, I inserted a delay before triggering the efuse reload, which helped stabilize the reload process to some extent.

    However, another issue still persists:
    After executing the Python script and attempting waveform capture using the High Speed Data Converter GUI, I consistently receive the following output:

    ***Exporting data to memory

    {
    'export_lane_order': [2, 1, 4, 3, 11, 10, 9, 8, 7, 6, 5, 13, 12, 15, 14, 0],
    'export_num_lanes': 4,
    'export_num_bursts': 512,
    'export_addr': 3221225472,
    'export_bitoffset': 0
    }
    Writing to memory failed

    In addition, I noticed something peculiar while testing various bitfiles provided in the msps_infra/bitfiles directory:

    • Several other EVM bitfiles function correctly and allow data capture and memory export.

    • However, the bitfile intended for the ADC3683EVM (specifically adc3683_parallel_bd_wrapper.bit) consistently triggers the "Writing to memory failed" error.

    This leads me to suspect that there may be a bitfile-specific issue related to the memory export logic or DDR interface configuration.

  • 0 in reply to yonggi lee
    TI__Intellectual 1440 points

    Hi,

    Thank you for sharing more info about your issue. The default bitfile used in the ADC3683EVM.py script is adc3664_bd_wrapper.bit. This is a bitfile that was generated for a similar part, the ADC3664. The evaluation firmware that we create is meant to be flexible and work with multiple devices in all device modes. The ADC3664 and ADC3683 are both parts with LVDS interfaces in the same device family, which is why we were able to reuse the ADC3664 bitfile for the ADC383. The adc3664_bd_wrapper.bit is the correct bitfile for the ADC3683, which we have tested and confirmed to work with the ADC3683. Please use this bitfile going forward.

    The issue you are running into is likely because you are performing the efuse reload after the fpga firmware is already calibrated. The efuse reload will change device bitmapping and timing, so if you need to perform efuse reload after calibration for any reason, you will have to reset the fpga firmware and peform the calibration sequence again. This includes putting the adc in a toggle pattern mode (0101), and peforming io calibration on the fpga.

    May I ask why you are performing the efuse reload after firmware calibration? Typically this would only need to happen once, when the adc output interface is configured. If you want to switch modes or change the adc configuration, you can simply modify the variables at the top of the script and run it again, and the script will automatically handle properly congifuring the adc and firmware in that mode.

    Best,

    Luke Allen