IWR1843BOOST: IWR1843BOOST

Hi Alan,

Please allow me some time to review this and get back to you with a response. Due to the Thanksgiving holiday in the U.S. I can expect to respond here early next week. 

Best Regards,

Josh

Hi Josh,

any progress on advice about using continuous mode? Almost everything else I need to put in place is done - so I'm about ready for help on this.

>  I guess an 1843 profile for continuous mode might be a starting point (I see there are commands for this)

> I need to knw what things need to be included in the cfg file .. do I still need chirp/frame set-ups?

... and any other useful advice!

thanks

Alan

Hi Alan,

My sincerest apologies on the delayed response. 

There is no built in feature in the SDK to enable continuous mode.  Typically, this is done using mmWave Studio but may be possible with modifications to the SDK code. Please take a look at the threads that I have linked below which I think are relevant to you. 

 https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/952410/iwr6843isk-continuous-transmit-mode-single-frequency

CCS/IWR6843: HowTo get the continuous wave Running - Sensors forum - Sensors - TI E2E support forums

Best Regards,

Josh

Hi Josh,

no problem with a delay, there was plenty else to do!

I have looked at the capture code before - good, in so much as it captures data, but not so good in that it was just "part of the system", hence why I've done myself a hybrid 1843/1642 (i.e. without HWA, so I can see how the EMDAing to RAM works), so I have all the control, config and UART etc code from the OOB-demo ... and also partly so I can use standard profile.cfg's and something more resembling TI code for as long as possible, so that there's a better chance you can help with my questions.

Taking ADC samples into L3 until its full - pretty much exactly what I need to do first, so what you've sent me looks very useful, I look forwards to examining it in detail.  I have done quite a lot of the "back end" i.e. I have all the EMDA set up to ping/pong from ADCbuf - driven by odd/even chirp number, not yet ADCbuf ping/pong control.

>> additional question for understanding: am I right, that the oob_demo code does not ping/pong into ADCbuf ... it takes a chirps worth of samples into (e.g.) ping, then tells the objDet etc code data is ready?  If it does ping/pong, then I already have some code I can look through to see how its all done - particularly around how ping or pong is selected (in BSS, I guess), and how I access the ping/pong control line from my code, so I can keep in sync with where the samples are put

At a first look, what you've sent me might well have the answers, I'll go through it in detail straight away.  If you don't mind, I won't close this thread just yet, as there may be more questions ...  at least I should be able to  base questions on TI code and your examples here, rather than anything I write which, of course, is entirely up to me etc.

many thanks

Alan

Hi again Josh,

looked at the code you sent - hopefully, with the other work I've done along the way, I understand the CAPTURE better now, and so can focus my questions ... not far off seeing how to do what I want.

Let's state what I think I need to do:

set up CONTIN mode, this will take (say) 1024 samples (ADCBUFCFG4.ADCBUFSAMPCNT) into ADCbuf ping, raise a chirpAvail interrupt .... and then carry on, writing to pong, then back to ping etc etc.  I'll read out of whichever of ping/pong the ADC is NOT writing to - until L3 is full.  This means I will have 256k (4 byte, ReIm16) values, which are continuous and CONTIGUOUS.  The back-end of EDMAing into L3, ping/pong, in ADCBUFSAMPCNT chunks, is all done - just need to understand the link into the ADCbuf sampling & it's ping/pong.

Now, in the capture code - I don't see if/where/how it is ping/pong-ing ... where my understanding is lacking.  It may be that it isn't actually necessary - but I must have contiguous data, so presumably ping/pong is essential so me reading ADC data doesn't conflict with new data being written.  I don't see any ping/pong setup, there seems only to be one EDAM channel in use, and there's no "shift" in SRC address to account for the front end ping/pong.

Indeed, that's partly why I went to look at oob_demo non-HWA code, as it does have ping & pong ... ponting to RAM, and a bit simpler that the HWA version.  But in that, I'm still not sure about the data INTO the ADCbuf ping/pong - or, maybe, the oob_demo doesn't do that anyway?

Thus, I presume, I need some way to access "Ping Pong Sel"  - and indeed, perhaps to specify whether the ADC starts in ping or pong, based on SWRU522e section 13.

So - its either already there in the code and I just need more understanding, or there is a bit missing (i.e. ping/pong on the ADCbuf input), for what I'm trying to do.

Hope that helps get a bit closer to what I'm trying to do, and what I need to understand in order to code it.  It's a complex system with lots to learn, but I think its just down to learning about how ADCbuf works in continuous mode.

many thanks

Alan

Alan,

Please allow me a some time to check on this. I will respond on this thread tomorrow with more information on the ADCbuf input.

Best Regards,

Josh

Hi Alan,

Just to further clarify, you are trying to enable continuous wave output mode, without actual chirping, just one frequency tone output? I clarify because this is fairly separate from the capture side of the issue. More info and an example for setting CW mode can be seen in the studioCLI tool in the platform toolbox. This should show how some of the CW is enabled.

https://dev.ti.com/tirex/explore/node?a=VLyFKFf__4.12.1&a=Z2F8GEn__1.2.1&node=A__AAqrdvmyB0iH1FeHk4CeoA__com.ti.mmwave_platform_toolbox__Z2F8GEn__1.2.1&r=VLyFKFf__4.12.0

Also, can you please describe more of what you are trying to test with CW output mode? The ADC samples don't actually work straightforwardly since the TX tone is exactly the same frequency as the RX tone, so the subtracted signal is always zero. Typically CW is just used to test the antenna patterns with an external receiver. Do you have more info on what you are trying to enable?

Regards,

Jackson

Hi Jackson,

thanks for the link - I'll read that immediately.  It may also answer a couple of related questions - both in continuous & oob modes:

as I understand it, once all configured, DSS basically waits for interrupts from BSS - frame & chirp.  Frame interrupts happen set by the framePeriodicity parameter in frameCfg etc - and just keep going once BSS is started.  This leads to two questions, sort of two halves of the same thing:

> is frame & chirp config still needed for continuous node? Obviously things like adc format & sampling need to be set, but chirps & frames don't have the same meaning (this is entirely about bss etc config, rather than any completeness checks done by mss or dss)

> when in oob mode, can I configure it do do a single shot e.g. one fame only, then stop?  In continuous, this would be can I config for some period, or number of samples, and then stop?  Controlling via sensor start/stop messages may be a bit slow to guarantee exact behavior, especially as we're talking about comms inside a multi-processor system. In either case, I'm looking at running for lets say 10ms, with a much longer gap until the next - so on-board temperatures etc shouldn't be a problem.

As for what I'm trying to do - well, I can't tell you the actual application as I have to protect my IP (if this all works!).  At this stage, I want to use the 1843 as a sensor, to do some real-world measurements - hence why I need to take a snap shot of adc samples (say a whole l3's worth) and get these out to the PC to look and see what information it contains ... under the test conditions I'm interested in.  As you'll gather, this is not a standard radar scenario - I hope to be able to add all that back in later on, as it gives me more information - and better selling points for the technology I'm trying to develop.  But, one stage at a time, I need to analyse what appears in the adc samples with pure cw first, then see if I can make it all still work with the other variables which come into play when chirping.

Once I get the data-acquisition bit (that we're talking about here) done, there's just one problem left to solve, which is to do with timing and synchronising the 1843 with the rest on my system ... that's all in FPGA, as timing control is critical.  But any questions on that will be for a different thread - I have a plan for how I'm going to do it, given that the 1843 is a s/w based system, and so guaranteed timing needs very careful thought and design.

When that's all in place, I have the measurement system I need to test my theory, so I'm getting very close to finding out if my ideas actually work ... or not.  If it does all work, and I can sell it, we could be talking of quite large numbers of implementations of this, in quite a few areas, and there may well be spin-offs for the technique into other areas.  As I think I've said in a previous thread, UK gov has recently put £6 million of the table - not by but finished equipment, but just to ask if anyone can sole this problem.  So I do have a commercial goal in mind!

many thanks

Alan

Hi Jackson,

thanks - I thought there would be an easy way to do a single frame: "set to 0 for infinite...", hmm, might have read that somewhere along the way.  For completeness, where is the frames loop (and NumLoops) code running?  Haven't managed to unravel that bit yet, doesn't seem to be in dss or mss, so presumably another part?

Using mmwStudio OUTPUT, I can see what its doing, but this gives a couple of problems:

> mmwStudio has more parameters in the cont mode cfg command that the oob_code is built for ... I can see what's going on, so its not an issue, just for your info. (and of course, mmwStudio has its own s/w, not the demo)

> I can see it send the command ContStrModEnable to start things off, but not the stop command, presumably just ContStrModDisable?

> so far, I can't see where that command is handled in the oob_demo (got the contModeCfg etc), so I can't see how its being dealt with - and perhaps it's not actually in the oob_Demo? I know I'm trying to do things the s/w wasn't really written for.  The mmwStudio s/w is only is .bin form only, no source, so I can't have a look and see how that does it.

Lastly, this is all to do with controlling it - but I still need to make sure my code emptying & bss filling the adcBuf are in step ... how do I access the "Ping Pong Sel" (swru522) control?  Closely related, I guess there won't be frame or chirp interrupts from bss so, perhaps rather than a bit or flag, I should be looking for a ping/pong buffer ready interrupt from bss?  Figs 13.3 & 13.4 show single & multi-chirp, but not what happens is continuous.  There must be a (very similar) mechanism?

many thanks

Alan

sorry, just reading 522 section 123 again .... it IS chirp available interrupt that s used!  The question then is only about the ping pong sel.

thanks

Alan

Hi Alan,

Please allow me some additional time to look into this for you. You can expect a response here by wednesday at the latest. 

Best Regards,

Josh

Hi,

wondering how this is coming along? I have nearly everything else I need in place now so I can start really using the 1843, but I still need to synchronise all the data acquisition i.e. ping/pong of BSS writing into adcBuf and my code reading reading it.

Just to re-cap: I need to do this so I can acquire radar data for as long a time record as possible ... e.g. fill L3 memory.  For this data to be contiguous, I must read out of adcBuf in the right ping/pong order to match what BSS is doing - I must be able to guarantee e.g. ABCD etc and not end up with BADC, never mind trying to read adcBuf at the same time and from the same location as BSS is writing to it.

thanks

Alan

Hi,

I do need information on this now.

I'm using chirpIndex lsb in the meantime to test the code, but I don't know how I can guarantee that this is always in step with adcBuf pig/pong selection.  The docs (522 section 13) say it's there, and it makes perfect sense that such a facility should exist ... just need to know how I access the information.  Although section 13 is only talking about the adcBuf - surely there must be some way of knowing whether the code should read from ping/ong, at least to avoid access conflicts i.e if adcBuf is writing to ping, then code MUST read from pong?

thanks

Alan Milne

Hi Alan,

I am checking on this register location. Please give me until thursday to respond here.

Regards,

Jackson

Alan,

I think this may be the register you are looking for.

DMMADCBUFPINPONSEL

Please look at 4.8.4.68 in swru522 for more info. However I think it will only be available when using hardware in loop mode and bypassing the front end. Otherwise the ADC ping pong is not really controllable from the application.

Regards,

Jackson

Hi Jackson

great, thanks!  I'll look into that - might be tomorrow before I get to it.  I don't (think) I need to write to this, just read ... so long as I can see what BSS is doing with adcBuf, then I ought to be able to synchronise my reading of adcBuf to avoid clashes, and maintain data-order sync too.  Assuming there's no conflict reading the register, I suppose.

many thanks

Alan

Hi Jackson,

may be section 4.9.4, as I'm using an 1843, but at least the lower section numbers are identical.  Now I see that register name, 522 does mention it in section 13.1.2 ... guess I was looking for PINGPONG, and didn't see the PINPON naming.  All of this seems geared towards WRITING to the selector (and relating to DMM/HIL), whereas I just need to read it, so I'm not convinced yet that this is the answer (questioning my knowledge, not your advice).

It must be there somewhere.  I don't think (looking at DSS code where oob demo sets up the adcBuf reading EMDAs) that the oob uses ping/pong-ing, it doesn't need to.  This only relates to CONTINUOS mode?

Following that line ... mmWave Studio CONTmode page default setting asks for 16384 samples. Given that the 1843 adcBuf is 32K and assuming ReIm16 data, then this is more that could be done without a ping/pong set-up (adcBuf max 4k ReIm16's for either ping or pong).  I've had a look at the LVDS_STREAMING code in the oob demo ... I can see it allocating EDMAs, but haven't yet found the bits where it actually configures them - as this is, presumably, where continuous data streaming would have to use the select signal I'm after?

I base that on the assumption that when it says continuous data streaming, it does also mean contiguous, with no gaps ... in which case, there MUST be some form of buffer switching involved for this to be possible. I admit I haven't tried this from Studio - I have a working set up, and the Studio requires different s/w on the IWR ... I'd rather not change that at the moment. Also, I don't have an independent signal source, so I can really see what is being received e.g. on a slightly different frequency, and check a good clean sinewave is recoded, without breaks.  Don't suppose you have any 1843BOOST boards to lend out for a week or two?

many thanks

Alan

Hi Alan,

I am checking and will get back by next Monday. Did you test if it is available for reading for your implementation?

IWR1843BOOST EVMs can be purchased here. https://www.ti.com/tool/IWR1843BOOST 

Regards,

Jackson

Hi Jackson,

thanks - not sure about "available for reading" - if that's to do with trying continuous mode in oob demo, I  don't think it does it.  I can see the cli accepting the command & parameters, but haven't so far found any code which seems to implement it.  Let me know if that's not what the question was.

As continuous mode does appear to be part of the mmWave Studio - that sounds like a good place to look for how it's been implemented.  Of course, I don't have the source for that IWR code, so that would have to be something I'd need ask you to look at.

In my implementation - although I've added more commands/controls, and the DSP is completely different, it is still by and large the oob demo in overall structure, uses exactly the same profile.cfg format etc etc.

many thanks

Alan

Hi Alan,

Continuous mode should also be available in the sutdio_cli program, which does have source code. I still think that most of this is handled directly by the firmware and not exposed directly. But in the studio_cli, you should be able to trace the continuous mode operation.

https://dev.ti.com/tirex/explore/node?a=1AslXXD__1.00.00.26&a=VLyFKFf__4.12.1&node=A__AL1nJaSEJYGHxnLFADKJ7g__radar_toolbox__1AslXXD__1.00.00.26

Regards,

Jackson

Hi Jackson,

thanks - looking at the studio CLI dev guide (you sent me before), there's a directory structure which looks like it most probably contains everything I need ie has 1843 code in it.  However, I haven't been able to access it.  Using TIREX inside CCS just gives me the docs (no code, no directory or any sort of download), and the link above takes me to doing something in the cloud ... again, appears just to be docs, no code.  I've also tried searching ti.com for studio CLI .. again. no code is offered.

If you can help me get that directory for studio CLI, that should hopreully contain all the answers

many thanks

Alan

Hi Jackson,

yes, I've done that, but...

firstly, there's a strange problem on some web sites (or my pc, but more than on of them) where things don't load correctly every time in CHROME.  I've re-done in EDGE, and it still only gets me into the cloud version of CCS, and a START page - no further info, and nothing comes up by searching, either.

When you say toolbox ... I have the ITB up to version 12, but haven't found it in there so far, maybe its a different one?

thanks

Alan

Hi Alan,

There is a new toolbox which has industrial and other applications all combined. This is what is linked above. It also includes the source for the studioCLI. Please download the new package and it should have what you are looking for.

Regards,

Jackson

Hi Jackson,

well, I finally got the new radar_toolbox to install .. looks like there's some interesting stuff in there, but I can't see anything about CLI, or any structure like fig 2 in the Studio CLI dev guide.  This is downloaded ... I haven't done any install into CCS or anything, I'm assuming I'll see the studio_cli directories in  file  explorer?

Alan

Hi Alan,

The source files should all be in the tools/studio_cli folder.

C:\ti\radar_toolbox_1_00_00_26\tools\studio_cli

Regards,

Jackson