• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 551 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

IWR6843: Hardware Trigger Inconsistencies

Scott Chandler1
Prodigy 50 points
Part Number: IWR6843

I have modified a few ICBOOST boards to bring the external frame SYNC_IN signal to the SOC and modified the SOC to generate the FRAME_START signal on ball N8 (MCU_CLKOUT).

I've also sent the frameCfg CLI command to enable hardware triggering with 0msec Frame trigger delay.

When using an external high resolution PWM to generate a positive 500ns pulse at exactly 30Hz to trigger a frame start the 6843 only generates 15 frames a second.

This table shows other input (SYNC_IN) to output (FRAME_START) relationships:

INPUT (Hz) OUTPUT (frames per second)
10 10
20

20
24 24
30 15
60 20
120 24
240 24

As you can see, there is some magic that happens around 24/25 Hz. If fact if I try and narrow down exactly where the linearity breaks, the SOC stops running (I haven't debugged this as of yet), and this happens at 25 Hz. Scope shows the FRAME_START signal occasionally does not happen after the trigger signal (resulting in the output rates shown above).

As a side note, the configuration for these tests limits targets to about 8 per frame so as to allow for speedy transfer (giving a relatively high frame margin). Software triggering works as expected.

Any insights into this?

  • 0
    TI__Mastermind 23570 points

    Hello,

    Would it be possible to get a  plot or timestamp for Trigger vs framestart instances.

    Wanted to understand what is happening here and what is the chrip/frame config used.

    Thank you,

    Vaibhav

  • 0 in reply to Vaibhav Mahimkar
    TI__Mastermind 25795 points

    Scott Chandler1,

       The periodicity of the external input pulse should be always greater than the programmed frame periodic in the frame configurations in all instances. That is why you are correct results until 30 Hz then it breaks.  

    If you follow above constrain then it should be ok. 

    Thanks and regards,

    CHETHAN KUMAR Y.B.

  • 0 in reply to CHETHAN KUMAR Y.B.
    TI__Mastermind 25795 points

    Scott Chandler1,

       Please refer to below sections in the SDK documentation.

  • 0 in reply to CHETHAN KUMAR Y.B.
    Prodigy 50 points

    Hi CHETHAN KUMAR Y.B.,

    Thanks for the reply.

    I guess I need some clarification. The document states "The external pulse should be issued only after the sum total of frame trigger delay and frame periodicity". What is unclear is if the frame periodicity is the actual time it takes to transmit the pulse, perform the DPC operations, and transmit the results out, or the programed software frame periodicity.

    In my case, the actual time to process a frame (including transmission to host) is ~10ms which is small compared to 33.33ms (30Hz). Are you saying that if the software configuration is 40ms I can't send another hardware pulse even though the frame was done long ago? I assumed that if I chose hardware triggering, software frame periodicity would be ignored. Looks like this is not the case.

    If the software just has to be faster than the actual hardware, could I just configure with a software trigger of say 10ms (100Hz) then only actually trigger (hardware) at 30Hz? Or will the firmware detect that a trigger might be coming and, in the case it is not done with previous frame, assert and halt?

  • 0 in reply to Scott Chandler1
    TI__Mastermind 25795 points

    Hello Scott,

       Yes, it’s not the case, if you chose hardware trigger you cannot rely on only hardware.. but need to look at software frame periodicity constrain as well as documented in SDK doxygen section.

    Thanks and regards,

    CHETHAN KUMAR Y.B.