Other Parts Discussed in Thread: LP87642Q1EVM, TPS2052B
This development board has been working for a few weeks, it is used only to provide I2C interface to a support Scalable PMIC projects.
Now neither USB port functions although power is on.
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.
This development board has been working for a few weeks, it is used only to provide I2C interface to a support Scalable PMIC projects.
Now neither USB port functions although power is on.
Hi,
Do you see power LED light?
Do you remember what had happened before the board became not working?
How do you connect the board to your I2C slave? Do you connect to the slave through a connector?
Hi,
The XDS110 side now appears to be working, but the MCU side USB does not.
I am using the default link positions; MCU powered from the XDS110 side (5V & 3.3V).
The MCU 3.3V (TP13) & 1.2V (TP12) rails are good,
MCU TARGET_VBUS (TP4) = 5.071 (directly connected to PC or 5.24V when using an external powered HUB).
The impedance from TARGET_VBUS to ground is 75K. TARGET_VBUS goes to U2 TVS diode then MCU PB1 (designed for 5V) & USB OTG switch.
I purchased a second development board, downloaded PMIC I2C interface firmware (3073.aevm_1_0_3_6.hex) and connected the 2 USB ports. The MCU side was now seen ok on this one (yay).
The impedance from TARGET_VBUS to ground was 240K, so significantly higher.
After disconnecting and reconnecting the new board a few times, it too fails USB port no longer functions.
The impedance of TARGET_VBUS to ground is now 200K. So maybe ok?
Have not been able to use the second board for development, so TSTO, I have 2 bricks and no progress.
Both are now the same: XDS110 side works, nothing from the MCU.
I will leave them unpowered for a while and then see if my selection of PC's/USB cables can magically connect tomorrow.
BTW: As backup and In contrast, I have had no problems using a NanoPI Neo Air module. It has been connected to the PMIC, I can use Python to read registers but obviously cannot use it to connect to PMIC GUI.
I am wondering what the specifications are on the TARGET_VBUS detect pin PB1 on the processor - datasheet does not state it! - It states it can take 5V but, this would be applied before the chip powers up with 3.3V and what upper limit?
Thanks for your help.
Steve
Further probing (From schematic):
Scope shows XDS110 USB signaling looks good and it functions.
MSP432 USPD_P low . . . typically with USB, the DP pin has a pullup,
With no cables plugged in, & both XDS110 and MCU powered up (using external 5V & internal 3.3.V regulator) & with both TARGET_VBUS and DEBUG_VBUS also at 5V, the XDS side has XDS_DP high (>3V) as expected, but the MSP432 side USBD_P is still at 0V. Also measured at MCU pin 94 (PL6).
Dev board 5V input is at 153mA crystal is running ok at 25MHz - nothing else connected.
Would be useful to have some LED action with this code (3073.aevm_1_0_3_6.hex)
So, the MSP432 USB peripheral is not functioning. Both boards have same fault.
Not sure what to do next with these boards, the MSP432 dev kit design/MCU appears to be very fragile in some way.
BTW:
End use is to program LP876411 PMIC chips from Scalable PMIC GUI, I've had some good success, but need the dev boards to be functional a little longer.
Ideally, I would use an LP87642Q1EVM module, so if anyone has one to sell, let me know.
Alternatively, if PMIC GUI could use alternative standard USB to I2C bridge, that would be productive, but for now, I am hacking in Python from my trusty NanoPi Neo.
Hi Stephen,
Can you show a picture of your connection between the LaunchPad and the rest of other boards/devices? If you have two boards all going bad after few times of usage, I kind of suspect what the LaunchPad is connected to.
I will be travelling in the next few days. Please expect delay on my response.
Thanks Charles.
I have given this a bit more thought for causality and any clue . . .
The XDS110 end is only needed to power up the board 3.3V regulator (via DEBUG_VBUS) required by the MSP432.
If power is routed through (using J6) from the MSP432 end to the XDS110 then only the MSP432 end is needed.
So simply connecting the TARGET_VBUS & DEBUG_VBUS can do this (both links installed).
So, linking the 2 VBUS lines is a logical thing to do (if your short of USB ports).
Q: How can that action damage the MSP432 USB.
Perhaps there is some other more subtle effect that can happen when doing this, (from the schematic, it’s not obvious)?
Thanks for your support.
P.S: A VBUS to 3.3V regulator for the MSP432 side is something I would vote for.
Thanks Charles.
I have given this a bit more thought for causality and any clue . . .
The XDS110 end is only needed to power up the board 3.3V regulator (via DEBUG_VBUS) required by the MSP432.
If power is routed through (using J6) from the MSP432 end to the XDS110 then only the MSP432 end is needed.
So simply connecting the TARGET_VBUS & DEBUG_VBUS can do this (both links installed).
So, linking the 2 VBUS lines is a logical thing to do (if your short of USB ports).
Q: How can that action damage the MSP432 USB.
Perhaps there is some other more subtle effect that can happen when doing this, (from the schematic, it’s not obvious)?
Thanks for your support.
P.S: A VBUS to 3.3V regulator for the MSP432 side is something I would vote for.
Measurements: Using a scope, this is the effect of powering the MSP432 with:
(NOTE measurements made on 2 failed boards - with identical results)
Both boards failed under condition 2. Here the MSP432 PB1 (TARGET_VBUS detect) pin gets (typically) a 7.5V peak with no power.
Condition 3 shows that a lower impedance cable has less overshoot to the MSP432 (6.4V).
So.
PB1 has been designed to be 5V tolerant so maybe avoids a substrate diode to VCC.
IMHO, the MSP432 USB OTG power requires: an input filter and/or polyfuse and a series resistor to PB1.
Digging deeper, this from the System design guide:
Paragraph 2 is not implemented on this dev board, please consider at least adding the 100R resistor - clearly not just for ESD.
Preferably: I would have a PI filter on the USB input to limit in-rush etc. and a 3.3V regulator close to the MSP432.
Please consider my research and offer effective course of action.
Many thanks, regards,
Steve
So simply connecting the TARGET_VBUS & DEBUG_VBUS can do this (both links installed).
So, linking the 2 VBUS lines is a logical thing to do (if your short of USB ports).
Hi,
Can you elaborate what you meant by connecting TARGET_VBUS and DEBUG_VBUS together? Do you mean you put a jumper between 3 and 5?
By default, the board is powered through the Debug USB port with a jumper between 5 and 6. You can power the board from the Device USB port by using a jumper between 3 ad 4. Please refer to the LaunchPad user's guide for details. https://www.ti.com/lit/pdf/slau748
2.1.6.4 Other Headers and Jumpers JP1 is provided to select the 5-V power input source for the Ethernet LaunchPad development kit. The left position is for BoosterPack plug-in module power; this position also disconnects both USB voltages from the board’s primary 5-V input. In the left position, the TPS2052B does not limit current so additional care should be exercised. The middle position draws power from the USB connector on the bottom of the board near the Ethernet jack. The right position is the default, in which power is drawn from the XDS-110 USB connection through J101. If JP1 is in the left or middle position, which selects the BoosterPack headers or the USB OTG connector, respectively, externally provide 3.3 V to the board, and remove the 3V3 jumper on J101.
Hi,
There is only one way to power the MSP432 and evaluate it as a USB powered device i.e. from only the USB OTG connector end (one cable), no XDS110 cable or external power.
From JP1 above:
The schematic is quite clear and it looks like the MSP432 is designed for these kinds of applications.
To the problem . . .
It looks like the USB cable inductance is sufficient to cause an overvoltage at the USB_OTG port VBUS pin (>7V see above). A high quality USB3.1 cable is better but apparently the TVS protection is not effective in this case.
Plan:
I have ordered 3rd MSP432 Dev board and some spare CPU's.
For now, I'll have to use a USB hub and 2 ports to continue my projects LP876411 development (hopefully not destroy that board too)..
Meanwhile, I'll swap out the MSP432's on the failed boards (to confirm the theory), then add current limiting resistor to the PB1 (VBUS sense) input to guarantee compliance to <64mA specification (AMR).
Once that's done - you know I will see if it fails in the single "USB powered device" configuration.
I'll post results.
- Put a jumper across 3-4, this applies TARGET_VBUS 5V to VBUS rail.
- Put a second jumper across 5-6 i.e. VBUS rail to DEBUG_VBUS, this powers the XDS110 side's 3.3V regulator needed to power the MSP432 (without external power).
- 5V Power goes from USB_OTG up to the XDS110 through regulator, then back down to the MSP432. This is how any standalone MSP432 will get power, as a "USB powered device".
So you put two jumpers with one across 3-4 and another across 5-6? I still don't understand your purpose of doing this. You should only place one jumper across one of the three selections.
Please also be aware that PB1 can only take 5V when in USB mode. When not in USB mode, you should not have 5V on PB1 pin.