• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 11 subscribers
  • Views 420 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.

Cascade 2243 receives AWR_AE_RF_CPUFAULT_SB signal

han feng
Prodigy 50 points
Other Parts Discussed in Thread: AWR2243

We used 4-chip cascaded 2243 hardware designed by ourselves to collect data. Now during long-term operation, we found that 2243 suddenly did not send data after running for a period of time (we have used an oscilloscope to confirm that 2243 does not send data, and the trigger signal received by 2243 is normal) . Check the program log and find that 2243 sends an asynchronous signal and reports an error. The signal type is AWR_AE_RF_CPUFAULT_SB. The specific error is as follows

FAULT_TYPE is 0x03

ERROR_CODE is 0x01

LINE_NUM is 0x07fd

FAULT_LR is 0x453c

I want to know why 2243 suddenly issued this error report, and how can we locate and troubleshoot this problem?

  • 0
    TI__Guru*** 149014 points

    Hi,

    Please give us some time to review this with the design team

    thank you

    Cesar

  • 0 in reply to Cesar
    TI__Guru*** 149014 points

    Hi,

    Can you please provide this additional information

    • If you re-start the system, does this issue happen after long-term operation for the same SW?
    • Does this happen always with the same sensor
    • Does this happen on several boards?

    This will help us understand if the issue is related to a single sensor/board

    Thank you

    Cesar

  • 0 in reply to Cesar
    TI__Guru*** 149014 points

    Hi

    I have some additional questions from the design team:

    • does the system use software or hardware trigger?
    • does the error happen on the master or salve devices? If slave, is it happening on all slaves or only one of them?

    Thank you

    Cesar

  • 0 in reply to Cesar
    Prodigy 50 points

    I'm sorry for the late reply.

    The system use hardware trigger,use fpga to provide 10hz trigger signals for master and slave devices.

    Once the failure occurs the master device, as well as all slave devices will be.If the device is re-powered and then re-run the device, the problem still occurs probabilistically after a long period of operation

    As it stands, there are a few fixed devices that experience the problem frequently, but there are others that have never experienced similar failures.

    Thank you

  • 0 in reply to han feng
    TI__Guru*** 149014 points

    Thank you for this additional information.

    Let me check with design team and get back to you

    Cesar

  • 0 in reply to han feng
    TI__Guru 69960 points

    Hi Han,

    I see that HW trigger pulse is provided by the FPGA.

    Could you probe to this HW trigger line and check if interval and width of pulse is constant across for long enough time period (until you get this error msg from AWR2243)? Try to probe this line very close to AWR2243 boundary.

    Are you using single point of HW trigger from FPGA to all AWR2243 devices? Wiring from FPGA to AWR2243 are same and short (in length)?

    .

    Regards,

    Jitendra

  • 0 in reply to Jitendra Gupta
    Prodigy 50 points

    I confirmed our hardware design, and the way the HW triggers the wiring to the 2243 is exactly the same as the TDA board, and the wires to the 2243 are of equal length. Also, we measured the quality of the trigger signal and it is normal, the pulse width of the trigger signal is also fixed without change. Only the period of the trigger signal has not been determined yet, and there is a possibility that it is above/below the set value.
    Is it possible to localize the problem?