Introduction

Our aim in this project was to create a proof of concept example use case for Texas Instruments’ mmWave Radar Board ( IRWL6432). We used their propriety software, Code Composer Studio, and training materials for this, and we aim to provide feedback on our experience in this document. Despite any negative feedback mentioned, we want to stress that many of the issues we encountered were due to our inexperience in this field, and our feedback should be taken from the perspective of junior developers with little to no experience in embedded systems and machine learning models. We also want to extend our gratitude to Texas Instruments for the opportunity to partake in this project and especially to Greg Peake for the excellent guidance and advice every step of the way.

Our Process

As we spent a relatively small amount of time working on this project, we may have missed documentation and tutorials that explain the issues we encountered. Our process for any holdups we had was first to try and find answers online or in the documentation, and if this didn’t help, we asked our client, Greg Peake, for advice. This approach aimed to minimise the reliance on Greg’s expertise and reduce the time holdups took to solve and was generally successful.

Our workflow for each project stage can be found in the User Instructions. We created these intending to make the instructions we wished we had at the beginning of the project (not that the instructions we received were bad, just not ideally suited for us on this project).

Code Composer Studio

We only used the Debugging tool in CCS to run our embedded code and test the model. Therefore, we didn’t have the opportunity to experience most of what the IDE offers, and our feedback may reflect this lack of experience with the tool. When there were no issues, it worked very well; however, when problems did arise when interacting with the board, they tended to take some time to sort out.

Debugging

When trying to debug the board using CCS, if there was an issue with the configuration of the board, the error would usually be largely unhelpful. For example, the “device is locked up in hard fault” error appeared many times for many reasons. It would make debugging much more manageable if these error messages were more meaningful; however, we understand this may not be possible.

Navigation

When navigating the program, some things stood out to us. One of these was the small and similar-looking icons in the toolbar. Trying to figure out what these buttons would do without more information was very difficult and led to a lot of time spent searching the toolbar. Also, when trying to change a setting, it was not intuitive where to find options for each program component. For example, there are many different settings/management menus for target configurations and knowing which one you need and where to find it is difficult. It would be very helpful to have a universal location for all settings/management/configurations (possibly in addition to their current locations) so they can be located more easily.

Target Configurations

On the point of target configurations, they were a large source of confusion throughout the project. Although they worked reliably, we didn’t understand them, and we got lucky to set it up correctly once and then leave it alone. We followed the instruction to create a custom target configuration but when debugging a project another configuration would be generated and also work perfectly fine. These target configurations could benefit from being more intuitive with their own toolbar/menu to avoid confusing debugging controls with the projects themselves.

Git Integration

In our project, we added a CCS workspace as a folder in a larger repository. Doing this initially caused a few headaches, as CCS detected the repo and created git ignore files for the projects themselves but not the metadata in the workspace itself. While this may be due to the integration being rushed and not researched properly, it was not intuitive and took some work updating the git ignores in the repo to ignore the workspace files. Also, when changing branches away from the CCS projects and then back to them again, it would take two launches of the workspace for the projects to be loaded correctly.

Positives

The default window layout for CCS is very intuitive and doesn’t require any customisation to be useful. A very nice feature was the window layout changing automatically when debugging a board. The project-wide search tool was a lifesaver when finding variables in the CCS projects. Due to the large amount of code, finding variables would be very time-consuming without it. The build tool was also very good. It worked right out of the box and didn’t require additional thought or time.

Learning Materials/Process

Format/Presentation

At the beginning of the project, we received a lot of information about the radar boards in a very short amount of time. Despite it all being very interesting, it was also overwhelming as we didn’t know how much information we needed to complete this project. It would have been easier to absorb the information if we had been given an approximate workflow overview of the project before diving into the details of any workflow stage. For an example of what we would have liked to see, look at the user instructions we have produced. While we were given instructions similar to these when replicating the dry/wet model, some steps were missing or not well explained in the instructions.

Troubleshooting

Performing troubleshooting around the board itself was incredibly difficult without Greg’s help. For example, it took us several days of having unexplained bugs when using the board until Greg informed us we needed to press the reset button between each usage. While this instruction was probably in the documentation, it was not intuitive and easily missed. This, combined with the vague error messaging from the board, meant that any attempts to research the issue were fruitless. There are many other examples of similar small errors that can be made and missed, which is the nature of working on proprietary embedded systems but could be improved upon by making errors more explainable and/or having frequently encountered errors in documentation.

Depth of content

Much of the content we were sent was way beyond the project’s scope. While it was very interesting and certainly would be useful to someone working on more complex parts of the board, for our purposes, the information was not required to complete the project. These resources are still very welcome, but perhaps they should be in a format that clarifies that they are not required. For example, there were a lot of resources on the exact timing of the board’s communication protocol but not many resources on how the Python scripts provided interface with these protocols.

Positives

The regular meetings and emails with Greg were incredibly useful, and the project would not have been possible without them. Any issues we encountered and could not solve quickly didn’t keep us blocked for long as these communications would solve them. There was also plenty of useful documentation for the scope of our project. For example, the motion and presence detection tuning guide for changing the configuration file parameters and the AI flow pdf containing instructions for the overall process of creating a model.

Conclusion

Overall, the resources we used for this project were very good. The only point of concern is the speed at which an inexperienced client/engineer can be ready to start their development. With this goal in mind, the order in which resources are provided could help greatly. Starting with high-level guides that can be easily replicated and having more in-depth information available at each stage if required.

The tools provided were also very usable and we picked them up quickly with a simple guide. The only issues arose when unexpected errors occurred with little to no information provided to debug them. To combat this, more information could be provided about the types of errors that can be expected from the board and their common causes, as well as, if possible, more descriptive error messages from the board itself.

For Information

For more information on the project, please refer to our docs website and don’t hesitate to contact us if you have any questions.