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

Part Number: IWR1843BOOST

Hi,

I'll assume you can see my previous thread - trying to download to SRAM, rather than FLASH....

I've made good progress with my own code - starting out as a super-set of the OOB demo, so much of code unchanged.  Further, at this stage, I can still use both visualiser and mmwStudio to talk to the system and gather data, for initial testing.  Might as well use the graphic displays while I can!

  • It suddenly occurs: mmwStudio requires that files are downloaded i.e. BSS & MSS (both RPRC format, I think).   Can you tell me about the protocol this is using?
  • It seems that if mmwStudio has the means to download and then boot into working code ... this is not far off what I was trying to do via the protocol in SWRA627?  Although mmwStudio only seems to load BSS & MSS ... can it load DSS as well (I'm not clear if it really is just MSS, with other/DSS processing is in the MATLAB bits, or is it MSS/DSS combined in some way)?

many thanks,

Alan Milne

  • Alan,

    Please allow us some time to look into the details of the the flashing done in mmWaveStudio. We will provide further info here no later than Wednesday.

    Best Regards,
    Alec

  • Hi Alan,

    I want to let you know we are still looking into these questions and will be getting back to you as soon as possible.

    Thanks,

    Angie

  • Hi Angie,

    thanks for the update - not urgent at the moment, getting on with working through my code updates & running & debugging via CCS.  Slow so far, but usually the case when learning the details of a new system - and seeing what might not work now I've been editing your code ....

    Actually, I'd be interested to know about all protocols used for talking to the IWR from mmwStudio & the visualiser ... I can see some in the CLI code of the oob demo, but documents for the control/data handling protocols would be really useful.  This might well be a different thread but, its just possible you know the answer straight away - that is, if these protocols aren't published, so I'll just quickly ask that bit here.

    thanks!

    Alan

  • Hi Alan,

    When loading in MMW Studio, you are correct this is loading to SRAM via UART. However, this is typically in DEV mode with the SOP pins, not functional mode, so the load code is slightly different as different features are enabled for debug/dev. the issue of normally loading SRAM via UART with the 1843 should still be present when loading with mmWave Studio if loading in functional mode. However you could try it. If you use the BSS FW line to load the entire BSS+MSS+DSS image you have (with the CRC included), this is where you would load from. The BSS load line should just set the start address for the image and then load the whole file. I have not tried but assume that in functional mode you would see a similar error as before.

    Regards,

    Jackson

  • Hi Jackson,

    thanks for the info ... I've experimented a bit.

    Doing what I think you mean i.e. using the BSS load with the pre-built .bin file does NOT work, it just hangs - I suspect its the wrong file format, as the BSS/MSS/DSS overall is MSTR, whereas the individual parts are RPRC's.  I tried sending the correct BSS part (mmwStudio expects a given order), followed by using the MSS line - but to send the DSS bin (from my ccs build of the oob demo code in SDK), which is RPRC.  I don't expect this to work functionally (pressed reset as soon as it had finished, just in case), but it DID accept the file.

    I can't try any further just yet, as I don't seem to have an RPRC bin file for MSS: DSS/ISK has the file for that processor, but the only bin under MSS/ISK is the MSTR one.  I'll need to have a play with CSS settings to see if I can get it to give me an RPRC for MSS, then try again.

    This all sounds frustratingly close to what I'd like to be able to do!  It's also rather confusing how its presented: functional mode for debugging with CSS, yet debug mode for using the IWR with mmwStudio.  You can see how I got so confused earlier on, when I was expecting to have to parse the individual RPRC's out of the MSTR, when reading SWRA627 document. Plus, FLASH has entries for four meta images (and 627 talks of four metas), whereas what it actually wants is a single overall file, containing many mete images.

    However, we're so close, I'd like to continue trying for a little longer - after all, mmwStudioa IS able to UART download to SRAM and run the code.  I need to look at:

    • how to get an MSS RPRC bin file (or you could advise), then try BSS/MSS/DSS separate loads in mmwStudio
    • OR - how to produce a combined MSS/DSS file, if that's what's in the mmwStudio MSS RPRC file - as said, I'm not sure if this IS a combined file, or in fact there ISN'T a DSS part, as studio uses MATLAB for the back end processing?

    Thanks for your efforts so far ... I'm guessing I'm digging rather deeper than many users might, but I am researching how to use radar for a sensing task that no one else has thought of.

    Alan

  • Hi again,

    working on what you said about different things happening with different SOP settings:

    "talking"  to the IWR in debug SOP2, it doesn't seem to follow the SWRA627 protocol e.g. no BREAK needed, looks to echo message sent, rather than return acks.  Is there a protocol document, like an SWRA627, but for whatever is required in SOP2/mmwaveStudio?

    thanks

    Alan

  • Hi Alan,

    I highly advise not trying to do any development in SOP2 mode. It really only allows raw data capture, and you don't have full access to all the memory. It is not designed for application code to run.

    On looking deeper, loading code via mmw studio in SOP4 is only possible with load via SPI with no flash present. It will not load over UART.

    Regards,

    Jackson

  • Hi Jackson,

    ... I entirely understand your reply.  I've always made a point of trying to learn as much as possible about any device I want to use, all its functions & capabilities, as there may be something in there which is useful in my application.  A manufacturer can aim for a target market, and publicise the functionality they expect will be used in that context - but then, people like me come along with an application which the manufacturer had never thought of.  Yes, this does mean that perhaps I'm trying to do something which won't actually work - that's the whole point of my research.  The sooner I get the IWR doing what I need it to (and make it easy to use as a research tool), the sooner I'll find out if my idea has any chance of coming to reality.  Not far off now, hopefully!

    I think we've done every thing we can now on this thread, so I'll close it.

    many thanks!

    Alan