AWR1843AOP: Change data processing path dynamically

Tanoop Rajan

Part Number: AWR1843AOP

I was currently using the MRR_Lab_07 and wanted to see if it's possible to implement dynamic chirp configuration and change the Data Path at runtime.

I see that the Data Path is set once during initialization in the main function with the following function call:

/* Populate the chirp configuration in the DSS for all the data path objects. */
    MmwDemo_dataPathConfigPopulate(&gMrrDSSMCB.dataPathObj[0]);

After this call, all other elements related to the data path, such as the DataPath object and EDMA, are initialized in the main function itself. Finally, BIOS_start() is called in the main function, effectively meaning that execution never returns back to main. However, I want to change the chirp parameters dynamically like this:

void MmwDemo_dataPathConfigPopulate(MmwDemo_DSS_DataPathObj* obj)
{
#ifdef SUBFRAME_CONF_MRR_SRR
        MmwDemo_populateMRR(obj, 0);
        //MmwDemo_populateSRR(obj+1, 1);
#else
#ifdef SUBFRAME_CONF_MRR
      switch(g_u8_ChirpMode)
    {

      case 0:
          count0++;
          MmwDemo_populateSRR(obj, 0);
          break;
      case 1:
          count1++;
          memset((void *) obj, 0, sizeof(MmwDemo_DSS_DataPathObj));
          MmwDemo_populateMRR(obj, 0);
          break;
      default:
          countdefault++;
          MmwDemo_populateMRR(obj, 0);
          break;
    }


#endif
#ifdef SUBFRAME_CONF_USRR
        MmwDemo_populateUSRR(obj, 0);
#endif
#endif
}

An if-else condition within the dss_main.c file, inside the mmwaveTask, determines which chirp mode to use. If I call the MmwDemo_dataPathConfigPopulate function inside this task, what steps should be followed after this function call? It's quite obvious that since the data path is changing, I need to call all the necessary steps to correctly reconfigure the data path.

If I just call this function and do not call anything else, I get this exception:

Internal exception: IERR=0x10

And if I try to mimic the other steps followed in the main() function after this function call, I am still getting the error.

So, what steps should be taken after this function call to correctly reconfigure the data path without any errors?

9 months ago

0 Cesar 9 months ago

TI__Guru*** 141644 points

Hi,

Unfortunately it is not possible to use this type of dynamic configuration with this demo. It is only possible to perform this configuration at build time

thank you

Cesar

0 Tanoop Rajan 9 months ago in reply to Cesar

Intellectual 291 points

Thanks, Cesar, I appreciate you clarifying that dynamic configuration isn't possible with this demo.

Could you elaborate on the limitations that prevent dynamic configuration in this demo?

0 Cesar 9 months ago in reply to Tanoop Rajan

TI__Guru*** 141644 points

Hi,

I am reviewing your updates in more detail

1) How is "g_u8_ChirpMode" defined?

2) I think you have implemented "MmwDemo_populateSRR()" because this function is not in the original demo. You will need to define a new object specific for this configuration.

At this point I think there are some issues with definition of this function that's why you get an error.

This type of configuration is not "dynamic configuration" if it is defined at build time. After understanding how the configuration is performed in the original code, you should be able to add the update.

Thank you

Cesar

0 Tanoop Rajan 9 months ago in reply to Cesar

Intellectual 291 points

Hi Cesar,

Thanks for taking a closer look at my updates! Here's a more detailed explanation:

1. g_u8_ChirpMode Definition:

g_u8_ChirpMode is indeed a global variable. It gets updated based on an if-else condition within the dss_main.c file.

2. MmwDemo_populateSRR() and Object Creation:

I implemented MmwDemo_populateSRR() as it wasn't present in the original demo. To address this, I created a new object specifically tailored for this configuration.

Object Creation Limits and Memory Usage:

I agree with your point about dynamic configuration. Since this configuration is defined at build time, it's not truly dynamic. With a better understanding of how the original code handles configuration, I should be able to integrate the update seamlessly.

Memory Considerations:

While I was able to resolve errors by creating objects for all data paths, I'm interested in understanding the optimal number of objects I can create. With my L1 RAM size of 16384 bytes, I was wondering if creating 5 objects (for 5 different data paths) would be reasonable.

The object contains pointers to other allocated memory blocks managed internally by EDMA. So, sizeof doesn't capture the complete memory picture. It just gives the size of the pointer.

Is There a Way to Judge Memory Usage?

I'd appreciate any insights on how to effectively judge the total memory "blocked" by these objects. While sizeof provides the header size, it doesn't tell the whole story due to potential memory fragmentation and EDMA optimizations.

Perhaps you could suggest some techniques or tools to monitor memory usage more accurately in this scenario.

Thanks again for your valuable guidance, Cesar!

+1 Cesar 8 months ago in reply to Tanoop Rajan

TI__Guru*** 141644 points

Hi,

That's a great question. When you consider memory requirement, there are two things to consider Program Memory for the code and Data Memory for the data used.

The DSP has several types of memory. L1 RAM is the fastest memory and is used for processing. It is not used for this type of objects. Most of the time L2 memory is used for this purpose.

To understand they type of memory used for the "MmwDemo_populateSRR()", please check first the memory map that is generated after building the demo. Used together with the DSS linker cmd file will help you understand where the Memory used for this Program source code is allocated.

The Memory Map will show you how much memory is not used. This will tell you how much memory is available to add new objects.

Now, regarding the Data Memory used for example by the "MmwDemo_populateMRR()", the function only updates a MmwDemo_DSS_DataPathObj type.

And you can check he size of the object in the Memory Map.

So, for each new object you should be able to estimate the memory required.

Thank you

Cesar

0 Tanoop Rajan 8 months ago in reply to Cesar

Intellectual 291 points

Thank you, Caesar, for such a detailed response. Let me check this out, and I’ll get back to you if the issue is resolved.

Regards

0 Cesar 8 months ago in reply to Tanoop Rajan

TI__Guru*** 141644 points

Thank you

I will close this thread for now.

For new questions please start a new thread

thank you

Cesar

Sensors

Sensors forum

AWR1843AOP: Change data processing path dynamically