• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 3 answers
  • Subscribers 32 subscribers
  • Views 585 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.

AWR2944: How to reduce the time consumed by a fault injection？

Zonghu Tao
Prodigy 100 points
Part Number: AWR2944

Screenshot from the document 《AWR294x Safety Manual Functional v0.601》, as shown below:

It can be seen from the above figure that the test time is about 1ms.

In fact, when I configure the wave period to be 40ms (framePeriodicity=(40000000U / 5)), I inject a RX0 fault of RX_GAIN_DROP as shown in the figure below, and through log printing, it is found that the actual consumption is about 53ms. (229ms-176ms=53ms)

《mmWave Radar Interface Control Document Revision 3.30》

[10:31:19.349]收←◆BssFaultInject: frame end
start inject fault:0
The cpu counter is: 176ms

[10:31:19.400]收←◆BssFaultInject: frame end
RL_RF_AE_MON_RX_GAIN_PHASE_REPORT Occur
statusFlags:0x00
errorCode:0
timeStamp:46753


start inject fault:1
The cpu counter is: 229ms

[10:31:19.452]收←◆BssFaultInject: frame end
RL_RF_AE_MON_RX_GAIN_PHASE_REPORT Occur
statusFlags:0x00
errorCode:0
timeStamp:46806

Why is there such a big difference between the measured time and the 《AWR294x Safety Manual Functional v0.601》 time in the document? How can I achieve such a small time as stated in the documentation (about 1ms)?

  • 0
    TI__Guru* 91206 points

    Dear Zhonghu - 

    It seems reasonable based on your UART prints that the majority of the overhead time you see is from those. You could confirm by putting logic analyzer or o'scope on UART and measuring the time for those.   

  • 0 in reply to Josh Wyatt
    Prodigy 100 points

    I use the interface CycleCounterP_getCount32 to record the timestamp, which is more accurate.

  • 0 in reply to Zonghu Tao
    TI__Guru* 91206 points

    Zhonghu - 

    OK - sounds good - it still seems reasonable that the UART prints are the main source of the delay you see. 

  • 0 in reply to Josh Wyatt
    Prodigy 100 points

    Hi Josh

    Firstly, set the PIN to high level, and then flip the PIN level every time a fault injection is performed(Executing 29 fault injections took a total of 1.46 seconds). Use an oscilloscope to capture the following image :

    The execution time of the first fault injection(inject a RX0 fault of RX_GAIN_DROP) is 50.4ms, as shown in the following figure:

    The result is still the same, it takes a long time. How can we reduce the time for fault injection?

  • 0 in reply to Zonghu Tao
    TI__Guru* 91206 points

    Zhong - 

    I meant put o'scope or logic analyzer on the UART to measure the time for your UART prints, or just remove them or reduce what is being printed, to reduce the time - if it turns out that those are indeed correlating to the time. 

  • 0 in reply to Josh Wyatt
    Prodigy 100 points

    Hi Josh

    It should be noted that the above oscilloscope images were obtained by turning off the UART driver in the software, which means you do not need to consider the impact of UART.

  • 0 in reply to Zonghu Tao
    TI__Genius 16120 points

    I'm looping in a colleague on this discussion, please expect a response after the weekend. 

    Thanks

    E. Shareef

  • 0 in reply to E. Shareef
    Prodigy 100 points

    Hi Ehtesham

    Is there any result from this week’s discussion? Looking forward to your reply.

  • 0 in reply to Zonghu Tao
    TI__Mastermind 32665 points

    Hi,

    The fault injection API is to be issued when no frames are ongoing. The corresponding monitor for which the fault is injected should be enabled. I assume you have done these 2 steps correctly.

    Now the issue is when you issue the fault injection API that is not the exact time when the fault is injected. The fault will be injected only at the time of framing. So your measurement is not accurate in the code.

     Also remember the monitoring happens in the frame idle time only. So the detection of fault will happen in the monitoring duration only.

    The total error time is also HW plus SW time (Mbox reporting time). So, you have to take that into account as well.

    Typical test execution time is written as 1 ms and it also mentions that this depends on user programming. So, you can reduce your frame duration and remove any irrelevant calls to the BSS to further optimize your code.

     

    Thanks,

    Pradipta.