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.

CCS/IWR1443BOOST: Difficulty receiving data over serial. Can access memory (capture demo) but cannot receive streamed data (mmwave demo/vitalsigns lab). Self-built device.

Part Number: IWR1443BOOST
Other Parts Discussed in Thread: TM4C1292NCPDT, UNIFLASH, IWR1443

Tool/software: Code Composer Studio

Hello everyone,

I am having some difficult receiving data over UART from a self-build of the IWR1443BOOST. The problem I am having is as follows: I can transmit (CFG) to the sensor, but receive (DATA) is not working completely (although it does to some extent). We think the problem might be due to the change in microcontroller to TM4C1292NCPDT, but would appreciate some suggestions on this.

To elaborate, when I run the mmWave demo (or vital signs lab), I can send config files but data from the chip is not sent back. Therefore, the mmWave visualizer always shows the message ‘waiting for data…’, and for the vital signs gui, nothing is received. However, I also note that when I run the capture demo I can access data from memory (and download it, which shows that the radar is indeed working correctly). So I at least know that the chip and memory are functional, and the serial port is working, albeit not for data streaming.

Without bogging the post down with too many details:

The build was made using TI-provided schematics. I also have a version bought from TI, which works perfectly well, so the problem is with the ‘home-made’ version.
There are a few minor differences to the build (based on product availability): memory is larger (I don’t think this is an issue), and microcontroller is the TM4C1292NCPDT rather than 1294 model. Could the problem be due to pin differences between the two models (further deltails below)?
The serial connection initially showed as ‘Stellaris’, but I managed to flash the bootloader and firmware, so the ports show up as XDS110.
Uniflash was used to flash the rss and mss .bin files.
CCS is used for debugging (using SDK 1.1.0.02 and the latest mmWave industrial toolbox 2.0).
One issue that we have identified with the TM4C1292 is that the following signals have a different state due to the slightly different pin arrangements for certain signals. There are two differences:

UART Module 1 Data Terminal ready (pins 12 and 111 on the 1294) is left floating on the 1294 but is grounded on the 1292, since this signal is at pins 12, 58 and 111.
UART Module 0 Ring Indicator (Pins 60 and 71 on the 1294) is pulled high via a 1k resistor on the 1294, but is pulled low on the 1292 (pins 59 and 71) through the 4.87k resistor at pin 59.

Let me know if there’s any other info needed.

  • Hi Khalid,

    I have a few questions for you in order to start the debug process.

    The current Vital Signs demo uses the mmWave SDK 1.0. Have you installed this? Has the .xer4f compiled properly for you? Download link is here: software-dl.ti.com/.../index_FDS.html

    Have you tried your new board with any other firmware? I'd highly recommend trying with the Out of Box Demo Firmware included in the mmWave SDK. If it still doesn't work then we can confirm that there is a problem with the hardware on your board and not the firmware.

    Lastly, can you confirm that you see two COM ports in your Device Manager? (one for Class Application UART and one for Auxiliary Data)


    Cheers,
    Akash
  • Hi Akash,

    Thanks for your quick reply. See below for my responses.

    Akash Gondalia said:

    I have a few questions for you in order to start the debug process.

    The current Vital Signs demo uses the mmWave SDK 1.0. Have you installed this? Has the .xer4f compiled properly for you? Download link is here: software-dl.ti.com/.../index_FDS.html 

    I haven't tried this yet, but I'll do so tomorrow when I'm back in the office. However I'm doubtful it will help, as the problem also occurs with the mmWave demo (using the web-based visualizer gui).

    Akash Gondalia said:

    Have you tried your new board with any other firmware? I'd highly recommend trying with the Out of Box Demo Firmware included in the mmWave SDK. If it still doesn't work then we can confirm that there is a problem with the hardware on your board and not the firmware.

    Yes I have tried it with a the Out of Box Demo Firmware, as well as the CCS version (basically, both versions in the SDK user guide). The same problem occurs in both cases. I would probably agree with you that it is a hardware issue. Do you think that the use of the TM4C1292NCPDT microcontroller could be an issue? As detailed in our other post, there are some differences with pin assignments, compared to the 1294.

    We actually used the 1292 because the 1294 was out of stock (it seems to be extremely popular!). An earlier post said that it would work as a like-for-like replacement, but we've since noticed a few differences.

    Akash Gondalia said:


    Lastly, can you confirm that you see two COM ports in your Device Manager? (one for Class Application UART and one for Auxiliary Data)

    Yes this works fine (both XDS110 after flashing the relevant bootloader and firmware).

    Thanks again for your help.

  • Hello,
    The XDS110 has specific connectivity, with the mmwave sensor, and the USB on the PC.

    Differences with the TM4C will not be easy to debug in the mmwave forum, we can try, but this should be brought up in the Embedded Processor forum, with your specific schematic.

    Normally in our use case there is a specific set of firmware that is flashed onthe TM4C first. This is expecting the IO to match the device to the board. If Uniflash worked, this means that the ControlTx UART, and ControlRx UART are working.

    The MSS_Logger is the data UART that is used for the return Rx data from the mmwave Sensor. The 2nd UART channel is supposed to be connected to pin PC4 the net name is AR_MSS_LOGGER, install R136, remove R135. Note: you need to make sure only the MSS_LOGGER is connected.

    So it looks like PA0 (AR_RS232Tx), and PA1 (AR_RS232Rx) works. So you need to make sure the pinmux allows PC4 to be a UART receiver.
    You need to get the source code for the XDS110 for your part and see where the serial port that was pin 25 PC4, is routed to.

    You should ask for the XDS110 source code over E2E (this is not in our group) for your processor, and trace through the 2nd UART (25@PC4) for
    TM4C1294 equivalent for your processor. Also you need to go through the PinMux utility.

    Regards,
    Joe Quintal
  • Hi Joe,

    Thank you for your reply and your help with this. I'm working with Khalid trying to resolve this small issue we are having.

    I have checked the AR_MSS_LOGGER and AR_BSS_LOGGER nets, and have verified that the resistors are in the correct places. Pin 25 (PC4) is the same on both the TM4C1292 and the TM4C1294, so I would imagine that it would be the same in the pinmux?

    The only pins on the 1292 and 1294 processors which appear to be different are pins 51 - 60. We have directly inserted the TM4C1292 into where the TM4C1294 should be. This doesn't appear to be a problem for any of these pins except for Pin 59, which on the TM4C1292 is the "UART module 0 Ring Indicator modem status input signal". Since pin 59 on the TM4C1294 is RBIAS (which is grounded through a 4.87kOhm resistor), it means that this Pin 59 on the TM4C1292 is now being pulled low. The equivalent Ring Indicator pin on the TM4C1294 is pin 60, which is pulled high to 3.3V through a resistor.

    Would the fact that the UART module 0 Ring Indicator is being pulled low prevent the ability to stream data from the IWR1443 through the TM4C1292?


    Thank you once again,

    Peter
  • Hello Peter,

    I think you need to ask in the XDS110 forum,  to get the source code.

    You should then trace with CCS for XDS110, the code to see if the UART data is being received.  

    When you look at the PC, I assume the XDS110 COM ports under Windows have a Control (which works) and Data (which is not working).

    You can also try changing the baud rate from 921600 for the data UART.

    I don't know what is blocking the UART to USB transfer,  if you have an oscilloscope , and you run a visualizer example, you should see activity on the MSS_LOGGER input to the XDS110 processor.  If you have a UART adapter, this 3.3v Tx UART should receive bursts of data, the code example for the mmWave SDK demo, should have a UART setup command, so you can see the format.

    Here is what I see with a mmWave Sensor EVM, connected over USB, and powered at the PC, Win7 System, Device Manager

    Ports (COM & LPT)

       ECP Printer Port (LPT1)
       XDS110 Class Application/User UART (COM23)
       XDS110 Class Auxiliary Data Port (COM24)
    The MSS Logger is COM24.

    Regards,

    Joe Quintal

  • Hi Joe, 

    Sorry for the slow reply, and thanks again for your help. 

    I will make a post and see if I can get hold of the source code for the XDS110. 

    Both COM ports are present in the device manager, and both appear to be functional (i.e. windows doesn't think there's a problem). I've tried various different baud rates with no success though. I haven't managed to get the board onto an oscilloscope yet, but hopefully I will have a chance this week to do that and will you post the results if there's anything meaningful. 

    Thanks once again, 

    Peter