AWR1843BOOST: runtime reconfiguration: does the OOB demo lab rely strictly on the GUI for proper setup?

may this could be useful?, what is the purpose/benefit of bypass the CLI?, the doc does not explain it

from sdk doxygen:

Hi Jairo,

I can see two possible culprits for this:

1. While you can send the commands over simple UART via PuTTy or Teraterm, or even call the functions corresponding to the commands directly in your code and start receiving data from the device, the demo visualizer does assume that it has control over the device. This is because the demo visualizer changes its own internal state based on the configuration it just sent (the labels on graphs, and possibly other such things). It is possible that the data is coming in from the device, but the demo visualizer doesn't display it after the change in configuration.

2. It is also possible that you aren't calling all the functions in the sequence. You can see in the demo visualizer console for what commands are being sent for the action you want, and try to match calling the functions for that on the device.

I created a Python script some time ago to convert the captured UART data via demo visualizer into a readable JSON file. This script might be of use for you to debug whether it is the device that is not sending data, or if it is the demo visualizer that is misbehaving. If this script is relevant to you, you can find the discussion for that here: e2e.ti.com/.../awr1642boost-mmwave-demo-visualiser-captured-data

Regards,

Aayush

Hi Jairo,

Jairo Gallardo said:

what is the purpose/benefit of bypass the CLI?

A typical usecase for these steps is if you want the device to not be dependent on receiving UART commands to start sending data. With the CLI bypass, you can start sending data as soon as the device powers up. The CLI bypass could also save some memory as it bypasses the CLI utility and the overhead that comes with it.

In your case, if you are already keeping the CLI, but also want to change some configs in code, I would suggest something other than CLI bypass: try to identify all the handler functions registered with the CLI utility corresponding to all the commands (there is exactly one handler for each command). Then, call these functions in the proper order and with the proper arguments to configure the device from within code. This would replicate the command being sent over UART.

Regards,

Aayush

Hi,

Aniket Mahajan said:

2. It is also possible that you aren't calling all the functions in the sequence.

No, the sequence is correct, as I mentioned before:

Jairo Gallardo said:

1.- I configure a single profile which values I obtained from the same demo visualizer tool, I just adjust the values in order to have a 3m detection, I generate the .cfg file and I use those values to configure the board

this is the .cfg file I use (generated by demo visualizer):

demo_2m.cfg

and I am calling the functions in the same order that the file, the only strange behavior as I mentioned before, is that with this config some graphs are not updated but the detection is ok and works but with the profile_advanced_subframe.cfg file I have the issues mentioned in the point 2 of my post.

Aniket Mahajan said:

You can see in the demo visualizer console for what commands are being sent for the action you want, and try to match calling the functions for that on the device.

I know, I am doing that.

Aniket Mahajan said:

try to identify all the handler functions registered with the CLI utility corresponding to all the commands (there is exactly one handler for each command). Then, call these functions in the proper order and with the proper arguments to configure the device from within code. This would replicate the command being sent over UART.

that is exactly what I have done

Jairo Gallardo said:

using the same functions that the demo uses to configure the board via the CLI (MmwDemo_CLISensorStart, stop, chirpCfg, etc)

Aniket Mahajan said:

This is because the demo visualizer changes its own internal state based on the configuration it just sent (the labels on graphs, and possibly other such things). It is possible that the data is coming in from the device, but the demo visualizer doesn't display it after the change in configuration.

If you tell me that there is a dependence of the demo visualizer for the correct visualization of the data received from the radar then I think that is not a problem of the code running in the radar, so to solve this I should somehow modify the code of the demo visualizer to detect that a new config is being sent from the board but without pressing the "send config to mmwave device" button, what do you think?

Hi Jairo,

Yes, I agree. As the demo visualizer stands right now, it cannot handle changes to configuration that it doesn't perform itself. You would need to modify the visualizer.

I would suggest using the script I shared above to confirm that you are getting the TLVs corresponding to the data you asked for (it is possible that the guiMonitor you use in the modified configuration is not configuring the device to send out all the data). It will be worth finding out whether the device isn't sending the data, or if the demo visualizer isn't displaying it.

Another thing I would ask you to do is to ensure that the task configuring the device has the same priority as the CLI task. The CLI task needs to be the lowest in priority on the MSS.

/**
 * @brief Task Priority settings:
 * Mmwave task is at higher priority because of potential async messages from BSS
 * that need quick action in real-time.
 *
 * CLI task must be at a lower priority than object detection
 * dpm task priority because the dynamic CLI command handling in the objection detection
 * dpm task assumes CLI task is held back during this processing. The alternative
 * is to use a semaphore between the two tasks.
 */
#define MMWDEMO_CLI_TASK_PRIORITY                 3
#define MMWDEMO_DPC_OBJDET_DPM_TASK_PRIORITY      4
#define MMWDEMO_MMWAVE_CTRL_TASK_PRIORITY         5

Regards,

Aayush

Hi,

Aniket Mahajan said:

I would suggest using the script I shared above to confirm that you are getting the TLVs corresponding to the data you asked for

I will check it, thanks

Aniket Mahajan said:

Another thing I would ask you to do is to ensure that the task configuring the device has the same priority as the CLI task. The CLI task needs to be the lowest in priority on the MSS.

No problem with that, I use the same priority that the CLI task

Ok, but I understand that it is a manual fix that I need to perform, would be great that the demo could update by itself automatically, even if this is not really necessary, I use the visualizer just to be sure that the reconfiguration has been carried out correctly because in real operation the data will be tx by CAN, so I will test your script to be sure the data sent ou from the radar is ok, I understand that the script is useful for that purpose right?

Hi,

Jairo Gallardo said:

Ok, but I understand that it is a manual fix that I need to perform, would be great that the demo could update by itself automatically

This is why I recommended applying the config via playback start. With this, the visualizer doesn't send any configs to the device, it just modifies its internal state.

What I'm suggesting is, change the configurations via the device only, but then change the state of the demo visualizer with the playback start hack to make sure it plots the data correctly.

This is not the intended use case for playback start, but it might just work to configure the demo visualizer for the modified config.

Let me know if this could be of use to you.

Regards,

Aayush

Hi,

Jairo Gallardo said:

I will test your script to be sure the data sent ou from the radar is ok, I understand that the script is useful for that purpose right?

Yes, the script will is used convert the recorded incoming data into readable JSON. Then, you can debug exactly what kind of data is being received manually/with other scripts/etc.

Regards,

Aayush

Aniket Mahajan said:

What I'm suggesting is, change the configurations via the device only, but then change the state of the demo visualizer with the playback start hack to make sure it plots the data correctly.

Hi, it works!

I have to manually load the .cfg file in the playback start but once it is done the radar shows the detections ok, so:

Jairo Gallardo said:

2.- I configure multiple profiles using the same values and commands provided by you in the profile_advanced_subframe.cfg, results:

- the detections are not steady, they are intermittent points being displayed in the GUI

- just the scatter* and range-doppler graphs are updated and working, the other graphs are just freeze

*the scatter graph is showing points but the scale is not adjusted, its scale is up to 10m, but when I load the profile_advanced_subframe.cfg using the GUI the scatter graph scale is up to 120m

this is not a problem anymore, now I know that the issue was the GUI that was not being updated from the demo visualizer, not my code, thanks