• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 386 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.

IWR1843BOOST: IWR1843BOOST

Alan Milne
Intellectual 285 points
Part Number: IWR1843BOOST

Hi,

working around the studio_CLI s/w and looking at continuous mode:

studio_CLI has been very useful!  I have almost all I need working, but have a question - which leads to a problem.

I have a TASK which waits for GPIO_1 to go high, to use as an external trigger.  This all works fine, but I need to start/stop continuous mode (or enable/disable chirpAvail interrupts?) from within this task, to control data collection.

Firstly: what code do I use for this: In studio_CLI MSS code I can see these functions:

in: MmwDemo_dataPathOpen
//start continuousMode
gMmwMssMCB.adcBufHandle = Mmw_ADCBufOpen(gMmwMssMCB.socHandle, 1);
and
//stop continuous mode
gMmwMssMCB.adcBufHandle = Mmw_ADCBufOpen(gMmwMssMCB.socHandle, 0);

in: MmwDemo_startSensor
retVal = MmwaveLink_ContMode(1);
and presumably
retVal = MmwaveLink_ContMode(0);

in: MmwDemo_dataPathStart
ADCBuf_control(gMmwMssMCB.adcBufHandle, ADCBufMMWave_CMD_START_CONTINUOUS_MODE, \
(void *)&gCLICmdCfg.cliCtrlCfg.u.continuousModeCfg.dataTransSize);

However, when I try to use these inside my TASK, it crashes:

Exception occurred in ThreadType_Task.
Task handle: 0x8006cd8.
Task stack base: 0x8006d38.
Task stack size: 0x800.
R0 = 0x00000000 R8 = 0xffffffff
R1 = 0x00000005 R9 = 0xffffffff
R2 = 0x00000000 R10 = 0xffffffff
R3 = 0xe59ff018 R11 = 0xffffffff
R4 = 0x0800d820 R12 = 0x00000000
R5 = 0x00000000 SP(R13) = 0x08007508
R6 = 0x00000001 LR(R14) = 0x00017e5f
R7 = 0xffffffff PC(R15) = 0x00010318
PSR = 0x000c019f
DFSR = 0x0000000d IFSR = 0x00000000
DFAR = 0xe59ff01c IFAR = 0x00000000
{module#44}: line 205: error {id:0x1a0000, args:[0x10318, 0x17e5f]}
xdc.r

So - what is the correct method for controlling continuosMode, from within the TASK ?

many thanks

Alan Milne

  • 0
    TI__Genius 17265 points

    Alan,

    Can you elaborate on what your goal is? Continuous Wave (CW) Mode does not produce meaningful data, and is primarily only intended for antenna testing and certification purposes. It seems that you are trying to use CW mode as part of your actual implementation, which I don't think we have much relevant experience with.

    Best Regards,
    Alec

  • 0 in reply to Alec May
    Intellectual 285 points

    Hi Alec,

    actually, no, I can't elaborate!  This is  a research project, and I need to protect my IPR ... if it works.  It's a case of doing things one bit at a time - I need to start with a CW signal and then, if that works out, add back in the traditional radar functionality.  If I'm right about what I'm trying to do, then there IS information in the returning CW signal, but I need to remove the extra dimensions of sweeping etc etc to do the research.

    I guess my question has two parts:

    • how do I / what is the correct way to start & stop continuous mode from within my TASK
    • what is the error I'm getting telling me ... have I done something wrong in how I've set up the task (maybe not enough stack?)

    The second part is hopefully the easier to answer, as this is more about TIros and how to do things in it; the first one may be more of a problem - as I'm trying to do something with the device that it wasn't originally designed to do.  However, if I can do it - this could add whole new markets, where no one would have though of using a radar device ... hence why I say much about what I'm actually trying to do, as this is the "sharp end" of my (potential) innovation.

    many thanks

    Alan

  • 0 in reply to Alan Milne
    Intellectual 285 points

    Hi Alec,

    I think I've found what's behind the crash & error message!  Although it was looking like it depended on where in the code the  start-contin-mode command was placed, this isn't what's wrong.  Its actually much simpler, and is just that I hadn't started the sensor yet - so it was probably allowed to get upset.  Now, somewhere along the way, I've seen an example of code which doesn't require a profile.cfg file to be downloaded to start things, so that ought to have the answer to how I should get the sensor started from within my code - and then I should be able to use continuous mode etc.

    That just leaves a need to check on the exact code I do use when running contin mode: what I need for configuration (guess dataPath & adcBuf etc), and what I ought to use to start/stop under program control.

    many thanks

    Alan

  • 0 in reply to Alan Milne
    TI__Mastermind 23037 points

    Hello Alan,

    Glad to hear you have gotten progress. Unfortunately as this is something we have never done at TI, the most we can do is provide you with the link to the mmwavelink test code which is at mmwave_sdk_03_06_00_00-LTS\packages\ti\control\mmwavelink\test

    Best Regards,

    Pedrhom

  • 0 in reply to Pedrhom Nafisi
    Intellectual 285 points

    Hi Pedrhom,

    thanks - I know I'm perhaps a rather unusual user of your technology, in that I'm using it to make a research tool i.e. to do something the original designer's hadn't thought of using it for.  I guess the time has come where I'm departing from "normal usage" enough to make it difficult for you to help.

    I'll close this thread now - but just to pass back some info, in case anyone else asks about this:  in a previous thread (talking to Jackson), I was looking at the adcBuffer, and how I access it re the ping/pong buffering scheme.  I thought (completely wrongly, I've now found out), that I'd need to read from separate addresses for ping & pong, and couldn't see how I got this information.  SWRU622e, sect 13 isn't at all clear on this, and is why I thought what I did.  However, I happened to find SWRA555a - fig 2 tells me everything, and its much simpler that I thought ... all the ping/pong mapping of "numerical" address to physical memory location is done inside the adcBuf h/w.  It might be nice if that fig 2 or something similar was added into 522 at some future update.

    many thanks

    Alan