IWR1642BOOST: Modified Traffic Monitoring configuration not working

Andrew Chadwick

Part Number: IWR1642BOOST

Hi,

I'm trying to use a modified configuration with the Traffic Monitoring demo code (v2.0 from the mmWave Industrial Toolbox v2.3), but can't get it to work with the desired parameter values.

I used the mmWave Sensing Estimator to generate configuration parameters, based on the long range default values and the following updated inputs:

Maximum detectable range = 140 m
Range resolution = 200 cm
Maximum velocity = 180 km/h
Velocity resolution = 1 km/h

The calculated configuration outputs then include:

Frequency slope = 5.99 MHz/us
Sampling rate = 6208 ksps
# samples per chirp = 78
# chirp loops = 356
Idle time = 2 us
ADC valid start time = 4.20 us
Ramp end time = 17.76 us

And all seems good: "no errors are found".

I then modified the default mmw_tm_demo_longRange.cfg file to update the profileCfg and frameCfg lines as follows:

profileCfg 0 76 2.0 4.2 17.76 0 0 5.99 1 78 6208 0 0 48
frameCfg 0 0 356 0 50 1 0

The configuration loads without reporting any errors, but I get no data messages back. The original configuration works fine with frame results messages at 20 Hz as expected.

By trial and error, it seems there are two problems:

The ramp end time must be greater than approximately 27 us.
The number of chirp loops must be less than 128.

If I modify the profileCfg and frameCfg lines again so both of these are satisfied, I get data as expected. If the ramp end time is less than 27 us, or the number of chirps per frame is greater than 127, it doesn't work. I've tried e.g. increasing the idle time to balance the reduction in ramp time, but that has no effect.

I can't see anything in the SDK user guide or source code that explains this - please can you help?

over 6 years ago

0 Nitin Sakhuja over 6 years ago

TI__Mastermind 30405 points

Hi Andrew,

The Sensing estimator generates chirps which are valid from an RF-Front End perspective i.e. they should not generate mmWaveLink errors as you noticed.

However, the Traffic Monitoring Digital Processing Chain is designed and optimized to process a specific use-case defined by the chirp configuration provided with the demo. A different chirp configuration, while valid for the sensor Front-End, may break the timing or memory constraints of the digital processing thus causing it to fail. You may need to debug and modify the digital processing chain in order to support a different chirp configuration.

Regards

-Nitin

0 Andrew Chadwick over 6 years ago in reply to Nitin Sakhuja

Prodigy 120 points

Hi Nitin, thanks for the quick response.

I can understand that increasing the number of chirps per frame will eventually break a memory limit, but doesn't the Sensing Estimator also check this? The Radar Cube Size for my config is 712 KB which appears to be OK. Reducing the velocity resolution to e.g. 0.9 km/h would increase the cube size to 790 KB, which causes an error - so I am close to the limit, but on the correct side as far as the software indicates. Do I need to change a project setting somewhere to increase the memory available to the DSS?

I'm not clear why reducing the Ramp End Time should affect timing in the digital processing though? The 2 us idle time is the same as for the default long range TM config (which has 3x more samples/chirp) so I assume time taken for data transfer from the front end to DSS once sampling is complete is not a problem? And if the time available for chirp processing is an issue, I would expect increasing the idle time to help? But this does not appear to be the case.

Please could you suggest more specifically where the problems may lie?

I'm also new to debugging with CCS. I've loaded the xwr16xx_ccsdebug binary and can connect to the EVM target and start the software - I can then start up an external terminal to enter a config, while I monitor debug output in the CCS console - but is there a better way to interact directly i.e. send CLI commands from CCS?

Any further help would be appreciated.

Thanks,
Andy

0 Andrew Chadwick over 6 years ago in reply to Andrew Chadwick

Prodigy 120 points

I've investigated these problems a little further, debugging on the EVM. Still looking for a way forward though so further comments would be welcome.

There appear to be two problems with my desired 356 chirps per frame. Firstly, this is invalid as a configuration since the maximum (per mmwavelink.h) is 255. So I reduced it to 255 - but my secondary problem is that this is still too large when trying to allocate the L2 scratch memory for handle->scratchPad in RADARDEMO_dopplerProc_create.

The size of the L2 scratch and heap are defined in dss_data_path.c:

#define SOC_XWR16XX_DSS_L2_SCRATCH_SIZE 0x2500U

#define SOC_XWR16XX_DSS_L2_BUFF_SIZE 0xB000U

But this is only 54528 bytes total out of 256 KB of L2 RAM.

Can I therefore increase the L2 scratch allocation, or will this cause some other problem?

Reducing the chirp ramp end time appears to violate the time required for chirp processing, as Nitin suggested. With ramp end time of 17.76 us and idle time of 2 us, the debug assertion checking the value of chirpProcToken in MmwDemo_dssChirpIntHandler fails. But if I increase the idle time to increase the overall chirp period, it now seems to be OK (not what I found previously but perhaps I had misconfigured something else).

How long is the range processing is expected to take (as a function of FFT size and number of Rx I guess) and therefore what is the limit on minimum chirp period in practice? Are there any examples of using chirp repetition periods ~ 20 us in other MMWave demos?

Thanks for any help,

Andy

0 Former Member over 6 years ago in reply to Andrew Chadwick

Hello Andy,

Yes - you should be able to increase the L2 allocation.

The processing time for this particular chain has not been characterized in such term and limits have not been determined.
In general, if you are interested in seeing some of the benchmark cycle times you can examine the test reports of the SDK processing modules (note however that this is not exactly the same as the processing chain in TM). Located at C:\ti\mmwave_sdk_03_00_00_08\docs\test

Amanda

0 Andrew Chadwick over 6 years ago in reply to Former Member

Prodigy 120 points

Thanks Amanda. Looking at the benchmarks, it looks like 1D processing (windowing and FFT) for a 256-point test vector should take less than 1200 cycles i.e. 2 us, for one Rx. So processing 128-point data for 4 channels as per my configuration should take rather less than 8 us... but I understand this excludes overhead for data transfer and possibly other aspects of the TM chain.

Looking at the reported chirp processing margins, I found that the chirp processing time for my config is typically ~17 us (the margin itself reducing linearly with idle time). I then modified the code to report the minimum chirp margin in each frame, rather than the margin for the final chirp in the frame - and found the minimum margin to be several us less for the first frame only. Debugging further it seems that specifically the SECOND chirp in the first frame takes ~30 us to process, therefore causing the DSS to stall if I try to configure a chirp cycle time less than this. The processing time for the first chirp appears to be within a few tenths of a microsecond of the steady state processing time I observe from the third chirp onwards, and for all chirps in subsequent frames.

This suggests to me that some part of the DSS initialisation is not complete before the DSS starts receiving chirp interrupts. Is this possible? How can I prevent this if so?

Is there any other known issue around timing of the first few chirps after startup (I note that in the TM demo as supplied, minimum and maximum chirp margins are not updated until the chirp interrupt counter is greater than 4)?

Andy

0 Andrew Chadwick over 6 years ago in reply to Andrew Chadwick

Prodigy 120 points

Further to the above - bypassing all 1D chirp processing for the first frame seems to give me a workaround. I can now use the desired configuration with 17.76 us sweep time plus 2.0 us idle time, with a small but consistent chirp processing margin of 1-2 us from frame #2 onwards.

The 1D processing itself appears to take ~5 us. The issue during the first few chirps in frame #1 appears to be additional delay during data transfer and/or waiting for buffers. I'd be interested in any further explanation as to why this can happen, before I mark as resolved, but I seem to have a solution.

Andy

0 Former Member over 6 years ago in reply to Andrew Chadwick

Andy,

Thanks for the information. This is not expected behavior. How did you benchmark the numbers you observed?

The cycleLog structure inside the DSS instance reports the margin information. Using the log info, during our testing and development we did not see this anomaly.

gMmwDssMCB. dataPathObj. cycleLog


/*! @brief DSP cycle profiling structure to accumulate different
    processing times in chirp and frame processing periods */
typedef struct cycleLog_t_ {
    float chirpProcMarginCurrInusec; /*!< @brief average margin for chirp processing */
    float chirpProcMarginMaxInusec; /*!< @brief best margin for chirp processing */
    float chirpProcMarginMinInusec; /*!< @brief worst margin for chirp processing */
    float frameProcMarginCurrInusec; /*!< @brief margin for current frame processing */
    float frameProcMarginMaxInusec; /*!< @brief best margin for frame processing */
    float frameProcMarginMinInusec; /*!< @brief worst margin for frame processing */
              uint32_t dopplerProcCycles; /*! @brief cycle cost for Doppler processing. */
              uint32_t cfarProcCycles; /*! @brief cycle cost for detection CFAR. */
              uint32_t doaProcCycles; /*! @brief cycle cost for DoA. */
              uint32_t dbscanProcCycles; /*! @brief cycle cost for DBSCAN. */
} cycleLog_t;

0 Andrew Chadwick over 6 years ago in reply to Former Member

Prodigy 120 points

Hi Amanda,

My timings were measured using the cycle profiler in the same way.

I added an array to store dataPathObj->cycleLog.chirpProcMarginCurrInusec for every chirp in a frame, and ran in debug to examine this at the end of the first frame.

I then modified the code to report chirpProcMarginMinInusec rather than chirpProcMarginCurrInusec in the frame header, so I could run continuously, having removed the condition that only updated chirpProcMarginMinInusec after 4 chirps have elapsed, i.e.

            //if (gMmwDssMCB.stats.chirpIntCounter > 4)
            if (gMmwDssMCB.stats.chirpIntCounter > 0)
            {
               if (dataPathObj->cycleLog.chirpProcMarginMaxInusec < dataPathObj->cycleLog.chirpProcMarginCurrInusec)
                   dataPathObj->cycleLog.chirpProcMarginMaxInusec = dataPathObj->cycleLog.chirpProcMarginCurrInusec;
               if (dataPathObj->cycleLog.chirpProcMarginMinInusec > dataPathObj->cycleLog.chirpProcMarginCurrInusec)
                   dataPathObj->cycleLog.chirpProcMarginMinInusec = dataPathObj->cycleLog.chirpProcMarginCurrInusec;
            }

This showed that the minimum chirp margin was consistently less than expected in the first frame (specifically, the first or second chirps in the first frame, depending on the chirp configuration) but settled thereafter.

I repeated the tests with the call to radarRangeProcessRun commented out to work out how long the actual processing was taking, and this was consistent from the outset; the additional delay seems to be waiting for data in MmwDemo_processChirp before this call.

Bypassing the call to MmwDemo_processChirp for frame #1 then works fine as a workaround.

Andy

Sensors

Sensors forum

IWR1642BOOST: Modified Traffic Monitoring configuration not working