MSP432 chip heats up quickly on Power-On

It's not visible what else you did to the board - perhaps you didn't even realize. So this is merely speculation.

Check carefully for short circuits or conspicuous components (brown, blackened). If nothing turns up, you have probably killed it with ESD, or connecting it to a dangerous voltage (overvoltage or reverse polarity).

If the MCU gets hot, I suspect a GPIO protective diode burned through, and is short-circuiting VDD ...

Hello f.m.
thanks for your speedy reply.

1) i didn't notice any damaged components so far...i also checked the current directly across the 3.3 V Pins and it measured 400 mA with 3.3 V. Is that a lot more than the maximum allowed or still within range?

2) the board still works, i can load programs and get them to run....just very often the JTAG Communication Error pops out and the chip heats up to an uncomfortable level very quickly.

What do you mean by reverse polarity exactly?

3) I've read that the C125, which is connected to the voltage regulator, is very touch sensitive (although in the newer msp432 boards, according to slau597b, this capacitor has since been removed). Could that really be the issue here? Because I am pretty sure my hands have come in contact with the capacitor upon insertion/removal of the usb cable.

4) I assume the way to test out your last sentence is by setting all the pins to low and see if any of them still goes high?

I don't know that specific board - but basically, it is a evaluation board like many others.

400mA seem really much to me - this seems like a short-circuit current limitation of a power supply circuit. I'd would check with the user manual, but this seems unhealthy. Have you checked the supply voltages (also intermediate one's and on the MCU) ? Don't forget to ground yourself before/while measuring...

2) the board still works, i can load programs and get them to run....just very often the JTAG Communication Error pops out and the chip heats up to an uncomfortable level very quickly.

Could it be that some operation (switching a GPIO with attached circuitry) causes the overload ?

Perhaps you can single-step through the code, and pinpoint a location causing the issue.

Posting the the schematics (if anything was modified) would help, too.

What do you mean by reverse polarity exactly?

Applying a low/medium negative voltage (e.g. 3V .. 5V), often by interchanging the supply / ground pins. MCUs don't handle this well, the max. allowed negative voltage on any pin is usually a few hundred millivolts.

3) I've read that the C125, which is connected to the voltage regulator, is very touch sensitive (although in the newer msp432 boards, according to slau597b, this capacitor has since been removed). Could that really be the issue here? Because I am pretty sure my hands have come in contact with the capacitor upon insertion/removal of the usb cable.

4) I assume the way to test out your last sentence is by setting all the pins to low and see if any of them still goes high?

As said, I don't have this specific board (just plenty of others ...). But such a touch sensibility would probably only apply during runtime, when galvanically coupled EMI (your finger) can cause a voltage regulator to run wild.

Anyway, I would avoid leaving the board running for longer periods in such a state.

hey f.m.,

sorry for the delayed reply. Been trying to test it to see if what you suggested worked.

A program (just the normal blink program) can be loaded onto it but the error with 'Reset & Retry..' keeps coming back and the processor still gets excessively hot, very quickly. And there doesn't seem to be any human caused short circuit on the original board either.

As to the last part of your response, if the voltage regulator has gone bonkers, that would mean I'd have to get a new board, right?

As to the last part of your response, if the voltage regulator has gone bonkers, that would mean I'd have to get a new board, right?

That depends upon the damage. I just one (a voltage regulator) or a few smaller parts are damaged, you could perhaps replace them - if you have replacement parts, the tools and the experience.

A program (just the normal blink program) can be loaded onto it but the error with 'Reset & Retry..' keeps coming back and the processor still gets excessively hot, very quickly. And there doesn't seem to be any human caused short circuit on the original board either.

Have you tried to debug from reset vector on (not from "main()" on) ?

The clock settings would also be a candidate to cause excessive heat. That might include single-stepping trough assembler instructions - from the reset vector on.

I know that other Cortex M MCUs use to reject invalid clock chain settings, and fall back to a low-frequency default configuration. The MSP432 is quite new (dare I say 'Beta' ?), so I would not exclude an issue here.

f. m. said:

Have you tried to debug from reset vector on (not from "main()" on) ?

Sorry i don't follow. Where do I find this reset vector? Or is it something generic in all programs.

f. m. said:

The clock settings would also be a candidate to cause excessive heat. That might include single-stepping trough assembler instructions - from the reset vector on.

So far I've only tested the code examples with presetted CS Configurations. Otherwise in my program I use the default DCO/ACLK.

The thing is I can't access the Debug state. It loads, the error pops out and then, only the 'Terminate' buttons remains lit. The 'Resume' and 'Suspend' buttons on CCS are greyed out.

f. m. said:

I know that other Cortex M MCUs use to reject invalid clock chain settings, and fall back to a low-frequency default configuration. The MSP432 is quite new (dare I say 'Beta' ?), so I would not exclude an issue here.

I see..yeah I've noticed that the Capacitor for the regulator (C125, which according to some posts here on the forum, is especially sensitive) has already been removed in the newer models.

Sorry i don't follow. Where do I find this reset vector? Or is it something generic in all programs.

The reset vector is the place where the core pulls the address of the first instruction and the stack address from.

You don't need to care much about the startup mechanism at the moment. If you do, you find descriptions in ARM manuals and TI manuals (didn't check the latter, though).

Depending on your toolchain, either disable a "Run to main" checkbox, or enable "vector catch", or set a breakpoint in the startup code (usually an assembler file), right after the reset vector.

The thing is I can't access the Debug state. It loads, the error pops out and then, only the 'Terminate' buttons remains lit. The 'Resume' and 'Suspend' buttons on CCS are greyed out.

Doesn't sound too good.

But usually (at least after CMSIS rules) the clock settings are done in a routine called from the startup/assembler code (and named 'SystemInit' after mentioned CMSIS rules), before calling 'main'. So, if there is a problem, it would "kill" debugging before you can see anything.

I see..yeah I've noticed that the Capacitor for the regulator (C125, which according to some posts here on the forum, is especially sensitive) has already been removed in the newer models.

As already mentioned, I have no experience with this special MSP432 board, nor do I own one. A great opportunity for TI expert staff chime in.

BTW, neither have I downloaded any source library for this MSP432 board, but I expect TI -not- to follow CMSIS rules for startup ...

Okay I'll check out the points you mentioned and see if anything changes.

Oops, i assumed you were an TI employee! Thank you for your explanation and effort, f.m.

A query I have for TI would be...is the Revision 1.9 of the MSP432P401R available from any european distributors? Currently looking to purchase a new board but most of them ( Mouser, RS, etc. ) are still delivering Rev 1.0.