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.

AWR1843AOP: Regarding AWR1843AOP in TI tool mux

Part Number: AWR1843AOP
Other Parts Discussed in Thread: AWR1843, AWR6843

Tool/software:

Hi TI,

In our application we are working on CAN protocol . We want to know the Pinmux for CAN pins of Awr1843AOP. In the TI tool mux only AWR18XX is present, can we use the same for AWR1843AOP also or please provide the tool mux for AWR1843AOP?

  • Hi Rashmika,

    No, the pin mux is different between AWR1843 and AWR1843AOP.

    For the pin mux details of AWR1843AOP, please refer the Pin Attributes table in the datasheet: https://www.ti.com/lit/ds/symlink/awr1843aop.pdf

    Thanks.

  • Hi Ti,

    Please provide the header file for AWR1843AOP (Pinmux_AWR1843AOP.h).

  • Hi Rashmika,

    Please download the mmwave_sdk_03_06_02_00-LTS from MMWAVE-SDK Software development kit (SDK) | TI.com. After installing, you can find the pinmux_xwr18xx.h file at "C:\ti\mmwave_sdk_03_06_02_00-LTS\packages\ti\drivers\pinmux\include". This pinmux header file also has the pin details of 1843AOP.

    Thanks.

  • Hi TI,

    We changed the code from CAN-FD to CAN. Then changed the pinmux from CAN-FD to CAN i.e from F2 and D1 (J8) to  C2 and D2(J10) pins of AWR1843AOP EVM. It is not giving data on J10.

  • Hi Rashmika,

    Can you confirm whether S2.1 pin is ON at the AWR1843AOP EVM?

    For more details on pin settings, you can refer to www.ti.com/.../spruix8.pdf

    Thanks.

  • Hi Rashmika,

    I hope your issue is resolved. 

    If this issue is not resolved, then kindly let us know if you need any further support from our side on this issue.

    Thanks.

  • Hi Voona, 

    Yes, the PIN S2.1 is ON.  We followed the attached document on CAN.But still not getting CAN on J10.

    www.ti.com/.../spracg9.pdf 

  • Hey Rashmika,

    Do you mind sharing your CAN code for initializing the driver? Alternatively, I would also recommend reviewing the code from the prebuilt unit test binary for the CAN driver. You can find the main.c file under <MMWAVE_SDK_INSTALL_DIR>/pacakges/ti/drivers/can/test/common.

    Documentation for using and building the test binary can found under the mmWave SDK User Guide (<MMWAVE_SDK_INSTALL_DIR>/docs/mmwave_sdk_user_guide.pdf), Sections 3.5 and 4.5.4 respectively. There is also the mmWave SDK Unit Test Procedure document in the same folder as the user guide which gives some simple information on each test binary, though I would recommend reviewing the code instead.

    Regards,

    Kristien

  • Hi TI,

    We are trying to implement the  CAN_transmit_schedule function  in OOB. Then we did debugging using MMWAVEIC BOOST. We got the below error.This error occurs when we call CAN_transmit_schedule function in MMWDemo_transmitProcessedOutput function of mss_main.c in OOB. Can you suggest how to fix this error. 

    The line 429 code of objectdetection.c is attached as below.

    It is understood that the processing of previous frame is going on. But the RF front end started the next frame. How to fix this error?

  • Hey Rashmika,

    This error is usually caused by not power cycling the board which fails to reset the RF front end. Power cycle the board by disconnecting and reconnecting the power cable before reloading the program in CCS.

    It also sounds like your application is similar to an existing example in the Radar Toolbox, the CAN Integration project. This example is built for the xWR6843AOP to send detected points and other information over CAN using the OOB demo as a project base. There are a couple notes on usage and functions of the CAN driver in the CAN Integration for SDK 3 Devices section that might be useful.

    Regards,

    Kristien

  • Hi TI,

    I implemented the AWR6843 Can integration in AWR1843AOP.  I am facing the below issues. Can you suggest how to resolve these issues.

  • Hey Rashmika,

    What did you add to the mss_main file for this project? Some of the warnings shown seem to indicate that there are some new DPC functions and sections declared that normally aren't in the mss_main file, such as MmwDemo_dataPathObjInit and .DPC_objDetTcmbHeap. These are included in the 6843 CAN example since that project does not utilize the DSP for processing, so processing is included only on the MSS side, but for the OOB 1843 project, the DSS is utilized.

    You should only need to copy over the CAN variables, macros, and functions mentioned in the "CAN Integration for SDK 3 Devices" section. If you want to know the exact code changes needed, you can diff the OOB main.c file for 6843 and the CAN integration main.c file for 6843. Note you still need to follow the linking steps described in the application note the CAN integration example is based on.

    Regards,

    Kristien

  • Hi TI,

    I implemented the CAN integration in OOB of AWR1843AOP as you suggested. Now it is building DSS as well as MSS without any errors. But, while debugging this using MMWAVE IC Boost, I am facing the terminating execution error. Please find the attached screenshot of the error. In the error it is showing {module#44}: line 205: error {id:0x1a0000, args:[0x167e0, 0x101d3]}.  What does this line means? What is the meaning of {module#44} ? Where we can find this {module#44}?

  • Hey Rashmika,

    Just a heads up, most of our engineers will be out until July 8th due to a United States holiday. If you have any updates or questions, please hold off on replying until next week when we can respond to you then.

    For now, your best bet is to load and run the program in the CCS debugger and check the call stack upon failure. It may be possible that there is an issue in the configuration being sent to the device which is causing the sensor to fail.

    For example, if you were to use the projectspec for the CAN integration example and change only the pinmuxxing to match 1843 instead, there is good chance it will still fail since the example uses a hard coded config (HCC) that is for 60 GHz starting frequency instead of 77 GHz.

    Regards,

    Kristien

  • Hi TI,

    I have used MMWave sdk version of 3.6.0.0 and CCS version is 12.6. 

    Ti Reply:

    You should only need to copy over the CAN variables, macros, and functions mentioned in the "CAN Integration for SDK 3 Devices" section. If you want to know the exact code changes needed, you can diff the OOB main.c file for 6843 and the CAN integration main.c file for 6843. Note you still need to follow the linking steps described in the application note the CAN integration example is based on.

    I followed the same steps as you mentioned above. i.e difference between OOB main.c for 6843 and CAN integration main.c for 6843 is implemented in mss main.c for AWR1843AOP OOB code. After implementing compile time errors vanished, but while debugging with MMWave IC BOOST the below error comes. 

    Please suggest how to fix this error of module#44.  Please give reply for where to check module#44? what is module#44?

     

  • Hi,

    Please allow us until next week to respond.

    Regards,

    Tim

  • Hi Ti,

    Ok. Please give reply as soon as possible.

    Regards,

    Rashmika

  • Hey Rashmika,

    I have not been able to determine exactly what is causing the XDC runtime error, but you can scrub through the XDCtools User Guide if you would like to learn more about error handling. Unfortunately, I have not been able to find if the user guide specifes what this error might be associated with. 

    As I recommend before, the first steps you should take to debug is to check the call stack after failure by pausing the CCS debugger. It might throw you directly into a fault of some kind which may not traceback to the original function or statement that caused the failure. In that case, you should place a breakpoint after the MMWave_start function and step through line-by-line until failure. 

    If you could post an image of the call stack and code line that causes failure, then we might be able to identify the issue and propose a solution, but for now, we need more information about those two.

    Regards,

    Kristien