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.

TPS6594EVM: Hardware not connected - Scalable PMICs GUI

Part Number: TPS6594EVM

I am experiencing difficulties connecting the TPS65941111EVM with the "Scalable PMICs GUI 3.0.0" on my Windows system. I am using the offline version for Windows with gcruntime 11. Upon plugging in the USB cable, I observe two new COM devices in the Device Manager and one unrecognized "Virtual COM port" without a driver. When I have the "Device Settings" window open in the GUI, this is the output I receive in the console:

COM4 and COM6 are consistently present on my PC. It appears that the software attempts to connect with COM4, but COM7 is actually the correct port. Although I managed to connect a few times previously, I am unable to do so again.

On a Linux virtual box machine, I encounter an error stating "Controller is not responding," although this is likely due to the virtual machine environment. Below I attached a screenshot of the console and the error message.

The only physical alteration on EVM I have made is connecting V3V3 to VSYS on J15. Power is solely supplied through USB.

  • Hello Adam,

    I know this might sound silly, but could you make sure that the VIO selection (J30) has a jumper on it and see if it works with 3V3?

    Here's the EVM User's guide if you don't already have it on hand: CLICK HERE FOR EVM USER'S GUIDE

    The connection in the lower left hand corner of the GUI is to denote if the MSP432 (Microcontroller on EVM) is able to establish a connection via I2C or SPI (depending on configuration from GUI). Once the acknowledgements have been received the lower left corner will say, "Hardware Connected"

    So the issue here may not be the COM PORT, but the jumper settings on the board, but I'm trying to rule that out first.

    Make sure you're using the ACCtrl device when in windows.

    BR,

    Nicholas

  • Just to add, I see that in the javascript that the timeouts are occurring as well for the MSP.

    Please try using the ACCtrl first and let me know what you get.

    Thank you!

  • Yes, tests were conducted on both Linux and Windows with 3.3V selected on J30. This is how it was when I received it.

    Yes I have read the User Guide.

    When unable to establish a connection, I'm unable to select any port from the "Select Port:" menu under "Device Settings" in Windows. When I can establish a connection, menu automatically shows "COM7 (Microsoft)" like on screenshot below and there is no other option. This behavior occurs because the GUI application checks for the correct port and only displays that port in the menu.

    I've observed that in my case, the COM port appears differently compared to the screenshot you provided.


    I'm completely confident that if I removed the "if" condition at line 453 in the file "ti-tpslp-main.html.js" while retaining the call to "_autoDetectPortIdentity," the issue would be resolved without any complications and consistently.

    I'm not interested in solving the issue on Linux as it's probable that the error may be caused by the virtual machine. I've only showcased it to provide additional information.

  • Hello Adam,

    I saw in the other thread that you were able to program the PMIC which means the connection was successful.

    If you don't mind telling me ultimately how you were able to solve this connectivity issue with the microcontroller in either Linux or Windows?

    BR,

    Nicholas

  • As I mentioned earlier, I was able to connect a few times in the past. However, it's now highly unlikely to occur. I believe the issue stems from a combination of my PC's configuration (including two additional COM ports and a different driver) and the application's behavior.

    In my view, the application isn't even attempting to connect to the correct COM port. I could attempt to verify this by altering the behavior, but I'm uncertain whether this would be permissible under the license agreement.

    I suspect the Linux application corroborates this hypothesis since it consistently displays the correct COM port, as it's always "the first one" on the Linux VM. This further confirms that the board is fully functional.

  • Thank you for the feedback on that Adam,

    it's much appreciated!

    Odd how it identifies itself as different devices, but that would make sense given different drivers.