MSP low-power microcontroller forum - Recent Threads

MSPM0G1505: Need to know which of these two MCUs we should use in our re-design. Tks

Eduardo Garza — Thu, 20 Aug 2026 20:59:36 GMT

Part Number: MSPM0G1505

Hi there,

We currently purchase tens of thousands of MSP430F2370IRHAR per year, and due to the low inventory available at TI.COM in the recent months, we are actively replacing the MSP430 for one fo the following newer MCUS: MSPM0G1505SRGZR or MSPM0G1505SRHBR.

The question is about future inventory availability at TI.COM. Could you please tell me which one of these two MCUs you typically sell more from your estore? At this point one of the show 140k inventory and the other just 20k. Big sifference. Please help us better understand that side of the equation, which is the last piece of information that we need to start our redesign. Thanks in advance for your quick reply.

Rgds, EdG

MSPM0G1505: MSPM0G1505 Intermittent FLASH_DED NMI / HardFault Resets Related to HFXTRSEL Setting

Mark Jones — Wed, 19 Aug 2026 14:09:21 GMT

Part Number: MSPM0G1505

Hi TI Gurus,

I am troubleshooting an intermittent runtime reset issue on an MSPM0G1505 (silicon revision 2).

Observed Failure:
During normal operation, the device occasionally resets. After instrumenting the fault handlers, I determined the sequence is:

- NMI occurs with source DL_SYSCTL_NMI_IIDX_FLASH_DED
- NMI exits
- A subsequent HardFault occurs
- Device resets

We do not perform runtime flash programming.

Investigation Performed:
Based on previous guidance and errata review, I verified:

- No DMA reads from flash are occurring.
- No apparent DMA/flash bus collisions.
- Flash wait states are configured correctly for operating frequency.
- I have reviewed code for stack corruption and pointer corruption issues and have not found evidence of either.
- Application image is not located near the end of flash, and avoiding the last flash bytes does not appear relevant to our memory layout.
- I have captured and correlated SYSCTL->DEDERRADDR and it is somewhat random but always near to a __WFI() instruction.

Findings:
While reviewing errata SLAZ742G, I noticed CLK_ERR_01, which discusses operation with a 4 MHz crystal and debugger connected.

Our design uses a 4 MHz HFXT crystal, but the failures occur without a debugger connected.

As an experiment, I changed the HFXTRSEL from:

DL_SYSCTL_HFXT_RANGE_4_8_MHZ

DL_SYSCTL_HFXT_RANGE_8_16_MHZ

This completely eliminates the FLASH_DED/HardFault/reset issue.

More importantly, I can reliably make the problem appear and disappear simply by switching between these two HFXTRSEL settings.

Results:

HFXTRSEL = 4-8 MHz

- Intermittent FLASH_DED NMI
- HardFault follows
- System resets

HFXTRSEL = 8-16 MHz

- Failure disappears

However, using the 8-16 MHz setting has side effects:

- Approximately 10% increase in core current (~1470 µA baseline)
- About 3 ppm reduction in measured crystal frequency accuracy

Questions:
1. For a 4 MHz crystal operating without a debugger attached, should there ever be FLASH_DED, NMI, or HardFault events related to the HFXT range setting, specifically the 4-8MHz setting?

2. Is CLK_ERR_01 (slaz742g) strictly caused by active debugger interaction, or can certain debug-related MCU settings, programming/debug operations, or clock configurations trigger the same behavior in standalone operation?

3. Are there any known mechanisms by which an incorrect HFXTRSEL setting could result in FLASH_DED / NMI events?

4. Has anyone observed similar behavior where changing HFXTRSEL from 4-8 MHz to 8-16 MHz eliminates intermittent FLASH_DED / NMI errors?

5. Are there additional clock-system or flash-controller settings that should be reviewed?

Any insight would be appreciated. The ability to command the failure in and out solely by changing HFXTRSEL makes it appear that the clock configuration may be closely related to the root cause.

RE: MSPM0G1505: MSPM0G1505 Intermittent FLASH_DED NMI / HardFault Resets Related to HFXTRSEL Setting

Mark Jones — Thu, 20 Aug 2026 19:26:56 GMT

Thanks Brian for your in depth response.

I will work on getting CPU_ERR_03 tested. I have tried the disable and flush code around the __WFI() code earlier and still had failure, but I will run that formally to verify behavior with a controlled change and test. That way we can move forward with confidence or find out that it solves the issue.

As an aside, I have been extracting data by bit-banging addresses out on some pins, after trapping the interrupts, as our debugger has been unable to remain connected during runtime.

During my failures I have seen no occurrence of FLASH_ERR_04.

RE: MSPM0C1104: Device seems to go into reset exactly 10s after power up every time

Parker Bondi — Thu, 20 Aug 2026 17:47:33 GMT

Hello Pengfei,

my procedure to use the factory reset tool follows these instructions and does not work. I will re-list them here with additional steps that I do:

1. power down the board

2. hold rst pin low

3. Power up board

4. load factory reset tool web browser

5. select mspm0c110X and factory reset manual

6. i observe the commands are sent and the tool asks me to press the reset button. Afree this moment i release the reset button and nothing happens.

previously I have been able to see the reset successful output from the tool following this exact procedure but not anymore. The thing that makes me think it is not ‘broken’ is that I can see this behaviour on 3 boards.

still I am stuck with these mcu’s not being able to reset.

MSPM0C1104: Device seems to go into reset exactly 10s after power up every time

Parker Bondi — Thu, 06 Aug 2026 04:10:36 GMT

Part Number: MSPM0C1104

I’m using the MSPM0C1104S8YCJR. I had five boards assembled, and boards #1 and #2 have been working well—I developed firmware on #1 and have been able to repeatedly upload firmware to both boards as long as I run the MSPM0_Factory_Reset_Tool before each upload.

I just powered up board #3. First few attempts at running my program and demo and I got a lot of success, but I noticed that towards the end of my demo (maybe 30s) the device failed. I didn't think much of it, used the factory reset tool to reset it, and tried again. Well a similar thing happened at least another 5-6 times. Now I’m seeing behavior that doesn’t match the expected sequence anymore and I'm not able to factory reset the device anymore no matter what I do.

For context - normally, a blank firmware board draws about 2 mA, and if I power it up with RST held low, it draws about 1 mA. Boards #1 and #2 behave exactly like this. Board #3 is different: when I power it up normally, it draws ~2 mA for about 8–9 seconds, and then at exactly the 10‑second mark it drops to 1 mA and stays there permanently. I realize I’m close to the measurement limits of my bench supply, but the XDS110 debug probe also reports that the device appears to be stuck in reset.

However the problem it creates for me is that I cannot get the MSPM0_Factory_Reset_Tool to successfully reset this MCU. The exact sequence that works reliably for boards #1 and #2 is:

Power down the board and tie RST low while it’s off.
Power up the board.
Refresh/reset the Factory Reset Tool webpage.
Attach MSPM0C110x.
Run a manual reset (I’ve also tried automatic).

On board #3, no matter what I do, I never get the “device successfully reset” message from the tool.

MSPM0L1227-Q1: Using HFOSC for RS485 communication

Til Schoengarth — Thu, 20 Aug 2026 15:04:59 GMT

Part Number: MSPM0L1227-Q1

Hello MSP team,

do you recommend using HFOSC for RS485 communication? Or do you think the clock accucary of HFOSC is not good enough and HFXT is recommended?

Best regards,

Til

RE: MSPM0L1227-Q1: Using HFOSC for RS485 communication

Diego Abad Sajamin — Thu, 20 Aug 2026 16:47:18 GMT

Hi Til,

What is the customer's requirements regarding the accuracy in their UART clock accuracy? I'm not sure what you are referring by HFOSC, but bellow are the specs we have for the M0L1227-Q1 SYSOSC accuracy with/without FCL + ROSC.

Best Regards,

Diego Abad

C2000-F28004X-POWER-EST-CALC: App Note SLVA301 Question Regarding Output Capacitane

cazadu designs — Mon, 17 Aug 2026 22:16:02 GMT

Part Number: C2000-F28004X-POWER-EST-CALC

Hello,

I have a question with regards to a Texas Instruments App Note - SLVA301 in particular. Referring to Figure 14, they have a capacitance shown as 50 x 0.1 uF. Why is the capacitance provided in this form? In all of my career, I have never once seen a power supply with 50 capacitors on the output of a power supply - ever. So, why would a tutorial app note list a capacitor in this manner? It seems a bit odd tbh. Why not simply put a value of 5 uF?

Can someone please clarify. Maybe I am missing something here or NOT understanding this at all.

Appreciate any help with clarifying this.

Thank you.

RE: C2000-F28004X-POWER-EST-CALC: App Note SLVA301 Question Regarding Output Capacitane

Febin — Thu, 20 Aug 2026 12:27:11 GMT

Hi,

Please note that this App note was released ~18 years ago and the author is not with TI anymore.

Therefore, it is quite challenging to provide the exact thought process behind the configuration. However, what I could understand is that the author was trying to use 3 different types of capacitors with different ESRs for his analysis.

We could alternatively provide you further technical support on specific devices and support queries on loop analysis for that device if any.

Best Regards,

Febin

RE: MSP430FR6043: Ultrasonic Water Meter - Flow Rate Reading Issues

Peter Jiang — Thu, 20 Aug 2026 10:42:02 GMT

Hi,

Regarding your questions:

1. I believe MCLK mainly affect the computation speed in the algorithm, so I don't think it would have too much help for the consistency issue.

2. In the "USS_userConfig.h", "USS_RESTART_CAP_COUNT_SEC" correspond to "UPS and DNS Gap (us)", and "USS_SYS_MEASUREMENT_PERIOD" correspond to "UPS0 and UPS1 Gap (ms)". And you can find more details about the relationship between the parameters in GUI and code in the " Ultrasonic Sensing Design Center User Guide 02.40.00.00" Configuration section.

3. From my point of view, different algorithm methods will help improve the calculation accuracy, and Hilbert is particularly helpful for gas applications because it has the ability to suppress noise in situations where signal tend to attenuate greatly in the air, however, based on the provided waveform data and attached waveform figure, I think there is no significant noise in there, and the amplitude of the signal were not greatly affected in every measurement, so I believe the Lobe algorithm is sufficient for the case, changing to the Hilbert won't be too much helpful for the drifts caused by inconsistency.

4. Sorry, I'm a bit confused of your understanding about the "DTOF is calculated in moving average", the DTOF should be calculated by the correlation algorithm of the UPS and DNS waveform, and it only depends on one UPS and DNS waveform, It's not as you might think there is a significant delay when the flow rate change to zero but it still shows a previous big value. It should be reflect current actual flow rate in the short measurement interval.

Regarding the inconsistency issue, from the provided waveform as shown below, it can be seen that there is a significant difference in every lobe peak between the UPS and DNS waveform which are from two different input channels. Normally, these two waveforms should overlap quite well. I tend to suspect that this is caused by a hardware issue and not too much related to the software like the parameter settings.

Based on my experience, consistency issues are often caused by hardware like inconsistency in the design of the water meter's mechanical structure, transducers, or the impendence of the signal input pin in the different board. One question, what's transducer model/manufacturer you are currently using? Have you tried replacing different transducers for testing, and obtained a similar waveform like the normal one as shown below? And please make sure it has a good connection between the meter and transducer when you make the changes, poorly connection will also lead to different performance between the boards. And also please measure the impedance of different input channel pins of the USS on the different boards to make sure they are mostly consistent.

Moreover, I have checked your frequency sweep results, I don't think these results are normal since the measured amplitude is much smaller than around 900, which you attached beyond the around 900, as the figure you provided at the very beginning, the amplitude should be around the peak of the waveform, since you are not changing the GAIN to too much low, so I believe they are not performed under good conditions. Please double check and have some new test according to my suggestions provided above.

Best Regards,
Peter

MSP430FR6043: Ultrasonic Water Meter - Flow Rate Reading Issues

Dev Tandon — Mon, 17 Aug 2026 14:31:48 GMT

Part Number: MSP430FR6043

Hi,

In the development of Ultrasonic water meter, we are currently using the reference of MSP430FR6043 firmware for meterology on the custom hardware and a different ultrasonic pipe than the one suggested by TI. We have also tried the EVM board of the same IC with this pipe and the GUI, the major params that were set are as follows:

Scenario 1:-
F1 Frequency - 1000Khz

USS No of Excitation Pulse F1 - 30

USS Restart Capture Count - 0.1 sec (1.00E-1f)

USS Start Capture - 31usec (3.1E-5f)

USS Gain Range - (-0.8 dB)

USS HSPLL Frequency - 80MHz

USS Capture Duration - 55usec

UPS and DNS Gap - 3000usec

UPS0 to UPS1 Gap - 1000msec

Scenario 2:-
F1 Frequency - 1000Khz

USS No of Excitation Pulse F1 - 30

USS Restart Capture Count - 0.1 sec (1.00E-1f)

USS Start Capture - 31usec (3.1E-5f)

USS Gain Range - (-0.8 dB)

USS HSPLL Frequency - 80MHz

USS Capture Duration - 70usec

UPS and DNS Gap - 3000usec

UPS0 to UPS1 Gap - 1000msec

The results for the above parameters were as follows for EVM board as attached below:

For Scenario 1:-

ADC Capture-

Frequecy Sweep-

DTOF, ABSDTOF and Vol Flow Rate-

For Scenario 2:-

ADC Capture-

Frequecy Sweep-

Note - Will be added in the subsequent post, as the file limit exceeded.

DTOF, ABSDTOF and Vol Flow Rate-

Note - Will be added in the subsequent post, as the file limit exceeded.

We have also tried the same two scenarios on our custom hardware as well and captured the corresponding results with the same parameters as above. The results are as attached below :

For Scenario 1:-

ADC Capture-

Frequecy Sweep-

DTOF, ABSDTOF and Vol Flow Rate-

For Scenario 2:-

ADC Capture-

Frequecy Sweep-

DTOF, ABSDTOF and Vol Flow Rate-

Issues :

Across the testing of these meters, we faced issues with flowrate readings and inconsistency with results. During the testing of the meters, at times we saw that the instantenous flow rate was reading Junk values like 8000 L/Hr or 10K L/Hr or 20.1K L/hr. It used to also read 0 L/hr at times even though the water was running through the meters.
This can be seen in the images under DTOF, ABSDTOF and Vol Flow Rate in both the scenarios of EVM and also in scenario 1 of custom board.
The same firmware onto the same hardware given different accuracies when tested in different intervals of time. This behaviour repeats even when meters are tested in series.

To resolve the issues, we referred to FAQ document on Ultrasonic meters by TI, and the following suggestiuons were also tried out:

MCLK was changed to 16MHz from 8MHz.
HSPLL frequency was changed to 80MHz, with OSR still being 20, so as to use 4MHz filter coefficients.
F1 frequency was set to 1000KHz and also Gain was increased to 3.5dB.

None of the above solutions improved the performance of the meters either on accuracy or consistency.

Questions:

Is any one of the above scenarios correct for the modified configuration parameters, or do we need to make any further modifications?
Can you verify if the parameters that are changed in the scenarios are in accordance with the parameters that are usually changed in the GUI?
Algorithm Filter is diabled by defalult. We have enable it. Any particular reason to keep it as disabled? Is all the issues that we are facing is due to noise ?

Pls suggest any modification in configuration to resolve the issues that we are currently facing. If any calculations behind the changes can be provided, that would be helpful.

MSP430FR6043: Im unable to get up stream pulses

Analogics Rnd Solar — Mon, 17 Aug 2026 06:42:19 GMT

Part Number: MSP430FR6043

Hi TI team,

As per our configurations im unable to get upstream pulses
currently Iam using custome designed Msp430fr6043 board, currently we dont have EVM board im testing on our designed board and getting error code i.e. 125, USS_message_code_algorithm_error_no_signal_detected_ups_channel = 125(error code)
i configured as follows,

1.single tone,
2.#define USS_HSPLL_INPUT_CLK_TYPE USS_HSPLL_input_clock_type_crystal
#define USS_CAPTURE_DURATION_USEC 40
#define USS_GAIN_RANGE USS_Capture_Gain_Range_1_0
#define USS_START_CAPTURE_SEC 3.0E-5f
#define USS_ADC_SAMP_COUNT_SEC 6.3999995E-5f
#define USS_RESTART_CAP_COUNT_SEC 3.0E-3f
#define USS_ALG_ADC_ADDITIONAL_CAP_DLY 11.0e-6
#define USS_ALG_DCOFFSET 20e-12
#define USS_PGA_IN_BIAS_COUNT_SEC 0.0
#define USS_TURN_ON_ADC_COUNT_SEC 5e-6

#define USSSWLIB_ENABLE_EXTERNAL_CIRCUITRY_CONTROL false

clock config is

CSCTL0_H = CSKEY_H; // Unlock CS registers
CSCTL2 = SELA__LFXTCLK | SELS__DCOCLK | SELM__DCOCLK;
CSCTL3 = DIVA__1 | DIVS__1 | DIVM__1; // Set all dividers
CSCTL4 &= ~LFXTOFF;
CSCTL4 |= (LFXTDRIVE_3);
do
{
CSCTL5 &= ~LFXTOFFG; // Clear XT1 fault flag
SFRIFG1 &= ~OFIFG;
} while (SFRIFG1 & OFIFG); // Test oscillator fault flag
CSCTL0_H = 0;

im sharing uss_userconfig.h file kindly please followup

USS_userConfig.h

thanking you TI team

RE: MSP430FR6043: Im unable to get up stream pulses

Peter Jiang — Thu, 20 Aug 2026 09:38:02 GMT

You're welcome, glad to hear the issue has been resolved, since that, will close this thread, thanks.

Best Regards,
Peter

RE: MSP430FR6043: Ultrasonic Water Meter - Flow Rate Reading Issues

Dev Tandon — Thu, 20 Aug 2026 05:51:21 GMT

Hi,

We have performed various tests as per suggestions with different F1 Frequency(780/800/900) and USS_ALG_RATIO_OF_TRACK_LOBE (0.25/0.26/0.27).

Attached zip file. File name format to identify the setting and features (Freq_sweep_F1Freq_Threshold_HSPLLFreq_CaptureDuration). This was done at 40 points at a step size of 10kHz.

e2e.ti.com/.../Freq_5F00_Sweep.zip

Scenario:

F1 Frequency - 1000Khz

USS No of Excitation Pulse F1 - 30

USS Restart Capture Count - 0.1 sec (1.00E-1f)

USS Start Capture - 31usec (3.1E-5f)

USS Gain Range - (-3.3 dB)

USS HSPLL Frequency - 72MHz

USS Capture Duration - 70usec

Envelope Crossing Threshold - 25

In the above mentioned setting, Flow rate waveforms have improved and junk values appearance has significantly come down but there exists still issue of consistency that exists i.e., The same firmware onto the same hardware gives different accuracies when tested in different intervals of time.

Questions:

1. Does MCLK settings have any influence on the consistency issue? Currently it is set to 8MHz.

2. Is there any settings to change UPS to DNS and UPS to UPS1 Gap in code?

3. Does the issue of consistency solve if we change the lobe algorithm to Hilbert?

4. Should we reset the DTOF once water stops as it is calculated in moving average?

Please suggest any changes to solve this consistency issues or let us know if we are over looking something.

RE: MSP430FR6043: Im unable to get up stream pulses

Analogics Rnd Solar — Thu, 20 Aug 2026 04:47:25 GMT

Thank you sir,
now is working, i changed gpio configuration GPIO_SECONDARY_MODULE_FUNCTION to GPIO_PRIMARY_MODULE_FUNCTION.
now its woking thank you so much.

RE: MSP430FR6043: Im unable to get up stream pulses

Peter Jiang — Thu, 20 Aug 2026 02:49:58 GMT

Hi,

Please take a look at the following thread and try to make the modification of the GPIO configuration, it seems the same issue as you are current facing.

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/831129/msp430fr6047-problem-with-eusci_b1-i2c-masterrxmultiple-example

RE: MSPM0G1505: MSPM0G1505 Intermittent FLASH_DED NMI / HardFault Resets Related to HFXTRSEL Setting

Brian Dempsey — Wed, 19 Aug 2026 20:15:35 GMT

Hi Mark,

Your HFXTRSEL experiment is a significant clue. For a 4 MHz crystal, DL_SYSCTL_HFXT_RANGE_4_8_MHZ is the nominal datasheet setting. The MSPM0G1505 electrical characteristics specify HFXTRSEL=00 for 4–8 MHz and HFXTRSEL=01 for 8.01–16 MHz. Therefore, using the 8–16 MHz range with a 4 MHz crystal should be considered an errata workaround/diagnostic condition rather than the normal production configuration. The increase in current and change in measured frequency that you observed are also reasons I would not recommend simply adopting the 8–16 MHz setting as the final solution without further confirmation.

The current MSPM0G150x/G350x errata, Rev. H, still contains CLK_ERR_01. It states that when MCLK is sourced directly from a 4 MHz HFXT and HFXTRSEL=0, random HardFault or NMI behavior can occur with the debugger connected; the documented workaround is to select HFXTRSEL=1 or higher while debugging. Your observation is particularly interesting because you can make the failure appear with the nominal 4–8 MHz setting and disappear with the same workaround even when the debugger is disconnected.

Based on the currently published errata, I would not consider intermittent FLASH_DED/NMI operation expected in a standalone system simply because a 4 MHz crystal is configured with the correct 4–8 MHz range. The published scope of CLK_ERR_01 is specifically the debugger-connected case. I also do not see a documented mechanism stating that a valid HFXTRSEL=0 setting at 4 MHz should directly create a Flash ECC double-error event. Because your result reproduces the CLK_ERR_01 workaround outside its documented condition, I think this needs to be escalated internally rather than assuming the 8–16 MHz setting is the production fix.

There is another erratum I would test before changing hardware: CPU_ERR_03. It states that when entering a low-power mode with a pending flash prefetch, the prefetcher can capture incorrect data. After wakeup, the CPU can then execute incorrect instructions if the prefetch/cache has not been flushed. The documented workaround is to disable the prefetcher before __WFI()/__WFE(), perform the shutdown-memory access needed to ensure the prefetch disable has taken effect, enter the low-power mode, and then re-enable prefetch after wakeup. This is especially relevant because you have already correlated DEDERRADDR with locations around __WFI().

I would suggest the following next test sequence:

Return HFXTRSEL to the correct DL_SYSCTL_HFXT_RANGE_4_8_MHZ setting.
Apply the CPU_ERR_03 prefetch workaround around every __WFI()/__WFE() and rerun the same stress test.
In the NMI handler, capture DEDERRADDR, NMI source, CPUSS->CTL, HFXTRSEL, clock status, and MCLK source before returning from the NMI.
In the HardFault handler, capture the stacked PC and LR so we can determine whether the HardFault is occurring on the same flash fetch that generated the DED event.
Repeat with the debugger physically disconnected and with any automated reconnect/reset behavior disabled.

One other point when interpreting DEDERRADDR: FLASH_ERR_04 documents an incorrect address representation when the DED occurs outside Main Flash, and FLASH_ERR_05 allows a specific nonzero reset value in DEDERRADDR. If your captured addresses are genuinely within the Main Flash code region around __WFI(), those two errata would not explain the result.

You have already eliminated several of the more common causes—no runtime flash programming, no DMA reads from flash, correct flash wait states, and no evidence of stack/pointer corruption. Given that changing only HFXTRSEL reliably commands the failure in and out, I agree that the clock configuration is strongly correlated with the issue. I would therefore test the CPU_ERR_03 workaround first and, in parallel, escalate this as a potential extension or related manifestation of CLK_ERR_01 under standalone operation. I would not recommend using HFXTRSEL=8–16 MHz permanently with a 4 MHz crystal until that behavior is confirmed as an approved workaround for the non-debug case.

MSPM0C1105: Will using high Precision Vdd improve internal reference performance?

Joseph Scherphorn — Tue, 18 Aug 2026 17:29:26 GMT

Part Number: MSPM0C1105

Hello,

In system being designed a high accuracy 3.3V as well as a lower voltage high accuracy reference are needed.

My question is will the accuracy of the internal voltage reference improve if a precision source is used for vdd? If so Is this quantifiable?

Thank you,

Joseph Scherphorn

Will using high Precision Vdd improve internal reference performance?

RE: MSPM0C1105: Will using high Precision Vdd improve internal reference performance?

Owen Li — Wed, 19 Aug 2026 15:36:28 GMT

Hi Joseph,

As Keith has pointed out, a precision voltage source will not have a significant effect on the accuracy of the internal VREF.

If your system requires a higher accuracy VREF, I would suggest using an external reference.

What kind of accuracy are you targeting? What is the application?

Best,

Owen

RE: MSPM0C1105: Will using high Precision Vdd improve internal reference performance?

Keith Barkley — Wed, 19 Aug 2026 15:10:05 GMT

Here are the Ref specs:

Note that the supply rejection is over 40 dB, so a precision VDD is not going to help much.

RE: MSPM0C1105: Will using high Precision Vdd improve internal reference performance?

Keith Barkley — Wed, 19 Aug 2026 15:06:20 GMT

I don't think so, it is set by the internal reference. You can provide an exetrnal reference if you want.

A high precision Vdd will prevent whatever power-supply variation might be present, it it is usually second or third order effects.

MSP430F5342: Cold temp high power consumption issue

Ryuuichi machida — Tue, 23 Jun 2026 11:39:11 GMT

Part Number: MSP430F5342

Hi,

My customer have high power consuption issue with MSP430F5342 when only powering up.
When I brouse E2E, I found similar thread.

(+) MSP430F534x - current consumption LPM3 at -40°C - MSP low-power microcontroller forum - MSP low-power microcontrollers - TI E2E support forums

This thread was posted 13 years ago, however could you please tell me this is known issue ?
(I could not find related issue in latest errata..)

Best Regards,

RE: MSP430F5342: Cold temp high power consumption issue

Diego Abad Sajamin — Wed, 19 Aug 2026 14:41:02 GMT

Hi Ryuuichi,

I checked the result, and it seems that the device still behaves the same regardless of the project, or customer's board. From the MSP Apps perspective, it seems the device is showing a behavior that it was not characterized in an errata or documentation. I believe we can start the process of FA analysis. Since this thread probably will change to an email, please reach out to Apps engineer for the Japan region I sent in the message.

Best Regards,

Diego Abad

RE: MSP-EXP430FR2355: MSP-EXP430FR2355 Meaningless UART Output

Keith Barkley — Wed, 19 Aug 2026 12:11:15 GMT

I would just do it all in counts and convert at the end, not as much precision, but easier to keep track of!

MSP-EXP430FR2355: MSP-EXP430FR2355 Meaningless UART Output

Ian Sanders — Wed, 05 Aug 2026 11:33:53 GMT

Part Number: MSP-EXP430FR2355

Hi All

I am doing a very simple project (so I thought) where I read the value in on P1.4 ADC from a 10k pot connected to 3.3V.

The ADC reads the value with no issues what so every. However, when I try to transmit the HEX value out on the UART I get meaningless characters which says to me it is a baud rate configuration issue. But I followed all the user guides and the formula and check it against several online AI tools and tey all come up with the same answer.

I suspect it is something to do with how I have set up my UART interrupts

I am using SMCLK = 1MHz ad the desired baud rate is 9600

The code is below and ay help would be much appreciated.

#include <msp430.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <math.h>

//Variables

volatile unsigned int ADC_value = 0;

void UART_init(void)
{

/* Configure UART pins (P4.2 = RXD, P4.3 = TXD) */
	
	P4SEL0 |= BIT2 | BIT3;                    			// Set P4.2 and P4.3 to UART mode
	P4SEL1 &= ~(BIT2 | BIT3);

	UCA1CTLW0	|= UCSWRST;					// Put eUSCI_A1 in reset
	UCA1CTLW0	|= UCSSEL__SMCLK;				// Choose SMCLK clock source

/*	Baud Rate Calculation for 9600 baud with 1,000,000 Hz SMCLK:
  	1000000 / 9600 = 104.166 -> UCBRx = 104, fractional portion = 0.166
  	Using Table 22-4 from User's Guide: UCBRSx = 0x11*/ 

	UCA1BR0		= 0x68;						// 1MHz 9600 baud
	UCA1BR1		= 0;
	UCA0MCTLW	= 0x1100;
	
	UCA1CTLW0	&= ~UCSWRST;					// Initialize eUSCI state machine
	UCA1IE		|= UCTXIE;				 	// Enable USCI_A1 TX interrupt
	
	__bis_SR_register(GIE);
	__no_operation();
}

int main(void)
{
	WDTCTL = WDTPW | WDTHOLD;	            			// stop watchdog timer
	
/* Disable the GPIO power-on default high-impedance mode to activate
 * previously configured port settings*/

	PM5CTL0 &= ~LOCKLPM5;

	UART_init();

/* Configure ADC Channel Pins*/

	P1SEL1 |= BIT4;                         			// Configure P1.4 for ADC
	P1SEL0 |= BIT4;

/* Configure ADC12 */

	ADCCTL0     =   ADCSHT_2 | ADCON;       			// ADCON, S&H=16 ADC clks
	ADCCTL1     =   ADCSHP;                 			// ADCCLK = MODOSC; sampling timer; ADC conversion start source is ADCSC bit
	ADCCTL2     =   ADCRES_2;               			// Set ADCRES_2 to binary 10 for 12 bit resolution
	ADCIE       |=  ADCIE0;                 			// Enable ADC conv complete interrupt
	ADCMCTL0    |=  ADCINCH_4 | ADCSREF_0;  			// ADC channel A4 selected as input and internal reference selected 000b = {VR+ = AVCC and VR- = AVSS}

/* Configure voltage reference for ADC conversion */
	PMMCTL0_H = PMMPW_H;                                      	// Unlock the PMM registers
	PMMCTL2 |= INTREFEN;                                      	// Enable internal reference 1.5V
	__delay_cycles(400);                                     	 // Delay for reference settling

	while(1)
	     {
	        ADCCTL0 |= ADCENC | ADCSC;                            	// Sampling and conversion start
	        __bis_SR_register(LPM0_bits | GIE);                  	// LPM0, ADC_ISR will force exit
	        __no_operation();
	     }
}

#pragma vector = ADC_VECTOR
__interrupt void ADC_ISR(void)

{
    switch (__even_in_range(ADCIV, ADCIV_ADCIFG))
    {
        case    ADCIV_ADCIFG: 						// ADC12MEM1 Interrupt
                ADC_value = ADCMEM0; 					// Save MEM0
                __bic_SR_register_on_exit(LPM0_bits | GIE);		// Exit CPU, clear interrupts
                break;
               default:
                break;
    }
}

#pragma vector = USCI_A1_VECTOR 					// Vector depends on specific MSP430 family variant
__interrupt void USCI_A1_ISR(void)
{
    switch(__even_in_range(UCA1IV, USCI_UART_UCTXCPTIFG))
    {
        case USCI_NONE: 
            break;
            
        case USCI_UART_UCRXIFG:
            break;
            
        case USCI_UART_UCTXIFG:
        	
            UCA1TXBUF = (ADC_value);
            break;
            
        case USCI_UART_UCSTTIFG:
            break;
            
        case USCI_UART_UCTXCPTIFG:
            break;
        default:
        	break;
    }
}

UART Issue.txt