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.

AWR1642: Help Needed I am a Hardware Development Engineer, working alone. Trying to Prove a Concept.

Part Number: AWR1642
Other Parts Discussed in Thread: , MMWAVE-SDK, UNIFLASH, IWR1642, IWR1642BOOST, TIDEP-0090

Help Needed I am a Hardware Development Engineer, working alone. Trying to Prove a Concept.

I'm not very good at software/firmware development.

I have an AWR1642BOOST EVM. It is a few months old and probably ES1.0, Can't read the writing on the AWR1642 chip, it is not visible.

Also have a mmwave-devpack, the box shows seal date 6/17/17 – I would have to “destroy” the AWR1642 by removing 3 resistors in order to adopt the EVM for use with the devpack, so I prefer not to use the devpack if not essential.

Need to extract Three approaching “Targets”, which may be Automobiles or People: the closest, the fastest and the largest. The resulting range, (radial) velocity, and size of each of these three targets then need to be recognized as data that can be read by further, “back end” processing continuously.

Need to update the processing for every frame.

Long Range and High Velocity is sought, Resolution is secondary. No specific distance or speed, just for now, the longer range and higher velocity it can handle is a plus.

Can this EVM be configured to do this?

Is “gtrack.h” sufficient to Generate and Track the three Targets?

Is the AWR1642 ES2.0 required?

Will this Hardware or Software be revised soon to an ES3.0?

Is the DCA1000 EVM Real-Time Data-Capture Adapter for Radar Sensing Evaluation Module Required? (Hope not)

It is not essential to do this proof of concept with an AWR1642, It will not be on an Automobile. Maybe IWR or other EVMs can achieve this result.

TI has downloaded

Per tools/mmwave-sdk, “MMWAVE-SDK-LTS” 1.02.00.05, 07 MAR-2018

Long Term Support, which Supports AWR1642 ES1.0

Also “MMWAVE-SDK” 2.00.00.04, 26 APR-2018 (If I need the ES2.0, Rev A AWR1642)

Demo Visualizer

CCS 8

Uniflash

I have a Windows 7 laptop, i7. Using Chrome.

Need to first run this as a Demo on the Laptop.

Once this demo is seen to be Extracting Targets on the Demo Visualizer Console, the demo will need to be converted to run in Linux in order to combine the target data output with the “back end” processing. At that point, the Demo Visualizer may not be required.

Will someone please assist me in accomplishing this task?

Thank You,

Dan

  • Dan,

    I will try to answer a few of the questions that you have posted here. To be upfront, TI does not develop code on the E2E platform. The platform is meant to provide answers to specific questions. TI does not review code on this platform.

    With regards to the DevPack, you do not need to destroy anything on this device in order to use it with the EVM. The EVM fit in nicely to the DevPack without any hardware changes. Please reference the User's Guide for the DevPack to ensure that the device is properly aligned.

    The DevPack is designed to be used with mmWave Studio, our radar development platform tool. With the EVM by itself, you can only flash compiled binaries onto the device. Using mmWave Studio, you can work on developing the different chirps you would want to use for your specific application.

    The DCA1000 is used for capturing raw ADC data so that it can be post-processed afterwords. Depending on your approach, this may or may not be required.

    AWR1642 ES 1.0 should be sufficient for developing your proof-of-concept. The EVM you have now should work fine. There is no publicly available timetable for the release of any future silicon revisions or SDK updates.

    Also please keep in mind that the SDK is developed for support primarily in Windows. Only limited Linux support is offered.

    Please reach out if you have further questions.

    Regards,
    Kyle

  • Thank you for your quick reply Kyle.

    I did not realize that the E2E platform is not for code review. If there is a better place to post my inquiry, please let me know.
    I am anxious to complete this proof of concept prototype as the application will save many lives.

    I have incorporated many TI products in many of my hardware designs over many years.

    When I read from swru506 for the devpack:
    2.4.4 MIPI 60-Pin JTAG Connector (J3)
    This connector provides the standard MIPI 60-pin interface for JTAG and trace capability (trace is
    available only on the 1642 device), through emulators such as the XDS560pro (see Figure 9). To use this
    interface, the JTAG lines to the onboard emulator (XDS110) on the mmwave BoosterPack must be
    disconnected. This is done by removing the resistors R69, R70, R71, and R30 from the mmwave BOOST
    boards.
    When these tiny surface mount parts are removed, it would be difficult for me to replace them, hence the term 'destroy'.

    I have also been having problem with the XDS110. Getting the Data Port to 921600 baud has been a problem, had it working on a W10 Desktop, but not on the W7 i7 HP Laptop. If the devpack takes over the JTAG function, that problem may resolve.

    Continuous tracking of the aforementioned Targets and generating back end functions from the resultant data is foremost.

    The Linux issue may be moot once a Software Engineer resolves the operability of the EVM for my application.
    I would imagine that obtaining the desired targeting data is not beyond the capability of the EVMs, it just requires knowledge in an area that I am not proficient in.
    That is why I have reached out to others that are familiar with this product.

    I again thank you for your reply, Kyle, and if it is acceptable, would welcome constructive replies from others as well.
    Dan
  • Hi Dan,

    Regarding the XDS560 and hardware modification of the mmWave DevPack: please do not bother with that for now as you may not need the more advanced debug capabilities of XDS560 before quite some time. The on-board XDS110 should suffice.

    Regarding the SPI communication speed: I have been using a 3-year old mid-range Core i5 laptop without any such problem ever. Make sure you run your software on a machine that has plenty of spare memory and CPU time left from the other tasks it is running while you run the mmWave GUIs. Setting your laptop to high performance may help as well.

    Regarding the sensing task you want to achieve, I would suggest you look at our Traffic Monitoring Object Detection and Tracking Reference Design (link). To me, it looks like it implements a sensing function that's fairly close to your objective, so it should be a better starting point than the out-of-the-box mmWave demonstration.


    Regards,
    François.

  • Hello Kyle and Francois,
    I have acquired an IWR1642Boost, but I think it is ES1.0, so I ordered an IWR1642 yesterday which should be Rev A, ES2.0.
    The TI Resource Explorer says all tools should be EXACTLY in C:\ti\...
    I have many of these tools in different folders, maybe that is part of why I had problems with the AWR1642?
    Do I need to delete all the tools in other file locations before completing installation of the TIDEP-0090 Demo?
    Thank you,
    Dan
  • Hello Dan,

    Indeed we strongly recommend to install all TI tools in their default directory which is most often c:\ti.

    The xWR1642BOOST boards have an ES2.0 sticker for this silicon version, and no sticker for the initial (ES1.0) version.

    The TIDEP-0090 reference design should work with both silicon versions, but indeed the software will be different. The firmware it uses is that of Lab 13 Traffic Monitoring in the mmWave Industrial Toolbox (link). Use the latest version of the toolbox (currently 2.5.1) for ES2.0 or, as said in the Lab 13 user's guide, the toolbox version 2.3.0 for ES1.0. The Lab 13 firmware itself relies on the mmWave SDK (link). As said in this page, use the latest SDK version (currently 2.00.00.04) for ES2.0 and the LTS version for ES1.0.

    As for the installations you already have in directories other than c:\ti, it is indeed safer you remove them as it will make sure only what is in c:\ti will be used, removing any confusion.


    Hope this helps.

    Best regards,
    François.