• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 257 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.

AWR2243BOOST: SubBlock Id = 0x7001 during MMWL_asyncEventHandler

Carlo
Expert 7715 points
Part Number: AWR2243BOOST
Other Parts Discussed in Thread: AWR2243, MMWAVE-DFP

Hi E2E,

Good day.

Our customer is using the AWR2243BOOST with Linux platform using the mmwave DFP version 02.02.00.03. They are using mmwave_example.c  and get 0x7001 as subblock id (sbId) during the call to MMWL_asyncEventHandler during powerOn(). The msgId takes the value 0x380, sbLen takes the value 0x4, payload takes the value 0xb59fde24.

According to the customer, there is no msgId with that value so the code enters an infinite loop and gets stuck, but no error messages The code has been ported to Linux and as they enter the MMWL_asyncEventHandler, implementation of callbacks look reasonable. However, the response seems corrupt.

Your advice is appreciated.

Regards,
Carlo

  • 0
    TI__Guru*** 148804 points

    Hi,

    The SW team will review your question and will get back to you

    thank you

    Cesar

  • 0 in reply to Cesar
    TI__Expert 7715 points

    Hi Cesar,

    I received another update from our customer. After shortening the timeout, the error code is mmWave Device Power on failed for deviceMap 1 with error -8, which corresponds to API timeout. The msgId continues to be corrupted.

    msgId is 0x380U (RL_MMWL_ASYNC_EVENT_MSG)
    asyncSb is 0x001 (RL_MMWL_AE_INTERNALERR_REPORT)

    Kindly advise in solving the error. Thank you.

    Regards,
    Carlo

  • 0 in reply to Carlo
    TI__Guru 69960 points

    Hi Carlo,

    Looks like this is AWR2243 ES1.0 device so with that at the bootup AWR sends few Fault async event message which Host needs to discard during AWR bootup time. (refer <mmWave_DFP>\docs\mmwave_dfp_user_guide.pdf : section 9.1)RL_MMWL_ASYNC_EVENT_MSG

    Could you ask them to refer C:\ti\mmwave_dfp_02_02_00_03\ti\example\mmWaveLink_SingleChip_Example which exemplies the usage and implementation of mmwaveLink on the Host Processor. Make sure that all the mmWaveLink callbacks are implemented correctly at Linux PC/Host.

    refer this document on Host Porting steps   <mmWave_DFP>/control/mmwavelink/docs/doxygen/html/index.html#proting_sec

    Now, above error RL_MMWL_AE_INTERNALERR_REPORT can come when rlOsiMutexLock callback returns non-zero value (mmwavelink\src\rl_driver.c: rlDriverMsgReadSpawnCtx function). Ask customer to check rlOsiMutexLock callback implementation.

    Within DFP they can refer Non-OS implementation of this callback

    <mMWave-DFP>\ti\example\mmWaveLink_SingleChip_NonOS_Example\rl_nonos.c

    Regards,

    Jitendra