IWR1843BOOST: IWR1843BOOST

Hi Alan,

We're working on getting an answer to you. Thank you for your patience.

Best,

Nate

Alan Milne said:

> create new  (lower priority) task AFTER the one that runs OK - new task does NOT run (no action, break point on task is never reached)

This seems like correct behavior. You'll need to pend on the higher priority tasks in order to reach a lower priority task.

Alan Milne said:

> create the new task BEFORE task that works ... new the new task runs, but now the original does not.

Could you perhaps share some small code snippets showing the task you've created? Please do not send entire files or projects. We will not review large blocks of code.

Alan Milne said:

I note that the MmwDemo_initTask doesn't explicitly have a PRIORITY set.  Does this imply that MAIN - and perhaps TASKs created in there - have highest priority?

From the BIOS user guide : "If NULL is passed instead of a pointer to an actual Task_Params struct, a default set of parameters is used"

You can put the device in debug mode to read the task priority.

Best,

Nate

Hi Nate,

correct behavior - don't quite understand, based on what I think TI code does...

MAIN starts INIT as a task, which then starts several other tasks in sequence, e.g. CLI mmWaveCtrl & DPM.  My task CREATEs just follow after this, and it seems that whichever one I put first works, but the second doesn't.  Looking at say the CLI code, this has a while(1) to wait for input - I don't see anything about PENDing this task, yet all the tasks I can see being started by MAIN & INIT do seem to be running together, along with one of mine (but not both, so far).  Perhaps this is the root of the problem - I've got something missing from my task implementations?

My tasks are very similar: while(1) waiting for something to happen.  One waits for GPIO_1 to go high, then does a little house keeping, then starts continuous mode (for my research).  The lower priority one waits for a flag, which is set inside the chirpAvail ISR.  This code looks like:

void sampleCollect_samplingBlockServerTask ()
{
while(1)
{
    System_printf("\nsampleCollect_samplingBlockServerTask\n");
    if(gMmwMssMCB.sampleCollectCfg.samplingDoneFlag)
    {
        System_printf("\nsampleBLOCK done chirpAvailCounter> 0x%x\n", gMmwMssMCB.sampleCollectCfg.sampleCollectChirpAvailCount);

        //clear flag
        gMmwMssMCB.sampleCollectCfg.samplingDoneFlag = false;

    }//end of "if(gMmwMssMCB.sampleCollectCfg.samplingDoneFlag)"
}//end of "while(1)"

}// end of "sampleCollect_samplingBlockServerTask"

This is just in "lets get something working" form for now.  A simple extension to the ISR, where printf doesn't seem to work.

For completeness, my chirpAvail ISR simply counts a number of adcBUF filling events, then stops continuous mode and sets the samplingDoneFlag .... and all seems to work fine in itself, just I can't get the TASK (above) to run along with everything else.

Should there be something extra inside the TASK code?

thanks

Alan

Hi Alan,

What priority is this task set to? If it's high priority it may just stay in that while(1) loop. How are you creating these tasks?

You also say:

Alan Milne said:

The lower priority one waits for a flag, which is set inside the chirpAvail ISR

The code you've provided below waits for a flag, but no other code can execute in the meantime (unless its higher priority). Do you mean to pend here instead of the while(1)?

Best,

Nate

Hi Nate,

my task priorities are set as:

#define MMWDEMO_CLI_TASK_PRIORITY                                                 4 //3
#define MMWDEMO_DPC_OBJDET_DPM_TASK_PRIORITY                     5 //4
#define MMWDEMO_SAMPLECOLLECT_EXTSYNC_TASK_PRIORITY     2 //2
#define MMWDEMO_SAMPLECOLLECT_BLOCK_TASK_PRIORITY         3 //2
#define MMWDEMO_MMWAVE_CTRL_TASK_PRIORITY                           6 //5

as you can see, I've been trying a few combinations!

I think we may getting closer to my problem - great thing about talking to someone about it.  I think there are two parts I'm not understanding:

1)

maybe WHILE(1) is the wrong construct for what I want to do - you mention PEND, I'll need to read up on that & how its used - I don't think I've seen it in the OOB_DEMO code, to have an example.  It certainly seems to make sense that when a higher priority task starts, it stops everything else running until its done ... which a while(1) will never do.

{really, my extSync task, waiting for GPIO_1, needs to be an interrupt.  I'm doing it in a TASK for now, as I can get the rest of the code around it working. without the next layer of learning i.e. how to implement hard ward interrupts.  And I can learn about how TASKs work}

2)

In that case - this doesn't seem to match what I see actually happening, unless there's something in how its set up that I haven't grasped.

At run-time, it would appear that I have CLI, the DPM control, talking to BSS and my extSync task all running - seemingly concurrently, yet with a WHILE(1)  format in their code (e.g. CLI waiting for serial character to arrive).  I say this because it all works i.e. I can make things happen via GPIO_1, I can talk to it over the CLI and, as it appears to do something (I can't guarantee it actually produces signals, but it does produce chiprAvail interrupts, under my control), so talking to BSS is presumably working too. So, all these tasks appear to be running at the same time, I can repeat commands (CLI or GPIO) as often as I like, so no task seems to have completed - they're all still inside while(1).

Yet, when I try to add my TASK to do more when the chirpAvail ISR  asks it to, I can only get one of my tasks to run.

If any of these tasks took priority, then how can it be that they appear to all work at the same time (at human speed, at least, if not actually all executing at exactly the same time)?  The BIOS doc does say something about being able to set to run many tasks, each in turn, rather than one taking precedence - but I can't see if that is being used by the code i.e. to have an example to look at. Maybe that's what's happening?

OK, hopefully that may help you see what/where I have a lack of understanding of how tasks work.

many thanks

Alan

Hi again Nate,

more work, perhaps a bit more understanding!

Watching what the code does, I can see that some things happen after the MmwDemo_CLIInit call.  Now, although this is done as a TASK - this one DOES complete (the while(1) bit I was thinking of must be somewhere else in the CLI workings).

That seems to make more sense now - drops through that bit of CLI and goes on to start my first (whichever way round I've got them) TASK, which then grabs all the processing because of its while(1).

If, on top of this, the other TASKS set up in MmwDemo_initTask then work via being HW interrupts (high priority), then this would all hang together nicely.

Does that lot sound about right? In which case, I may be starting to understand how TASKS & their usage in oob_demo!

thanks

Alan

Hi Alan,

How do you see the CLI task completing? As far as I can tell, it simply gets pre-empted by higher priority tasks that kick off once the sensorStart command is sent. See the documentation in 

C:/ti/mmwave_sdk_03_06_00_00-LTS/packages/ti/demo/xwr68xx/mmw/docs/doxygen/html/index.html

Perhaps we can find an alternate way of accomplishing what you want here without creating another task. What do you want to make another task on this device to accomplish?

Best,

Nate

Hi Nate,

lots of layers in the s/w...

In MmwDemo_initTask, it calls MmwDemo_CLIInit, which doesn't, itself, have a while(1).  However, this calls CLI_open which in turns starts CLI_task ... which is where the while(1) is.  Got it.

Nearly understand all that - final part is: when CLI_task is priority 4, how do my priority 2 or 3 task start at all?  What I see is that the code goes through MmwDemo_CLIInit, then moves on to start my task (which is why I though it was completing).  Why doesn't this stay in the priority 4 CLI_task?

As for why I need to add another task - it's to off load various other jobs from inside the chirpAvail ISR. 

As you know - I've got another question going re Hwi & Swi.  Now I've got the Hwi working for GPIO_1 to be my external sync, I don't need that task anymore ... it was only a step along the way.  The "new" task (snippet I sent) is just to clean up the ISR - and also allow me to have some debug printf's, which don't seem to work inside an ISR.  Now, I can get this last task to run (simply don't start the extSync one) .. but its not responding as I want it yet - but I think that's a different issue, as at least the code round about all runs.

When I get it sorted (other question) - I guess posting a Swi would be the better answer than a TASK - so the entire problem goes away, apart from me learning about TASK.

In which case, we're nearly ready to close this question - if I can understand how the code continues after MmwDemo_CLIInit, when it heads for a while(1) in CLI_task, then we're there.  Is it as simple as the MmwDemo_initTask  task has a higher priority that the CLI_task?  It's not specifically set in MAIN, where its called - maybe the default setting is higher priority?

many thanks

Alan