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.

IWR1843BOOST: IWR1843BOOST

Part Number: IWR1843BOOST

Hi,

happy with driving & collecting data via mmWaveStudio - I now want to start integrating with my other systems, so I need to use HARDWARE TRIGGER.

I see in the SDK user guide under frameCfg that only s/w trigger is allowed.  I was hoping not to have to delve too deeply into things yet - is it possible to use hardware trigger, and still use mmWaveStuiod to configure the system & collect data?

If I set h/w trigger in mmWaveStutio, it does do something: I get a frame completed message, but it doesn't seem to have actually run, as any further cfgFrame commands fail saying that they can't be done when a frame is already running - and using STOP FRAME doesn't fix it either.

thanks

Alan

  • Hello:

    Using the HW trigger requires strict timing requirements to work properly, so in general is not advised. What has been suggested in other threads is to have a GPIO tied to what generates your trigger than have that issue a SW trigger. See this thread for reference:

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/834651/awr1843boost-hardware-trigger

    Best regards,

    Connor Desmond

  • Hi Connor,

    thanks for the inof - some reading to do. Strict timing is part of what I'm trying to do - my system so far is FPGA based with timing done in a state machine, no s/w or OS latencies allowed, so my timing regime may be even stricter!

    This is looking like I'm going to have to start learning how to reprogramme bits of the system sooner that I wanted.  Is this sort of thing in BSS, RSS or MSS?  Other than MSS which I believe is TI  only, is the source and some explanation available?  I have all (I think) of SDK, DFP etc downloaded - but there's a lot to get through when starting from scratch, so any guidance for where to look would be great.

    Also I assume that changing the code is what's happening when I down load the files in mmWaveStudio, into RAM rather than FLASH ... is this the correct route for new s/w?

    many thanks

    Alan

  • Hello,

    The MSS, DSS, and HWA can be programed by the user. The BSS can only be interacted with by API calls which are called out in the Interface Control Document in the DFP package. When it comes to modifying code you will build executable files for the MSS and DSS. I assume that you have ran the OOB demo for your device. All of the code for the MSS and DSS for our provided labs are provided in the SDK as well as Industrial Toolbox. Lab specific code will be in the ITB and cross-lab code will be in the SDK e.g. drivers.

    You are free to modify the code as you see fit, but enabling the HW trigger and having it work as expected are beyond the scope of what this forum can provide. The most straight forward approach would be to use GPIO, but if you have to use a HW trigger then it will be up to you to utilize the provided collateral. There is no step by step guide to enable this. I would start be looking in the ICD in DFP package about the timings with the HW trigger as the thread I linked suggested.

    Best regards,

    Connor Desmond

  • Hi Connor,

    OK, I understand that this may get a bit too deep!  For just this sort of reason I was hoping not to have to go so far so soon ... but got to do it sometime I guess.

    What I really need for now is just to set everything up in mmWaveStudio, s/w type enable it, but the chirps/frames do not start until it gets a signal from my h/w - it can then run all of the frame/chirp set up in Studio, just as it would for a purely s/w start.  I think GPIO_1 is intended for this, and is brought to one of the 0.1" connectors, to ease physical access on the IWR.

    I assume this is not too far off your suggestion of using the h/w input to send an API command to do the start.  I'll need to look into the how the timing works out for e.g. GPIO to trigger an interrupt & this to send the API command .. and for this to be enacted.  Although I can programme delays in my h/w, I'd need to work out what these would need to be ... and hope that they're consistent each time.  This is precisely why I've done a h/w state machine for timing, so I can guarantee exactly when things happen, rather than letting a processor get in there.

    I'll leave this open for one more go in case there's anything else, then best to close it and hope I can get into all the s/w and work out how to modify it.

    many thanks
    Alan