IWR1843BOOST: IWR1843BOOST

Hi Alan, 

Thanks for the post! Please let me digest this and get back to you with more information in the next couple of days. 

Best Regards,

Josh

Hi Josh,

looking a bit further, I've realised something that may help - and that I hadn't included in the info I sent before.

As a test case, I'm collecting sets of 4096 ImRe samples from adcBuf into L3 - and in this case, I'm recording 20480 samples, so 5 sets.  Interestingly, the difference I see when counting chirpAvail interrupts and EDMA completions is a factor of five,  I've checked this with other numbers & seems to hold up.

So, something is doing what it should i.e. the edma completes when its collected all the sets, each of which needs a chirpAvail to start.

This answers that I've got the edma set up reasonably correctly, and it matches (in number of occurrences) with the chiprAvail  interrupts.

>> It looks like there are just many more chirpAvail events being seen in DSS compared to MSS (which is always as I'd expect - the number of blocks).

Question 3: am I using the correct values in DSS for chirpAvail going to ISR & edma? Something must at least match up between the ones I've used, hence the correct relationship (how many sets I collect) between the counts in ISR & edma.

Other info: I've finally managed to get more budget, so I now have a second IWR, to use as another Tx/Rx chain.  Thus, I can now see that it does indeed manage to collect the correct number of samples (and they're contiguous, which is what I need).  The problem is in the DSS counting to keep everything in step, with seemingly two things that I can't explain:

>>why more events seen by DSS than MSS

>>in the EDMA, it looks like its sort of doing what it should - except that it's carrying on taking blocks (bCount) in response to the extra events, but is not actually transferring any data, except once - the data in memory looks OK. However, as it's continuing, it's keeping control of memory access, so my own DSS code looks like it doesn't do anything ... unless I put in a pause via a break point (I've tried a long do-loop as a delay, that doesn't seem to help).

Hope that might help tracking down what the problem is.

many thanks

Alan

and a bit more...

DSS does, on one level, do the right things i.e. simple count of chirpAvail interrupts & EDMA complete callBacks do line up e.g. ten counts in the ISR gives one edma completion.  The actual total numbers seen also depended on the counts calling (via SWI-post, in case that's significant) my other DSS code which, when its done, resets the EDMA.  Take that bit out, and the counts go higher still.

Thus, it look like DSS is doing what it should, except that it reports the chirpAvail ISR is being entered far more often that MSS reports there have been interrupts from BSS.

I'm setting up the DSS ISR using the SOC_registerSysIntListener format, copied from MSS.  There isn't a similar construct in the oob_demo DSS to copy ... and I want the code to be as direct (i.e. NOT via any operating sys calls) as possible, to control timing & latencies - so maybe I'm breaking the rules expected by the DPM/DPC etc format - and so need to do something more?

>>do I need to be doing something to e.g. acknowledge the chirpAvail in DSS?  Otherwise, how can I be reporting more interrupts in DSS than MSS?

many thanks

Alan

Hi Alan, 

Thanks for the additional info. I'm still looking into this. You can expect an update by the end of the day tomorrow. Your patience is appreciated.

Best Regards,

Josh

Hi Josh,

this still looks difficult to understand what's happening in DSS.

I've tried things like reducing the count in MSS (i.e. MSS code stops contMode, so should stop chirpAvail interrupts - which MSS  chirpAvail ISR always counts correctly).  Even with this, the EDMA says its completed, despite MSS saying it hasn't generated enough chirpAvail events for this to be true.

As I understand it, I simply use the correct EDMA channel, make it eventDriven, and that should be it?  I'm using:

.hwRes.edmaCfg.dataInPing.channel = DPC_OBJDET_DPU_RANGEPROC_EDMAIN_CH;
#define DPC_OBJDET_DPU_RANGEPROC_EDMAIN_CH EDMA_TPCC0_REQ_DFE_CHIRP_AVAIL
#define EDMA_TPCC0_REQ_DFE_CHIRP_AVAIL (9U)

and edma 9 looks to be correct from the tech ref document 522e.

That seems to be one connection between DSS & MSS, the one for DSS listening for chirpAvails is SOC_XWR18XX_DSS_INTC_EVENT_CHIRP_AVAIL.

I assume these are all meant to be "connected" to the same thing, and the events have exactly the same meaning in MSS and DSS?

I don't think I can do the data saving entirely in MSS - according to the tech ref it can't see all of L3 memory, so I think I still need to solve this problem.

thanks

Alan

Hi Alan,

Sorry for the delay.
From the information you have posted I do not see any immediate issues. You are correct that both SOC_XWR18XX_DSS_INTC_EVENT_CHIRP_AVAIL and EDMA_TPCC0_REQ_DFE_CHIRP_AVAIL should be used based on the TRM and OOB demo.

Unfortunately, I still don't have any answer as to why you are seeing more chirp available events in the DSS compared to MSS but please bear with me as I ask around a bit more. I will update you in the next couple days.

Best Regards,
Josh

Hi Josh,

at least I may have got something right, then!

This all comes from having a second IWR, so I can look at actual signals as they progress through the system - so I can now see that things that looked like they were running Ok, aren't in fact doing what it seems e.g. looking at breakpoints says the code is accessed, but the data isn't correct.

>> Can you confirm that my supposition is correct: even though my DSP seems to run, the data is wrong - and this is because the EMDA is running when I think it's finished, and takes priority over (L3) memory, so the DSP can't write its results?

>> similarly to do with the EDMA, event triggered: it shouldn't do anything except via the event, and once bCount reaches zero, it completes - does it then STOP until reset, or can it carry on in some way?  I have bCount reload set to zero, but I'm not convinced it's stopping (although that may just be due to the apparent excess of chirpAvail events).

If I fiddle the execution via breakpoints, so that (by elapsed time, or some other interaction) the EDMA has really completed, I can see that my actual DSP seems to be working fine - so I just need to sort out this problem and I should be about there.  That is to say I've got the technology to implement my research - lots more to do after that!

many thanks

Alan

Hi Alan, 

I apologize again for the delay. I think the behavior you are seeing from the EDMA is likely related to the excess chirp available events you are receiving. We still do not know exactly why this is happening but I want to recommend you to take a look at/try running the medium range radar demo (mrr) from the Radar Toolbox. The mrr demo counts chirpAvail events from the DSS side and uses them to control processing similar to what you are trying to accomplish. Can you please check dss_main.c located at {RADAR_TOOLBOX_INSTALL}/source/ti/examples/ADAS/medium_range_radar/src/1843/dss/ and compare the way you are setting up the ISR etc...?

Best Regards,

Josh

Hi Josh,

thanks - I'll look into that tomorrow.  Would be good to have some TI code which does something similar in DSS, as the oob doesn't - more to look at to see what I might have set up wrongly!

It does look like EDMA is doing sort of what it should, and is "simply" following chirpAvail interrupts, and the ratio of one to the other also looks right, depending on how I've configured my data capture e.g. set for 10 blocks (of 4096 ImRe samples), and there are 10* chirps as EMDA completions.  This also seems to say that the ISR and EDMA event are pointing to the same place, despite one points to 9 and the other to 123 (from memory).

To confirm what I see so far: MSS counts chripAvails - always correct.  DSS does pretty much exactly the same (code set up etc, and in how the ISR is declared) but counts many more.  This, I assume then makes EDMA run, so blocking data access from DSS code.  In does stop eventually, though - put a break point where it says EDMA has completed, and by the time a human reacts, it seems to have sorted itself out, and DSS has access again.

many thanks

Alan

Hi Josh,

well, as far as I can see - my ISR setup is identical, except that the .arg is set to 0 in MRR, but the oob version uses (uintptr)null.  I've changed this to 0, but don't see any difference.

I wonder if the problem is somewhere before dss, partly based on the fact that I've used the oob as my starting point, and this doesn't use chirpAvail in dss?

Question: what happens/what is wired up in the silicon?

It seems that dss is doing what it's told i.e. both the ISR & EMDA counts appear to be in step, so they're both connected to the same source.  What happens in bss? Is there a "wire" of some form, from the adcbuf which says samples are available (the chirpAvail interrupt signal), and does this exact same "wire" go directly to MSS & DSS? Or, is there some conig I'm missing?

As MSS seems to be correct in counting interrupts - is there something I haven't got initialised (being oob based, not mrr), which links bss to dss?  I've had a look through MAIN and the INIT parts of both, and there's nothing obvious, but it may be that there is something in lower layers, or in the way which things are done that is different? 

As far as I can see, both CCS projects are building with the same bss code - so at least that bit is common.

many thanks

Alan

Alan, 

The hw interrupt should be generated based on adcbuf configuration and the same signal is exposed to both MSS and DSS. 

Alan Milne said:

I've had a look through MAIN and the INIT parts of both, and there's nothing obvious, but it may be that there is something in lower layers, or in the way which things are done that is different? 

I do not think anything else is required here but as I am not as familiar with the automotive demos please give me a couple days to inquire with the engineers who would be more knowledgeable with this demo's setup and get back to you.

Best Regards,

Josh

Hi Josh,

I'm still looking at this too - and I've found something to report: indeed, something seemingly so strange, that it must be a pointer to what's going on.

In the "real" system, the IWR is synchronised with other h/w via GPIO_1 ... and a h/w interrupt there from.  As I've now got a second IWR to act as a signal source, for testing my DSP, I've added a "s/w trigger" command, to save having to have everything else running, while I test.

I've just gone back to check something - so, setting continuous mode running via the GPIO ISR ... and this works just fine!  Both MSS & DSS chirpAvail counts are correct, and the dsp seems to run properly in DSS i.e. the (I assume) conflict between DSS & the EDMA taking control of L3 doesn't happen, because the EDMA is only running the once, as it's suppossed to,

I'm using the exact same code to start cont mode: 

ADCBuf_control (gMmwMssMCB.adcBufHandle, ADCBufMMWave_CMD_START_CONTINUOUS_MODE,
(void *)&gMmwMssMCB.cfg.ctrlCfg.u.continuousModeCfg.dataTransSize);

just that one is inside a message processor in mmw_Cli (exactly as every other message handler in there), where as the other is in an HWI.

I can't see anything different around any of the other code that would account for the difference in DSS behavior - for both modes, all control, counting, IFs etc are in MSS (no control in DSS, so no DSS to MSS IOCTLs etc involved).

>> IS there perhaps something in the depths of the OS which means that it matters where I put the contMode (i.e. talks to BSS?) command?  I know that you can't have PRINTFs inside ISRs, so maybe there is more like this?

Hopefully that may spur a thought  - I haven't found anything else that's significantly different between the two, other than where the ADCBuf_control is called.  The rest is essentially quite simple: h/w or s/w starts contMode : this produces chirpAvail interrupts : MSS counts these and stops at the desired number :: DSS sits there and counts chiprAvails too ... just that it gets a different answer, despite being, as far as we know, connected to the same signal as MSS.  The only difference I've found so far being which ADCbuf_control it's started with.

many thanks

Alan