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.

IWR6843ISK: cannot recieve data on MCU

Part Number: IWR6843ISK
Other Parts Discussed in Thread: IWR6843, , UNIFLASH

Hi there,

We are using IWR6843 in a project with the 3dpeople_counting demo. The measurement data is transferred via F14 pin of the chip and to a local pc's COM port through a cp2105. We modified the Baudrate of the demo to 115200 so that the MCU we want to apply for data processing can handle the speed. After some tests on the pc, we are sure the baudrate is appropriate and the data can be recieved by the COM port of the pc without problem. However, when we switch to the MCU and connect the same pin F14 to its Uart pin, no data can be recieved by the MCU. At the moment, we cannot figure out what the problem is.  Have we missed something. Could you give some tips?

thx

Shen

  • Hi Shen,

    Thank you for reaching out with your question.

    Are you using the IWR6843ISK with the MMWAVE ICBOOST Board https://www.ti.com/tool/MMWAVEICBOOST to access J14 which if I am understanding correctly is the MSS Logger pin or are you just using a standalone IWR6843ISK?

    Thanks,

    Alex Chan

  • Hi Alex,

    Thanks a lot for your reply. Here are some words describing the hardware we are using. Based on IWR6843ISK, we disigned and fabricated a module that is almost identical to original iwr6843isk using offical designing guides provided by TI. The data transmission pin we are using is pin F14 which serves as MSS_UARTB_TX defined in pin attributes written in iwr6843's official document and actually ithe module works well if we attach pin F14 that is directly pulled from the chip to a cp2105 which converts uart to usb and monitor the data transmission via COM port on a PC. Problem occurs when we attach the F14 to the recieving pin on our MCU (i.e. ESP32). There is voltage variation on F14,but the MCU doesn't react to it. Somehow confused by the situation. Is there anything to do with the pull down resistor of F14? since F14 is connected to a pull down resistor before to the cp2105, but no resistors are between F14 and the MCU. Any advices on how we can pin down the problem?

    thx & regards

    Shen

  • Hi Shen,

    Thank you for providing more information on the issue. I am reaching out to some other people on my team and will get back to you as soon as possible. Thank you for your patience.

    Thanks,

    Alex Chan

  • Hi Shen,

    I apologize for the late response due to the holidays and I was waiting for a response from someone else on the team. 

    Please see some of the following recommendations. 

    Below are the possible pointers:

     

    1. Possible causes are right Baud rate setting need to be present on the both sides of the UART ports.
    2. Improper connection: Our Device Tx UART pin need to be connected to Rx UART pin of the MCU device. Connectivity circuit diagram would help to understand it better.
      1. Need to understand how is the boot modes are asserted and how is the configurations are sent to device i.e. how is the RS232_TX/RX are driven? Is it also MCU?
    3. Incorrect power up sequence: There is a caution on the using external I/Os, Please see attached VIO note.
      1. External MCUs should be connected only after device is booted and SOP configurations are asserted.
      2. If MSS_logger is connected during the power on reset when VIO goes to zero, there could be chance that I/Os are driven externally through the MCU causing incorrect booting of the device.
    4. Incompatibility with UART port: Try changing different UART port.
      1. For example, CP2105 has two UART ports, MSS logger was not working with enhanced COM PORT using UNIFLASH tools, after changing to regular COM PORT it started working.
    5. UART driver code issue:
      1. Need to check the UART driver code how it’s written, Interrupt routines checks, UART buffer checks e.t.c checks need to be done on the MCU side

    Thanks,

    Alex Chan