MSP low-power microcontroller forum - Recent Threads

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

Ryuuichi machida — Thu, 25 Jun 2026 22:21:36 GMT

Hi,

Could you please give your feedback ?
Especially, I would like to know about below.
>This thread was posted 13 years ago, however could you please tell me this is known issue ?

Best Regards,

MSPM0C1106-Q1: Secure Boot Timing

Daviel Almonte — Thu, 25 Jun 2026 20:12:08 GMT

Part Number: MSPM0C1106-Q1

Hello,

My customer needs to boot a camera using the MSPM0C1106 MCU under 2 seconds. I do beleave that we can achive this, but I couldn't find the bootiming for this device.

what is the typical boot time for this device using secure boot.

Regards,

Daviel

RE: LP-MSPM0G3507: Unable to use EnergyTrace with onboard XDS110

Ki — Thu, 25 Jun 2026 19:50:11 GMT

Is the XDS110 currently in use with another session?

I am sure that only one session is open.

What was the issue you had when you tried running it? Any errors?

Energytrace icon was grey under debug mode on CCS 12.8.

[/quote]

I am not sure what the issue is with your CCS 12.8 environment. You can try cleaning the CCS and workspace caches as mentioned in sections 9.4.2 and 9.4.3 of the user's guide:

https://software-dl.ti.com/ccs/esd/documents/users_guide_12.8.0/ccs_troubleshooting.html#use-the-clean-argument-when-calling-ccstudio-exe

Please note that CCS 12.8 has been greatly deprecated in support.

[quote userid="585063" url="~/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1658020/lp-mspm0g3507-unable-to-use-energytrace-with-onboard-xds110/6394479"]Tried gpio_toggle_output, out_of_box [/quote]

That is the one I used in my screenshots.

No, it should not. Those devices (MSP432E401Y and TM4C1294NCPDT) should be interchangeable and both are valid for the XDS110 hardware.

My LP-MSPM0G3507 (Rev A) development board actually has the MSP432E but again it should not matter here.

Can you show a screenshot of your CCS 21 environment with the EnergyTrace tab showing no data?

LP-MSPM0G3507: Unable to use EnergyTrace with onboard XDS110

Eching Cheung — Wed, 24 Jun 2026 07:00:22 GMT

Part Number: LP-MSPM0G3507

Hi, I got a brand new LP-MSPM0G3507 (Rev A) development board and tried to program and debug some example code. Worked fine.

However, I am facing some problems when trying to use the onboard EnergyTrace function.

When I test it with the CCS 12.8 standalone EnergyTrace tool, it shows

"Error communicating with XDS110"

Another question: Why EnergyTrace unavailable in debug mode on CCS 12.8?

When I test it with CCS 21, I am able to open the EnergyTrace tab and no error shows up.

However, I start the project, it shows "Collecting data -> Data capture complete" within a second, but nothing appears on the graph.

What I have done so far:

Changed the USB cable and USB port.
Updated the development board firmware using CCS.

MSPM33C321A: Getting started with LVGL

Keith Barkley — Mon, 22 Jun 2026 22:05:19 GMT

Part Number: MSPM33C321A

The MSPM33 SDK (Currently 1.03.00.01 - March 18, 2026) contains a demo for using LVGL on the MSPM33C321.

www.ti.com/.../sdaa158.pdf

TI provides an LVGL CCS demo project you can find in the SDK here:

C:\ti\mspm33_sdk_1_03_00_01\examples\nortos\LP_MSPM33C321A\demos

(I imagine you can also get to it in resource explorer.)

Now that you have run the LVGL demo successfully*, and tried to call Elena's phone number, what do you do?

Here is a quick guide to get you started with your own gui on LVGL with the MSPM33C321.

All of these instructions make changes to main.c in the MSPM33C321 LVGL example.

#0 Remove the demo

Comment out the demo files:

In the global area

//#include "demos/widgets/lv_demo_widgets.h"

and in main():

//lv_demo_widgets();

#1: Our first label

Add a global object just above main():

lv_obj_t *MyLabel;

This creates a pointer to an LVGL object.

Now in main() just ahead of the while() loop add the following:

MyLabel = lv_label_create(lv_scr_act());

lv_label_set_text(MyLabel, "Hello, World!");

lv_obj_align(MyLabel, LV_ALIGN_CENTER, 0,0);

This creates a new label, assigns it to MyLabel and initializes it to "Hello, World!"

It also aligns it to the center of the display.

Go ahead and compile and run it on your hardware.

(My screenshots are from my MSVS simulator - see below)

#2 Counter

Let us make a slight modification to create a live counter in our label.

Add this variable and function to the global area above main():

Int Counter = 0;

void UpdateCounterTimer(lv_timer_t* timer)

{

lv_label_set_text_fmt(MyLabel, "Hello, World: %d", counter);

counter++;

}

And add this function underneath the other MyLabel code:

lv_timer_create(UpdateCounterTimer, 1000, NULL);

Build and run.

This code adds a timer that will call UpdateCounterTimer() every 1000 ms.

[Note, at least on my launchpad, it updates much faster. The interrupt is probably being called faster than every 1 ms]

When UpdateCounterTImer() is called, it sets a new text label with the counter value.

#3 Button

One final modification, let’s add a button.

In the global area, we need a button and Boolean to act as a flag:

lv_obj_t* Button;

volatile bool Flag = false;

And a function to handle our button event:

void Button_Event_Handler(lv_event_t* e)

{

lv_event_code_t code = lv_event_get_code(e);

if (code == LV_EVENT_CLICKED) {

if (Flag == false)

{

Flag = true;

}

else

{

Flag = false;

}

If we had more than one button we might need to add code to discriminate between buttons

Let us make a slight change in the UpdateCounterTimer() function by only updating the counter if the flag is false

void UpdateCounterTimer(lv_timer_t* timer)

{

lv_label_set_text_fmt(MyLabel, "Hello, World: %d", counter);

if (Flag == false)

{

counter++;

}

Finally, let us add the button startup code to main():

Button = lv_btn_create(lv_scr_act());

lv_obj_add_event_cb(Button, Button_Event_Handler, LV_EVENT_ALL, NULL);

lv_obj_align(Button, LV_ALIGN_CENTER, -100, -100);

lv_obj_t* label;

label = lv_label_create(Button);

lv_label_set_text(label, "Start//Stop");

lv_obj_center(label);

This creates a button as a child of the main screen. (“lv_scr_act()”) It is aligned above and to the left of the original label.

We then create a label that is a child of the button, and add some text.

Compile and run. You should see something like this:

As you click the button you can start and stop the counter.

This should be enough to get you started.

But if you want to add more widgets and see more examples:

https://lvgl.io/docs/open/8.3/get-started/

(I point to the 8.3 docs, since that is the version currently supplied with the MSPM33 SDK.)

If you want to create any kind of complicated GUI's I strongly suggest getting a simulator to run on a host PC:

https://lvgl.io/docs/open/8.3/get-started/platforms/pc-simulator.html

There is also a large active users forum to help you with any other questions.

(Note: The imminent new SDK is coming and may change these instructions in unknown ways.)

*I had to disconnect the PWM/LED pin to get it to work.

RE: MSPM33C321A: Getting started with LVGL

Keith Barkley — Thu, 25 Jun 2026 13:03:54 GMT

The example uses a TimerG for the tick increment with a Load Value of 999. Since the example does not include the sysconfig file, it is difficult to parse the exact clock frequencies to see if that load value is correct. I was just going to increase it a bit to see if I can get closer to 1 ms per tick.

MSPM0G5187: MSPM0G5187 IrDA baud rate

Toshio Katsura — Thu, 25 Jun 2026 11:00:13 GMT

Part Number: MSPM0G5187

We are trying to use IrDA with the MSPM0G5187, targeting a baud rate of 115200 bps.

We configured the IrDA parameters using CCS; however, CCS indicates that
“A baud rate of 9600 should be used for IrDA mode.”

Could you please advise whether it is possible to use IrDA at 115200 bps?

MSP430F6778A: After clearing the JTAG signature at 0x17FC via BSL, what is required to re-enable JTAG?

MF — Sat, 20 Jun 2026 11:48:36 GMT

Part Number: MSP430F6778A

Hello,

I have an MSP430F6778A whose JTAG is locked by the electronic fuse (the JTAG signature at 0x17FC–0x17FF holds a non-zero, non-0xFFFFFFFF value). JTAG access is blocked, so I am using the BSL to recover the device.

Over BSL I clear the lock as follows:
1. Clear the BSL read/program protection (write 0x0003 to SYSBSLC @ 0x0182 to clear SYSBSLPE).
2. Write 0x00000000 to the JTAG signature @ 0x17FC (4 bytes).

My question is about what happens after that write. To make the cleared signature take effect and have JTAG become active again, what exactly is required?

- A full power cycle (VCC off → on / BOR)?
- A hardware reset via the RST/NMI pin?
- Is the BSL "reset/reboot" command (the BSL's own software reset that exits BSL and starts the application) sufficient?
- Or does the device re-evaluate the JTAG fuse only on a specific reset class (POR vs BOR vs PUC)?

In other words: at which reset level does the F677x family re-read the 0x17FC signature to decide whether JTAG is enabled? I want to know the minimum, reliable action so I can re-enter JTAG immediately after the BSL unlock without an external power cycle if possible.

The device is self-powered in my setup (the programmer does not drive VCC), so I would prefer a method that does not require toggling the supply, if one is sufficient.

Thank you.

RE: MSP430F6778A: After clearing the JTAG signature at 0x17FC via BSL, what is required to re-enable JTAG?

MF — Thu, 25 Jun 2026 04:32:43 GMT

Hi Brian,

Can the JTAG test-register BOR be issued while JTAG is still locked (i.e. in the unlock direction), or only on an already-unlocked device?

Thanks.

RE: LP-MSPM0G3507: Unable to use EnergyTrace with onboard XDS110

Eching Cheung — Thu, 25 Jun 2026 02:19:47 GMT

Is the XDS110 currently in use with another session?

I am sure that only one session is open.

What was the issue you had when you tried running it? Any errors?

Energytrace icon was grey under debug mode on CCS 12.8.

Which example code are you working with?

Tried gpio_toggle_output, out_of_box and other but none of them made a difference on enerygrace.

I noticed that the main debug chip from user guide was MSP432, However, on my board is a TM4c1294, does it make any different?

I tried to probe P7,P8 (HOSTSCL, HOSTSDA) of 430G2453 from energytrace circuitry but found no signal at all times.

Does it mean my board is defective or an incorrect firmware?

RE: MSP430F6778A: After clearing the JTAG signature at 0x17FC via BSL, what is required to re-enable JTAG?

Brian Lee — Wed, 24 Jun 2026 19:44:38 GMT

Hi MF,

Apologies for the delayed response. For this device a BOR is required to reset the JTAG interface. However, BOR can be triggered without a full POR. A BOR can by generated by JTAG by writing into a dedicated JTAG test data register. Section 2.4.2.1 in the MSP430 Programming with the JTAG Interface User's Guide goes into further detail.

Best Regards,
Brian

RE: LP-MSPM0G3507: Unable to use EnergyTrace with onboard XDS110

Ki — Wed, 24 Jun 2026 19:36:31 GMT

Hello,

I tried ET with my MSPM0G3507 LaunchPad. It seemed to work on all the environments.

Is the XDS110 currently in use with another session? If not, and the XDS110 is configured properly, it should work:

[quote userid="585063" url="~/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1658020/lp-mspm0g3507-unable-to-use-energytrace-with-onboard-xds110"]Another question: Why EnergyTrace unavailable in debug mode on CCS 12.8?[/quote]

This worked for me too. What was the issue you had when you tried running it? Any errors?

When I test it with CCS 21, I am able to open the EnergyTrace tab and no error shows up.

However, I start the project, it shows "Collecting data -> Data capture complete" within a second, but nothing appears on the graph.

[/quote]

This also worked for me in CCS 21.

Which example code are you working with? I'm using the gpio_toggle_output example from the SDK.

Thanks

MSP430FR5849: SMCLK stops at low temperatures.

Ichiro Nagai — Fri, 15 May 2026 01:27:06 GMT

Part Number: MSP430FR5849

ACLK is LFXTCLK connected to an external 32.768kHz signal.

SMCLK divides DCOCLK.

It is operating in LPM4 mode.

Under normal temperatures, it transitions to AM mode when an interrupt occurs.

However, at low temperatures (approximately -10°C), it does not transition to AM mode.

When monitoring SMCLK (8MHz) output to the port,

SMCLK stopped at low temperatures. It resumed operation when the temperature returned to normal.

ACLK (32.768kHz) was also monitored. This was outputting normally.

The LFXTOFF bit is always kept clear.

Is there a way to avoid the phenomenon where SMCLK stops?

RE: MSP430FR5849: SMCLK stops at low temperatures.

David Schultz — Wed, 24 Jun 2026 16:21:11 GMT

Since the line of code to enable the watchdog is just free floating, it is impossible to tell when, or even if, it executes.

But if the dog is enabled, no code to periodically reset it has been shown. So when the code that waits for a GPIO interrupt enters LPM4 (actually LPM3 since the dog needs LFXT), nothing resets the watchdog. So 16 ms later, more or less, the device is reset.

If the GPIO event you are expecting to cause an exit from LPM4 happens during that reset process, then it will be lost.

RE: MSPM0L2117: Controlling PA1 on pin 2 on MSPM0L2117

Diego Abad Sajamin — Wed, 24 Jun 2026 15:18:47 GMT

Hi Orlando,
PA1 is an open-drain pin, which means it will require a pull-up resistor in order to drive (output) high. Does your design includes it?

Best Regards,

Diego Abad

MSPM0L2117: Controlling PA1 on pin 2 on MSPM0L2117

Orlando Diaz — Wed, 24 Jun 2026 10:45:18 GMT

Part Number: MSPM0L2117

We are trying to interface the MSPM0L2117SRHBR with the motor driver DRV8242

We connect pin 2 (PA1) to IN1 of the motor driver.

But so far, we are unable to set PA1 to drive it. We are not even able to set that pin to high.

This is the current configuration on on the syscfg tool.

We have discarded to be a PCBA problem so far so we suspect that there might be an issue with the libraries. According to the datasheet PINCM2 is set to address 0x40428004, but in our debugger (Segger JLink) IOMUX_PINCM[0] seems to correspond to that address.

Do you have any suggestions?

RE: MSP430FR60431: MSP430FR6043 / USS Library: Pair-dependent cycle-slip / wrong-lobe dTOF jumps in air anemometer prototype

Peter Jiang — Wed, 24 Jun 2026 09:21:09 GMT

Hi Colby,

Sorry for the delay since these days I'm not in the office, regarding your questions:

[quote userid="704470" url="~/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1655940/msp430fr60431-msp430fr6043-uss-library-pair-dependent-cycle-slip-wrong-lobe-dtof-jumps-in-air-anemometer-prototype"]Does this evidence look consistent with cycle slipping / wrong-lobe locking in the USS library?[/quote]

Yes, it appears to be the cycle slip issue which related to the wrong lobe locking since from your dTOF diagram it occurs some abnormal one cycle offset.

[quote userid="704470" url="~/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1655940/msp430fr60431-msp430fr6043-uss-library-pair-dependent-cycle-slip-wrong-lobe-dtof-jumps-in-air-anemometer-prototype"]If the USS library reports valid results (ALG=122) during these events, is it expected that adjacent-cycle wrong-lobe locks can occur without an error code?[/quote]

Yes, it's possible that the cycle slip issue may occur when the algorithm perform normally.

[quote userid="704470" url="~/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1655940/msp430fr60431-msp430fr6043-uss-library-pair-dependent-cycle-slip-wrong-lobe-dtof-jumps-in-air-anemometer-prototype"]Why might the test pair produce cycle slips while the reference pair does not, when both are tested with the same firmware configuration, USS algorithm path, and similar open-air geometry? [/quote]

This may be related to poor transducer consistency or different input impedance, so here are some questions: Have you replaced the transducer and exchange the input channel to perform the test? Does the cycle slip issue still exist after you change it?

Answer the Question 4,5,6 together, by observing the waveform you captured as shown below, it seems involve a lot of noise, and the signal is almost drowned out by the noise, I cannot tell which is second or third lobe from the figure, so the algorithm can not either, cycle slip issue can easily occur due to poor quality of the signal, you can increase the GAIN to let the peak of the signal reach to around 800,900 counts, and other parameters like capture start / capture window/pulses can remain unchanged. Since the algorithm is entirely based on the captured waveform, I believe the priority is to first rule out some hardware issues and try to acquire a good ADC waveform, other algorithm related parameters can be adjusted later after the ADC waveform is confirmed to be satisfactory. Have you taken a look at the Quick Start Guide for Gas Flow Meter? you can take the "Figure 11. Representative Captured Waveform" in the document as reference, and as mentioned above, please try to change the transducer to perform some test again.

In addition, you can try to perform an FFT on the waveform data to check if there is any obvious harmonic components, we have provided digital filter function in the code which can help filter out some noise.

[quote userid="704470" url="~/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1655940/msp430fr60431-msp430fr6043-uss-library-pair-dependent-cycle-slip-wrong-lobe-dtof-jumps-in-air-anemometer-prototype"]For a final open-air sensor with 2–3 transducer pairs, should all pairs be sorted/tuned to work under one shared USS configuration, or does TI recommend any per-pair characterization/configuration strategy?[/quote]

We recommend using transducers with better consistency, in which case, the setting parameters can be kept consistent without needing to optimize parameters for specific transducers.

Best Regards,
Peter

MSP430FR60431: MSP430FR6043 / USS Library: Pair-dependent cycle-slip / wrong-lobe dTOF jumps in air anemometer prototype

Colby Allen — Tue, 16 Jun 2026 17:50:55 GMT

Part Number: MSP430FR60431

Hello TI team,

We are developing a custom open-air ultrasonic anemometer prototype using an MSP430FR6043 and the TI USS library. Unlike a pipe or tube flow meter, the intended sensor will use 2–3 transducer pairs in open air, either in a direct/linear or reflective geometry. We are currently testing one approximately 150 mm acoustic path at a time in still air before moving to the full multi-axis sensor.

We are seeing what appears to be transducer-pair-dependent cycle slipping / wrong-lobe locking. One transducer pair repeatedly locks cleanly, while another pair intermittently produces integer-cycle-like dTOF jumps, often near ±1 acoustic cycle and occasionally larger, even though the USS library reports valid algorithm results.

By “valid algorithm results,” we mean our firmware reports ALG=122 from USS_runAlgorithmsFixedPoint() / USS algorithm processing. In these events, the capture call succeeds, the algorithm reports valid results, and converted dTOF, TOFups, and TOFdns values are produced, but the reported dTOF sometimes jumps by an integer-cycle-like amount.

We found a related E2E thread titled “EVM430-FR6047: Possible Cycle Slipping or other issue causing +/- 10 uS dToF readings”, where TI indicated that poor ADC capture / weak receive signal could cause cycle slip. Our symptoms seem similar in class, but our setup has a useful A/B comparison: one transducer pair works cleanly while another pair does not under the same firmware configuration and USS algorithm path, with both UPS and DNS ADC captures logged.

Terminology used below:

Reference pair: our bench reference transducer pair. This pair has repeatedly produced ALG=122, near-zero still-air dTOF clustering, approximately 600-class ADC peak-to-peak captures, and approximately 0% wrong-cycle events in our control logs. We do not mean this pair is production-qualified.
Test pair: the second transducer pair that intermittently slips under the same style of USS processing.
CH0/J9-J2 and CH1/J8-J3: our custom board connector/channel labels, not TI EVM labels. A schematic excerpt is attached as Fig. A.

System summary:

MCU: MSP430FR6043
Medium: open air / still-air bench testing
Current test path length: approximately 150 mm
Final intended sensor: 2–3 ultrasonic transducer pairs per sensor unit, open-air direct/linear or reflective geometry
Transducers: 200 kHz air ultrasonic transducers (CUSA-TR09)
Firmware mode: multitone / Hilbert-Wide
ADC raw waveform logging: both UPS and DNS capture slots are dumped over UART
Board: custom RevA board with external AFE and mux/steering
Reference pair: custom board connector/mux channel CH1, J8/J3
Test pair: custom board connector/mux channel CH0, J9/J2
Test condition: still air / fan low / no probes attached

Attachments for setup/context:

Fig. A: schematic excerpt showing MSP430FR6043, external AFE, mux/steering, and transducer connectors (figA_anemometer.pdf).
Table 1: TI GUI-style parameter table mapped from our current firmware values

Current baseline USS-style parameters:

Pulse mode: multitone
Baseline F1/F2: 185 kHz / 215 kHz, center 200 kHz
Number of trill pulses: 12
Gain baseline: USS_Capture_Gain_Range_0_1
ADC capture: 300 samples, 1 us sample period, ADC after ping approximately 350 us
UPS/DNS raw captures are stored and dumped as slot 1 and slot 2
Algorithm output: firmware reports ALG=122 for both clean and slip events

Observed behavior, backed by logs:

Reference pair on CH1/J8-J3 at the 185/215 kHz center-200 kHz baseline:
- wrong-cycle rate: 0%
- dTOF cluster remains near zero
- slot peak-to-peak amplitude roughly 600-class
- USS algorithm reports ALG=122
- See Fig. 1 for the reference pair ADC capture
- See Fig. 5b for the dTOF comparison. Red “x” markers identify fires where abs(dTOF - still-air cluster center) exceeds the ±2.50 us half-cycle screen at 200 kHz.
Test pair on CH0/J9-J2 at the same 185/215 kHz center-200 kHz baseline:
- intermittent wrong-cycle behavior
- examples include dTOF jumps near ±5 us and occasionally larger
- USS algorithm still reports ALG=122
- raw ADC waveforms are present in both UPS and DNS slots
- ADC amplitude is weaker than the reference pair. In representative logs, the test pair is roughly in the 300–400 peak-to-peak class versus approximately 600-class for the non-slipping reference pair, depending on slot and run.
- See Fig. 2 for a test-pair slip ADC capture
- See Fig. 5b again for dTOF vs time showing the reference pair remaining near zero while the test pair produces ±cycle-like jumps
Frequency-band testing showed that lower-center bands improved the test pair:
- Initial runs at 190–195 kHz center were clean, but repeats still showed occasional slips: 175/205 repeated at 1/18 fires slipped and 180/210 repeated at 2/24 fires slipped.
- These were still substantially better than the higher-center bands.
- 185/215 kHz and higher-center bands showed higher wrong-cycle rates.
- This suggests the test pair is sensitive to excitation band / waveform shape.
- See Table 2 ("Pair-2 cycle-slip evidence") for the frequency/gain summary.
Gain testing at 175/205 kHz:
- Test pair at 175/205 + 3.5 dB gain: clean in one run, no obvious clipping, pp improved to roughly 500–600 class.
- Test pair at 175/205 + 1.0 dB gain: still slipped, approximately 2/15 wrong-cycle events.
- Reference pair at 175/205 + 3.5 dB gain produced one outlier/slip event with a high-amplitude slot-2 capture in one safety-check run. We have not concluded that +3.5 dB is unusable, but it is not yet proven safe as a shared global gain.
- See Fig. 6 for the test-pair gain comparison.
Mechanical discriminator:
- We kept the reference pair electrically connected to CH1/J8-J3 and moved only its mechanical mounting location to the position associated with the test pair.
- The reference pair remained clean in that alternate mechanical location.
- This makes a gross mechanical mount/alignment issue less likely, though it does not rule out all coupling/seating effects.
- We can provide the mechanical discriminator plot/table if useful.

Our interpretation:

This looks consistent with cycle slipping / wrong-lobe locking rather than ordinary air motion, because the dTOF jumps land near integer acoustic-cycle offsets while the non-slip cluster remains tight.
AbsToF and dTOF values are still produced, and the capture/algorithm path does not report an error. However, the primary failure signature is that dTOF sometimes jumps by about one acoustic cycle while `ALG=122` is still reported. We interpret this as a possible wrong-lobe/cycle selection problem rather than a missing-capture problem.
The issue appears tied to the test pair’s waveform strength/shape/matching/configuration, not a total firmware/library failure.
Frequency band and gain both affect the behavior.
We have not yet found a shared configuration that keeps the test pair and the reference pair clean at the same time.
We have not run standard deviation testing yet because the test pair is not consistently locking cleanly.

Questions:

Does this evidence look consistent with cycle slipping / wrong-lobe locking in the USS library?
If the USS library reports valid results (ALG=122) during these events, is it expected that adjacent-cycle wrong-lobe locks can occur without an error code?
Why might the test pair produce cycle slips while the reference pair does not, when both are tested with the same firmware configuration, USS algorithm path, and similar open-air geometry?
After frequency sweep and moderate gain testing, what is TI’s recommended next diagnostic step?
- Try intermediate gain options between 1.0 dB and 3.5 dB?
- Adjust capture start / capture window?
- Adjust envelope threshold / search range / Hilbert-Wide parameters?
- Adjust pulse count?
- Sort/match transducers based on frequency response?
Are there specific USS parameters we should inspect for multitone Hilbert-Wide open-air operation to reduce these slips?
Are there waveform metrics you recommend we compute from UPS/DNS captures to decide whether the issue is amplitude, capture-window placement, waveform ambiguity, or transducer mismatch?
For a final open-air sensor with 2–3 transducer pairs, should all pairs be sorted/tuned to work under one shared USS configuration, or does TI recommend any per-pair characterization/configuration strategy?

Primary attachments:

Fig. A: schematic excerpt showing MSP430FR6043, external AFE, mux/steering, and custom connector labels
Table 1: TI GUI-style parameter table for the active USS configuration
Fig. 1: reference pair ADC capture
Fig. 2: test pair slip ADC capture
Fig. 5b: dTOF vs time showing reference pair near-zero cluster vs test pair ±cycle jumps
Table 2: frequency/gain summary table
Fig. 6: test-pair gain comparison

Supplemental data available if useful:

Clean test-pair ADC capture at 175/205 + 3.5 dB
Test-pair slip ADC capture at 175/205 + 1.0 dB
Reference-pair 175/205 + 3.5 dB outlier capture
Mechanical discriminator ADC capture/table
CSV versions of the parameter and summary tables
Raw UART logs

We can provide additional plots, raw UART logs, or specific diagnostic captures if useful. Thank you for any guidance on the recommended TI-native characterization path from here.

MSP430F6779A: Flash write (segment erase+program with interrupts disabled) degrades EM Software Library energy accuracy — clean when the write is removed

Jitain Sangwan — Tue, 23 Jun 2026 12:12:39 GMT

Part Number: MSP430F6779A

Device / SW: MSP430F6736A, SD24_B front end, MSP430 Energy Measurement (EM) Software Library (EVM430-F6736 / Energy Measurement Design Center). EM_SAMPLING_FREQ_HZ = 4096, mainNomFreq = 60, 60 Hz mains. SD24 ISR calls EM_perSampleProc; foreground EM_foregroundProc updates activeEnergy.

What we're doing: Periodically we persist energy/calibration data to main flash. Our routine disables global interrupts, erases one flash segment, programs it, then re-enables interrupts:

uint16_t ui16GIE = __get_SR_register() & GIE;
__bic_SR_register(GIE);
__disable_interrupt();

FCTL3 = FWKEY;
FCTL1 = FWKEY | ERASE;
*(uint8_t *)addr = 0;          // dummy write -> segment erase
FCTL1 = FWKEY | WRT;
memcpy(addr, &data, sizeof(data));   // program
FCTL1 = FWKEY;
FCTL3 = FWKEY | LOCK;

__bis_SR_register(ui16GIE);
__enable_interrupt();

On top of this, the same save also writes a backup copy to a second flash segment (flash_copy_primary_to_backup()) — another interrupt-disabled erase+program of the same form, run back-to-back with the primary. So a single save does two segment erase/program cycles, each with interrupts off.

Each erase+program takes ~60–65 ms with interrupts disabled, and the backup roughly doubles the total interrupt-off time, so the SD24_B sampling ISR (and therefore EM_perSampleProc) cannot run for that entire window.

Symptom: When this flash write runs anywhere near an active/just-finished metering session, our per-session energy total becomes inaccurate and non-repeatable (intermittent ~1 Wh / ~1% errors on a ~100 Wh session at ~5 kW). As soon as we comment out this flash write (user_flash_update(1)), the energy results become accurate and reproducible (error tightens to roughly ±0.15%). So the flash operation itself is clearly disturbing the metering.

Questions for TI:

What is the recommended way to write MSP430 flash on this part without disrupting the EM library's continuous SD24 sampling? During a flash erase/program with interrupts disabled, samples are necessarily missed — is there a supported approach (run the flash routine and/or ISR from RAM, keep the SD24 ISR serviced, minimize the interrupt-off window, etc.)?
After an unavoidable sampling gap (interrupts off for ~60 ms, ~120 ms with the backup), does the EM library recover on its own, or is there state (DC estimators, per-sample/per-chunk accumulators, ping/pong buffers) that gets left inconsistent and needs to be handled? Is there a recommended re-sync that does not require a full EMLibGUIApp_Init() (which forces a settling transient)?
Is there a TI-recommended pattern for persisting energy counters to flash in a continuously-running metering application (e.g., only write when no sampling is in progress, double-buffered segments, write timing relative to the measurement window)?

RE: MSP430F6779A: Flash write (segment erase+program with interrupts disabled) degrades EM Software Library energy accuracy — clean when the write is removed

Rahul Dahiya — Wed, 24 Jun 2026 08:11:13 GMT

Hi Luke,

Thanks. One clarification before I go further: the "recovers on its own" point covers instantaneous metrology (RMS, power), which I understand. My actual concern is the accumulated per-session energy total. Active energy is a time integral, so the energy during the interrupt-off window (~60 ms) is never integrated and stays permanently missing — correct power afterward doesn't add it back. My error (~1 Wh on a 100 Wh / 5 kW session, non-repeatable) is also far larger than the clean missing-window energy (~0.17 Wh), pointing to frame-boundary corruption plus DC/RMS settling, not just lost samples.

1. Is the active energy accumulator consumed/reset per computation frame? I need to know if a flash write landing mid-frame corrupts the in-progress chunk.

2. Please confirm the F6736A flash has no read-while-write path — i.e. even with the SD24 ISR in RAM, the vector table is in flash and can't be fetched during erase/program, so sampling can't continue through the operation. I want to stop treating "ISR in RAM" as a way to keep samples flowing.

Thanks,
Rahul

RE: MSP430F6779A: Flash write (segment erase+program with interrupts disabled) degrades EM Software Library energy accuracy — clean when the write is removed

Jitain Sangwan — Wed, 24 Jun 2026 07:09:02 GMT

Can we get any example how to run sd24ISR into ram

RE: MSP430FR5849: SMCLK stops at low temperatures.

Ichiro Nagai — Wed, 24 Jun 2026 06:48:14 GMT

教えてください。DCOCLKの発信元についてです。

MSP430FR2xxxは、XT1を発信元にできました。

しかし、MSP430FR5xxxのClockSystemの内部ブロック図を参照すると、

XT1に繋がっていません。DCOCLKの発信元は内部RC発振(LC発振)なのでしょうか？

MSP-FET: MSP430-Flasher compatibility with Windows 11

Melissa Mitrevski — Wed, 24 Jun 2026 06:13:38 GMT

Part Number: MSP-FET

Hello,

I would like to confirm whether the MSP430-Flasher (MSP430-FLASHER command line tool) is officially supported on Windows 11. The latest user guide I am referencing is SLAU654E (Revised February 2019), which lists support up to Windows 10. I would like to know:

Is MSP430-Flasher compatible with Windows 11?
Are there any known limitations or required workarounds?

Is there an updated version of the tool or documentation that includes Windows 11 support?

Kind Regards,

MSP Flasher User Guide version E.pdf

MSP430FR5043: Question about oscillator frequency tolerance impact on TOF measurement accuracy in MSP430FR5043

?? ?? — Tue, 23 Jun 2026 05:33:08 GMT

Part Number: MSP430FR5043

Dear Texas Instruments Support Team,

I would like to inquire about the MSP430FR5043.

My understanding is that the MSP430FR5043 measures propagation time using an 8 MHz oscillator. However, the oscillator has temperature characteristics, and the actual output frequency may deviate from 8 MHz by approximately 0.4%.

For example, if the clock signal generated by the oscillator and supplied to the MSP430FR5043 is 7.984 MHz, the number of clock cycles used to measure the propagation time would decrease. On the other hand, the internal calculations in the MCU are performed assuming an 8 MHz clock. Therefore, I believe that the calculated propagation time may be smaller than the actual (true) value.

Could you please confirm whether this understanding is correct?

In my application, the target system is a water meter, and the operating water temperature range is from 5°C to 55°C.
Given this condition, I would appreciate your advice on how to compensate for the oscillator’s temperature characteristics (frequency drift) in order to improve measurement accuracy.

Thank you in advance for your assistance.

Best regards,