• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 305 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM2732: HWA stand-alone configuration: stuck in "RUN" mode

Maximilien B
Prodigy 115 points
Part Number: AM2732

I am trying to make HWA work in standalone mode (without EDMA or any other input / output trigger).

All of the configuration seems to go well, but inspecting the debug register shows the HWA stuck in "RUN" mode (0x3) on thread 0:

  • current paramSet index is correct (=1)
  • numLoops is correct (=1)
  • software trigger / immediate behave correctly (when no trigger is applied in software trigger mode, the state machine stays in "WAIT TRIGGER" mode 0x2)
  • trigStatus is {0,1}

The start-up sequence seems correct and conforming to specification (using the HWA V0 driver library provided with the MCU+ SDK). In particular, the proper calls to HWA_Init, HWA_reset, enable, and configuration calls have been done. The paramSet configuration is as follows:

  • accelMode = FFT, triggerMode = SOFTWARE
  • src and dest complex 16-bit signed, scale = 2
  • fftSize = 4, butterflyScaling = 0
  • srcAcnt = 255, srcAIdx = sizeof(uint32_t), srcBcnt = 0
  • dstAcnt = 255, dstAidx = sizeof(uinit32_t)
  • All other parameters are 0

The memory banks do not get modified in any way (output bank is only zeroes, input bank is zeroes except for input values).

What could cause the HWA to be stuck in RUN mode forever, apparently doing nothing ?

  • 0
    Prodigy 115 points

    I was able to successfully rebuild the standalone example using the HWA example in the MCU+ SDK, stripping the EDMA-related code and changing parameters to obtain the required configuration.

    (This does not solve the issue of the stuck HWA, I will post findings if investigating further on the issue)

  • +1 in reply to Maximilien B
    TI__Mastermind 20605 points

    Hi Maximilien,

    One instance where this has been observed on the FFT engine is if the FFT size is less than number of input samples. The FFT length is supposed to be equal to or greater than the number of input samples (does automatic zero padding). Looking at you FFT size (2^4 = 16) and SRCACNT = 255, this seems to be an issue, right? The minimum size of FFT you can use with SRCACNT=255 is 8 (2^8 = 256).

    Regards,

    Kaushik

  • 0 in reply to Kaushik Gowda
    Prodigy 115 points

    Thank you for your reply.

    Absolutely, the parameter was overlooked and numDopplerBins (=16) was used instead of "numFFTBins" (which has the correct value in rangeprochwa.c:711 in the mmWave MCU+ SDK):

        hwaParamCfg[paramsetIdx].accelModeArgs.fftMode.fftSize = mathUtils_ceilLog2(pDPParams->numFFTBins);