IWR1843BOOST: IWR1843BOOST

Hello Alan.

You could also try modifying the existing visualizer to fit your needs, and see if that is able to resolve any of your issues.  I am looking into this internally and will get back to you beginning of next week.

Sincerely,

Santosh

Hi Santosh,

wasn't aware I had source for the visualiser.  I've had a look, and seems that'd be quite a lot of effort to work out what its doing and what I could modify ... and high risk I might break it on the way!

I'll wait and see if there's anything you can help with.

thanks

Alan

Hello Alan.

I have not encountered such issues with either visualizer for the out of box demo.  However, it seems like most of your issues revolve around parsing the data being streamed out of device.  I would take a look at the gui_parser.py, parseFrame.py, and the parseTLVs.py as a reference and compare it to how you are doing it in your c# visualizer.

Sincerely,

Santosh

Hi Santosh,

thanks - I don't seem to have those files, it is usually interesting to see how others have done things.

I don't think its the parser - it works just fine after the delay & I've got the IWR code to tell me which frame/subframe its just sent - my code reflects this, so it's not actually missing any info.  Also, putting a break-point right on the comPort receive also shows the delay, so it's somewhere between the IWR and c# i.e. there isn't data running through my code until it gets sync, sort of thing.

Interestingly .... as I'm progressing with my own code (starting from oobDemo), I've cut out bits I don't need.  Although the CLI etc bit is still servicing incoming messages, I've removed quite a lot of the CONFIG sort of parts from the original.  This, now, responds immediately, without the delay that the original shows.  To this end, I can remove all the cfg file entries beyond the guiMonitor & everything still works as I need it to.

This leads me to wonder if ether is something else hidden going on between the IWR & visualiser to account for this. By hidden, I mean not in the profile.cfg .... setting up the data comPort is an example of this.  It took a moment to work out why, at my first attempts, everything seemed to be working as regards setting up the IWR, but no data seemed to come out.  I found the answer by adding debug text into the IWR code, to catch what the visualiser was sending.

As I seem to be OK i.e. my latest code doesn't have the problem, I guess this is academic now - but it's always nice (and good!) to understand what is going on.

Still of interest, though, is the problem of the data seemingly stopping at around 3300-3400 (ReIm16) records.  I guess part of that is a question for what happens in your USB-to_comPort drivers ... any buffer size issues?

What I'm trying to do with this question is understand the existing s/w - before I set about modifying things. Nothing here is actually stopping my work, so I won't keep the tread live for long - I just need to find out if anything is already known about the issues I'm seeing.

Thus, probably only one more loop needed - if you could tell me anything about:

>> maybe driver etc buffer sizes, now I'm sending larger data sets back?

>> is there any good/easy way to add flow control - that might also be part of it?

many thanks

Alan

Hello Alan.

Please give me some time to review this and I will get back to you with a response by the end of this week/Monday at the latest.

Sincerely,

Santosh

Hello Alan.

Alan Milne said:

thanks - I don't seem to have those files, it is usually interesting to see how others have done things.

You can find the source code to the out of box visualizer in the latest version of the industrial toolbox under {Toolbox location}/tools/visualizer.  Please try running that visualizer with the regular out of box demo(unmodified) to see if the issues you see with yours show up here as well.  

Alan Milne said:

Still of interest, though, is the problem of the data seemingly stopping at around 3300-3400 (ReIm16) records.  I guess part of that is a question for what happens in your USB-to_comPort drivers ... any buffer size issues?

What do you mean by records?  Are you referring to the TLV's sent from the device or another data format you are using?  Also if you have questions regarding the drivers, you can find a link to those drivers in the out of box user guide.  There are no buffer size issues that have been encountered with our visualizer, but if you look in the code for the out of box demo, in the main.c file, you can find the length of each of your output messages and make sure that the data you are sending doesn't exceed that size.

Alan Milne said:

is there any good/easy way to add flow control - that might also be part of it?

I am not familiar with flow control in c#, but you can check in the parser script gui_parser.py as there is some work done to determine if you are reading at the start of the frame via a magic word.

Sincerely,

Santosh

Hi Santosh,

By record I mean a 4 byte (ReIm16) value - so this is within the  body of the TLV message.  On my GUI, I can see that (say) 2048 records all arrives OK, but the next size up i.e. 4096 doesn't.  The received TLV record length is correct at 4096, but the data stops arriving at around 3400 or so.

The data I'm sending here is raw ADC data - I've added this via extending the guiMoncontrol in the cfg file, and added to MmwDemo_transmitProcessedOutput to send it out.  I have a breakpoint at the end of this, so I can see that DSS has completed, sent everything to MSS, and it looks like it's all been sent to UART_writePollling, inside a loop just like other output processes there - the loop counter says 4096, so that should have completed.  It then sends the padding bytes just before my break point.

I think I've done that all correctly (baring a question of length of data sent) - indeed, I swapped over the order of sending in the IWR, so that it now sends temperature first (thought I ought to keep an eye on that, even if the data doesn't all arrive) followed by my ADC data.  My c# code was quite happy with this, without change.

As sending 2048 2*16 bit values is OK but 4096 doesn't make it, I wondered of maybe it was a stack size issue (I'm changing what the s/w does, so may be consequences - I may be sending more data over the UART than the code was intended to).  If I double the MSS DPM stack size ... this makes no change.

As for flow control: I know about the c# end, it's the 1843 end I need to ask about.  SWRU520e (amended May 2020) section 27.1.1 - if that 's the right bit - says flow control isn't available ... but can be added via IO pins etc.  I don't know if this is possible on an IWR1843BOOST board?

thanks

Alan

Hello.

I think this makes a little more sense now that I understand you are trying to send raw ADC data.  You can refer to this e2e as to why you cannot stream raw ADC data over UART.  This may answer some of your questions about why you are not getting all the records you are expecting.  If you want to stream raw ADC data, you can follow this e2e to threads that might help.

Alan Milne said:

As for flow control: I know about the c# end, it's the 1843 end I need to ask about.  SWRU520e (amended May 2020) section 27.1.1 - if that 's the right bit - says flow control isn't available ... but can be added via IO pins etc.  I don't know if this is possible on an IWR1843BOOST board?

Here is the link to the technical reference manual for the devices in the IWR family.  In section 26.1.1, it states that it also does not support any hardware UART flow control.

Hope this helps,

Santosh

Hi Santosh,

thanks for that - ah, but I didn't say anything about "streaming" rawADC data .... 

For my research, I first need to "access measurements at radar frequencies", for which, the 1843 is very well suited, even if what I'm trying to use it for is not exactly what it was envisaged in its design.  If my idea turns out to work, then I can port all the algorithms into the device (hence starting with the 43 type, maximum on-board processing available).  On the way to that, though, I'll need to do quite a lot of development and, for this, I'll need to be able to look at the data in ways that CCS and the other TI tools do not allow (hence the need to produce my own "visualiser" etc).

For this, I don't need to get adc data in real time - UART speed is just fine (I do have some very tight timing restraints, but that's for a completely different question thread).  So, this question is not really about ADC data - its about getting "any" data off the device and into the PC.  I know you actually can't do this with the OOB_demo - but that 's really only because the code isn't there.  I've added that code, simply copying how it was done for other data ... so that much ought to be completely compatible.

Where what I'm doing is different, I guess, is in that I'm almost certainly sending larger data sets back through the interface than it was probably designed for.  I fully accept that changing your code to handle this is up to me!  However, I'm "only" extending the use of existing code (i.e. how to use the UART, the fact that it happens to be ADC data doesn't matter),

I'm looking for help/advice on the workings of the UART interface - guess this is a question about using your device rather than your software.  It may be that I'll have to delve into the lower workings of UART_writePolling etc to solve this.  As said, I accept that this level of change-of-use is entirely mine to sort out.

Thanks for the 522e document link - looks like an update to 520e, always best to have the latest info.  My problem here is that I have an 1843BOOST, with whatever connectivity it has.  The UART looks like a comPort an the PC end, but is USB at the 1843 end (if I understand correctly).  This comes into J8, and then into U10 & U6 - the XDS110 interface.  I'm not at all familiar with these devices - and the connectivity between them and the 1843.  I was rather hoping you could give me advice on how to add flow control (which may or may not help my UART problem) - but again, this may be that I'm trying to use the device/board in ways that it wasn't really designed for.

I think we may be near closing this thread - I'm trying to use the device beyond its original use cases, and so it's on the limit of what's in your remit to assist with etc.

many thanks

Alan

Hello Alan.

Alan Milne said:

I'm looking for help/advice on the workings of the UART interface - guess this is a question about using your device rather than your software.  It may be that I'll have to delve into the lower workings of UART_writePolling etc to solve this.  As said, I accept that this level of change-of-use is entirely mine to sort out.

Let me look to see if there are any resources I can point you to regarding the UART interface.  We have links to the UART drivers in the out of box demo which you can take a look at as well.  You can also place breakpoints at the UART functions in debug mode(especially since you have boost board) to dive into these functions and see how they work.

Alan Milne said:

Thanks for the 522e document link - looks like an update to 520e, always best to have the latest info.  My problem here is that I have an 1843BOOST, with whatever connectivity it has.  The UART looks like a comPort an the PC end, but is USB at the 1843 end (if I understand correctly).  This comes into J8, and then into U10 & U6 - the XDS110 interface.  I'm not at all familiar with these devices - and the connectivity between them and the 1843. 

The document I linked is the technical reference manual for the IWR devices including the IWR18xx devices, which includes the 1843Boost.  The XDS110 interface is used to connect with CCS debug, but it works the same as the COM port in terms of streaming UART data back from the device to the PC.

Alan Milne said:

I was rather hoping you could give me advice on how to add flow control (which may or may not help my UART problem) - but again, this may be that I'm trying to use the device/board in ways that it wasn't really designed for.

As stated in the TRM, there is no hardware flow control and will have to be integrated into your own software.  Since your software is custom and not something we support I don't have any tips that I can provide, but as I stated before, you are welcome to look through our source code for our visualizer and pull what you need from it.

Sincerely,

Santosh

Hi Santosh,

yes, fully understand that you can't really help with software I come up with!  I'll leave this thread open for a little while, in case you can find any more UART info.  I'll close it by the end of this week at the latest.

I'll have a look for the visualiser source too - I don't seem to have this at the moment.

many thanks

Alan

Hello  Alan.

Here is some documentation on the UART drivers, and the app notes have some code examples on how to use them in software.

Alan Milne said:

I'll have a look for the visualiser source too - I don't seem to have this at the moment.

If you download the latest toolbox, the source code is in tools/visualizer.

Sincerely,

Santosh