MSP430F5419A: not start correctly

Hello,

220pF is too large for the reset capacitor.  Try with a 2.2nF and see if you are still seeing problems.

I was trying to change Creset to 22n (only that I have it in the same package) or Rreset from 1k to 470k. Doesn't matter.

Yes, I changed the reset RC to exactly 2.2n*47k, but nothing new.

One more thing. In case of "stuck" state chip doesn't restart by shorting of GND w RST, only fast reconnect of the power chord.

That voltage looks like at the power-up. VCC, Vreset and Vcore. Pretty clear I think

Hi James, I use 1u+0.1uF on every DVCC pin, so it's 4.4u together. + I add 22u, but nothing changes.

It's very strange for me, the schematic of chip-related connection was almost the same as described in devboard MSP-EXP430F5438 manual ( https://www.ti.com/lit/ug/slau263i/slau263i.pdf )

Alexander R4PFD Lovchev said:

I use 1u+0.1uF on every DVCC pin, so it's 4.4u together. + I add 22u, but nothing changes.

Keep in mind 4.4 uF is still less than a ratio of 10. Moving forward, just keep a higher cumulative capacitance on DVCC than 4.7 uF. That should help you rule this out and focus on other things that may be causing the issue.

What do you mean by nothing changes? Are you able to program the device? If so, try programming one of our code examples in TI Resource Explorer. Now that the CDVCC to CVCORE ratio is > 10, it'd be good to narrow down if it's a programming issue or a (code) startup issue.

What tool are you using to program your device?

Is the device getting back-powered by another device on your board? With no VCC applied, you'll want to avoid applying any voltages greater then what the datasheet specifies. Sometimes, this scenario occurs when other devices on your board are connected over I2C, UART, etc. but powered by different supplies.

I mean that chip wasn't starting correctly every startup, even I increase Cdvcc\Cvcore ratio. I can program&debug (CCS, SBW through launchpad), there is no one problem with all of the peripherals which I use in my project.

If the device is back-powered parasitic before I connect the main power (external usb-uart converter for example) - the chip starts well.

It's possible a problem with code too. But with the just "blink" examples its starts not every time too.

Alexander R4PFD Lovchev said:

I can program&debug (CCS, SBW through launchpad), there is no one problem with all of the peripherals which I use in my project.

Are you powering the custom board from the debugger (e.g. 3V3 pin) on the LaunchPad or are you applying an external voltage to the custom board too? Depending on your connections, there could be a power supply conflict, so the device may be getting back-powered by the LaunchPad debugger or another IO which can cause erratic behavior. The MSP-FET debugger is designed to sense the power supply voltage and adjust the voltage (logic) levels to the JTAG pins without back-powering the device. The LaunchPad is not able to do that, so more caution must be used. Assuming the logic levels are the same (e.g. 3V3), you'd want to connect the debugger AFTER the device has been powered up by the external supply. In this case, you'd just need the SBW pins and GND for programming.

Alexander R4PFD Lovchev said:

It's possible a problem with code too. But with the just "blink" examples its starts not every time too.

A simple code example is good to use to help rule out code issues. For example, if you're using an external crystal with the wrong load capacitance and enabling/verifying the crystal in your code, there could be an oscillator fault flag that prevents your code from running when set. This would appear like a startup issue. If the simple code example doesn't use the crystal, you can rule that out. I think you're making progress.

I'm powering my board directly and through a debugger separately. If I connect the debugger first-time behavior is the same as in the case of external power - not starting correctly every time. Chip started well only after reprogram (or another software reset event), after fast power reconnection, or in case of switching on with back-powering peripherals too.

James Evans said:

For example, if you're using an external crystal with the wrong load capacitance

Yes, it looks very related to this. But in fact, 32768 generation is there. And XT1OFF bit default value is 1, so the chip must start with internal RC,

I also add simply leds initialization to _system_pre_init, so I know that it stuck on this function or earlier, before main() and all of the clock inits, etc.

Can it be trouble with factory programmed bootloader? May be chip going not to _system_pre_init() and main() but to BSL?  Can I check it?

It's way to check that chips in my local store are not fake, for example by reading TLV dump?

That's is also one strange fact. In "stuck" state shorting reset pin to gnd doing nothing. Look like something is disabling RST pin by software before actual startup.

Thanks!

I think there are too many variables right now that could be contributing to this issue, so I would recommend that you start establishing some known reference points in your debugging process.

On the software side, rule out your code (e.g. __system_pre_init) by using a code example like msp430x54xA_1.c to toggle P1.0. On the hardware side, remove or disconnect all unnecessary connections from the MSP430 on your board. Do not connect the debugger to it and see if it powers up correctly. By that, I mean check that P1.0 is toggling.

There may be times after programming the MSP430 that it doesn't immediately start executing code until you reset it. However, after programming and removing the debugger connections, it should start up every time. I'm confident that if I used this MSP430 in a target socket board and followed my earlier instructions, the MSP430 would start up every time 3V3 was applied to the board.