MSP low-power microcontroller forum - Recent Threads

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

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.

MSPM0G3107: Request for LIN Based Bootloader Base SW code for MSPM0G3107

Desingh Raj Mani — Fri, 19 Jun 2026 13:46:15 GMT

Part Number: MSPM0G3107

Hi ,

we are using MSPM0G3107 micro for our switch based automotive projects. Request to have LIN Based Bootloader for flashing purpose and could used for EOL production. The flashing shall be performed either Vflash or Canape.

Please provide more details of SW for LIN Based Bootlaoder and MCAL package has been already provided but ours is non Autosar based so how could we adapt the MCAL provided to our project without using any generation tool.

Please gives us clarity on this since we create ECU SW for production for customers.

Thanks in advance.

MSP430-GCC-OPENSOURCE: Vendor and Technology Security Assessment

Matthew Rodriguez — Thu, 18 Jun 2026 21:39:02 GMT

Part Number: MSP430-GCC-OPENSOURCE

I need to use the MSP430-GCC-OPENSOURCE tools to continue the development of a medical device. I am looking for a primary contact to provide Vendor information for the assessment by my organization's IS department.

MSPM0G3107-Q1: UART DMA Rx Issue

Jopaul Joseph — Thu, 18 Jun 2026 11:54:41 GMT

Part Number: MSPM0G3107-Q1

I am trying to receive packets of UART Data. I have configured the UART RX to happen via DMA. The transfer is also happening as expected. The failure use case is as follows:
When a few bytes, say 1 or 2 bytes, are receved before the next DMA reception transfer is configured,
the RXINT bit in the DMA_TRIG_RX is set. I tried clearing/flushing the bytes from the RXDATA FIFO, till the FIFO Empty bit is set (RXFE), also afterwards, I tried manually clearing the RXINT in DMA_TRIG_RX and RXINT in CPU_INT by writing to corresponding ICLR. Still the RXINT in DMA_TRIG_RX is remaining as high. So when DMA is configured next time, one random byte is getting copied, after this copy, the RXINT is getting reset.

Please suggest a way to get this RXINT to be cleared between DMA configurations. I want the bytes that come in between to be discarded

MSPM33C321A: Serial Data Stream

Keith Barkley — Thu, 18 Jun 2026 02:42:41 GMT

Part Number: MSPM33C321A

I need to generate a 5 MB/S serial datastream (200 ns per bit). There are no start or stop bits, just continuous data. (If any one cares, this is data conforming to the IRIG telemetry standard.)

I would like to create the 300 byte or so frame, use DMA or something to send its on its way, and use the 60 us to create another frame which will take the place of the currently transmitting frame when it is done.

I can’t seem to remove the start and stop bits from the UART, so that is out, but could I use SPI for something like this?

Also, I am not wedded to the MSPM33C321, if there is another MCU that can do the job.

MSP430F2618: MSP430F2618 having consistent I/O related malfunctions

Michel Landry — Wed, 17 Jun 2026 11:17:57 GMT

Part Number: MSP430F2618

Hello TI Support Team,

I am looking to reboot Case CS3164948 regarding the suspected reliability issue with the MSP430F2618TPNR covering devices manufactured between 2022 and 2023. It has been many weeks without progress, and I want to get this case moving again.

To recap the situation:

We have confirmed many field failures across multiple lots of MSP430F2618TPNR, all showing consistent I/O related malfunctions.
Replacing the MSP430 resolves the failures, indicating that the device itself is the likely root cause in our product.
We have provided all requested information, including purchase history, PO details, failure descriptions, and supporting technical data. CE3 has supplied its own records directly to TI.
Multiple follow-ups since January 7 have not resulted in progress or clarity on TI’s next steps.

Given the above, We are requesting the following from TI:

Clarification
We do not have a PCN document number. We are asking TI to confirm whether one exists for this device and timeframe.
Next Steps for Failure Analysis
Please outline what is needed for TI to:
• reopen or advance Case CS3164948
• accept affected units for failure analysis
• provide an engineering contact to continue the investigation

If anyone else has any information on part changes that may have happened, any help would be appreciated.

MSP430F6775A: Can JTAG be re-enabled by JTAG Mass Erase after programming 0x55555555 to 0x17FC?

MF — Wed, 17 Jun 2026 07:01:36 GMT

Part Number: MSP430F6775A

Hello TI experts,

I need a precise answer specifically for the MSP430F6775A device.

My understanding is that on MSP430F5xx/F6xx devices, JTAG access can be locked by programming a non-zero/non-0xFFFFFFFF value into the JTAG lock key location at 0x17FC–0x17FF. In our case, the value programmed is 0x55555555. According to TI documentation, these addresses are located in the protected BSL area.

My question is:

After the device has been locked by writing 0x55555555 to address 0x17FC, is it possible to reconnect through JTAG and perform a Mass Erase operation that changes the contents of 0x17FC–0x17FF back to 0xFFFFFFFF, thereby restoring JTAG access?
Or, once the device is locked, is BSL access mandatory to remove the JTAG lock?

I have seen different behaviors across various MSP430 families (classic fuse-based devices, F5xx/F6xx lock key implementation, FRAM devices, etc.), so I would like to obtain a definitive answer specifically for the MSP430F6775A.

Thank you very much for your help.

Best regards,

MSPM33C321A: XM33C321ASZAWR Unable to execute the Erase command

MING CHEN — Wed, 17 Jun 2026 05:40:19 GMT

Part Number: MSPM33C321A

Hi team

According to the implementation of the SDK Example, before performing the Flash Erase/Program operation, we will first carry out the Flash Semaphore acquisition operation:
1. Write GSC_FPC_FLSEMREQ
2. Read GSC_FPC_FLSEMSTAT to confirm that the Semaphore acquisition is successful
3. Poll steps 1 and 2 repeatedly until the Semaphore acquisition is successful

However, when using the model XM33C321ASZAWR to read GSC_FPC_FLSEMSTAT, the returned value is always 0x00000000. The Semaphore cannot be acquired successfully, so the subsequent erasure operation cannot be continued.

Using MSPM33C321ASZAWR works normally. May I ask what are the differences between the two? Are there any other operations specific to XM33C321ASZAWR?

The following picture shows MSPM33C321ASZAWR

The following picture shows XM33C321ASZAWR

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
Other Parts Discussed in Thread: MSP430FR6043

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.

MSP430-GCC-OPENSOURCE: Energia Windows Drivers

Ryan Kehr — Tue, 16 Jun 2026 16:34:48 GMT

Part Number: MSP430-GCC-OPENSOURCE
Other Parts Discussed in Thread: ENERGIA, MSP430FR2433

I noticed that the link to download the Energia Windows drivers ("LaunchPad CDC drivers zip file for Windows 32 and 64 bit (s3.amazonaws.com/energiaUS/files/energia_drivers.zip)") does not appear to be working. When I try to access it, I receive an "Access Denied" message.

Do you know if there is an updated location for these drivers, or if the link will be updated soon? Alternatively, would it be possible for you to share the driver package with me or recommend the appropriate drivers to use with the MSP430FR2433 LaunchPad?

MSPM33C321A: Stepper motor board for upcoming Motor control SDK

Keith Barkley — Tue, 16 Jun 2026 12:51:36 GMT

Part Number: MSPM33C321A

I know I am too late for you to actually take this suggestion, but for the upcoming SDK with motor control, are you planning to use one of the Click boards for the mikroe connector on the launchpad? They have several that use TI chips, and it will allow use of the connector to show off the capability.

Also fewer flying wires than if you use an existing TI evm. 8^)

MSPM0G3505: Feasibility of MSPM0G350x as SPI bridge with simple response modification

Conor — Tue, 16 Jun 2026 07:28:20 GMT

Part Number: MSPM0G3505

Hi,

I am considering using an MSPM0G350x MCU as a simple SPI bridge between a host controller and an ASIC.

The intended configuration is:

Host SPI Master

<-> MSPM0G350x SPI Peripheral

MSPM0G350x SPI Controller

<-> ASIC SPI Peripheral

The MSPM0G350x would receive an SPI command from the host, check a specific 3-bit command field, access the ASIC via another SPI port, and return either modified or unmodified response data to the host.

I am considering MSPM0G350x because it has two SPI modules, DMA support, and an 80MHz Arm Cortex-M0+ CPU.

Could you please confirm the following?

1. Is MSPM0G350x suitable for this SPI bridge use case, where one SPI is used as a peripheral/slave and the other SPI is used as a controller/master?

2. If the host sends a command byte first and then provides one or more dummy bytes before reading the response, can MSPM0G350x receive the command, check the 3-bit code, prepare the response, and transmit it back within the same SPI transaction?

3. Are there any MSPM0G350x reference examples for SPI peripheral mode with DMA/FIFO, or SPI-to-SPI bridge operation?

The response modification is simple, such as bit masking or fixed-pattern substitution.

No complex CRC recalculation is required.

Best regards,

Conor

LP-MSPM0G3507: Syscfg Error Popup Window When Trying to Assign Pin to ADC12 and OPA Input

Michael V — Tue, 16 Jun 2026 05:15:27 GMT

Part Number: LP-MSPM0G3507
Other Parts Discussed in Thread: SYSCONFIG

Hello,

I have a client who is developing on an MSPM0G, with the following environment:

CCS 20.5.0.28_1.11.0
MSPM0 SDK 2.10.0.04
Sysconfig 1.27

They desire a way to assign a signle pin, in their case PA25, to be both the input to ADC12 and an input to OPA (to route to COMP for high-speed fault detection).

When attempting to assign the pin as an input to both ADC and OPA, they get an error window stating a TypeError.

I was able to replicate a similar situation easily by doing the following:

Demo Project: adc12_single_conversion

Syscfg changes:

Add OPA
Non-Inverting Channel IN1+ pin

Error window:

Given the above, my client has the following questions:

What is the meaning of this error window, and how can we prevent it?
Are there any workarounds to enable a single pin as the input to both ADC and OPA at the same time?

Best regards,

Michael

MSP430FR6007: Issue getting CPU in Full-Emulation-State using 4-wire JTAG

Daniel Mishurisman — Mon, 15 Jun 2026 10:35:10 GMT

Part Number: MSP430FR6007

I implemented the flow described in User’s Guide MSP430™ Programming With the JTAG Interface, Figure 2-15, to get the CPU in the Full-Emulation-State.

Following the 4-wire JTAG-entry sequence, I receive the correct JTAG ID.

When checking if the Lock key is programmed by shifting 0xAAAA, TDO output value is 0x7FFF.

In function GetCoreipIdXv2() target returns 0x7FFFF as DeviceIdPointer.

Even after executing the specified function SyncJtag_AssertPor(), all I receive from the target device on TDO is 0x7FFF for 16 bit DR-Shifts and 0x7FFFF for 20 bit DR-Shifts. While IR-Shifts all correctly return JTAG ID 0x99.

Comparing the trace of my implementation to the trace produced by the MSP-FET430UIF, I dont recognize any difference in entry sequence, shifting operations or TCLK clocking.

Is there anything I am missing? Any additional sequence needed? Known Issues?

Thanks a lot in advance.

MSP432E401Y: Unable to flash LP-MSPMOL1306 Rev A using Keil uVision.

Justin Jackson — Fri, 12 Jun 2026 16:45:09 GMT

Part Number: MSP432E401Y
Other Parts Discussed in Thread: MSPM0L1306,

Attempting a flash download in Keil uVision v5.49 using XDS110 with CMSIS-DAP debugger, MSPMOL_11XX_L13XX_DFP@1..3.1, and the 6.24 ARM Compiler.

The power up request is sent to the device and it begins executing the power up sequence. After this the following errors are generate generated by uVision.

Ive made sure the device is set to the MSPMOL1306 inside Target. Ive pasted my debugging settings for review. This could be a uVisionspecific error, since CCS and OpenOCD can flash the board fine. Any help would be greatly appreciated.

MSP432E401Y: Does the C-GANG programmer work with MSP432 microcontrollers?

Brian Ishaug — Fri, 12 Jun 2026 15:56:38 GMT

Part Number: MSP432E401Y

The MSP432 is not explicitly listed as a supported microcontroller.

MSP430I2041: Information memory usage

savita morab — Fri, 12 Jun 2026 08:59:46 GMT

Part Number: MSP430I2041
Other Parts Discussed in Thread: UNIFLASH

I am using MSP430I2041 controller in my project: Name: Transducer

I was storing application data in Information Memory, but the TLV data also got erased. To avoid this, I moved the data storage to Main Flash Memory.

However, the data in Main Flash gets erased whenever I reprogram the device. Could you please suggest the recommended way to store user data so that it is retained during firmware updates/reprogramming while also ensuring that TLV data is not affected?

Any guidance or recommended practices would be greatly appreciated.

We have completed all other tests and project is about to be launched

Just for this crucial problem project may get on hold

Kindly confirm on urgent basis

MSPM0L1228: Pre-programmed production files (.bin) boot into BSL due to external pull-up on BSL invoke pin, while CCS

Will Tsai — Fri, 12 Jun 2026 08:25:48 GMT

Part Number: MSPM0L1228
Other Parts Discussed in Thread: SYSCONFIG

Hi Team,

My customer's board design requires an external pull-up resistor on the BSL Invoke Pin. To prevent the device from entering BSL on boot, we disabled the "Enable BSL Invoke Pin Check" in SysConfig and set the flash option to "Erase MAIN and NONMAIN necessary sectors only".

Here is the issue:

CCS Flashing (OK): When flashing via CCS, the board boots normally into the MAIN application.
Factory Pre-programming (FAIL): When the production vendor pre-programs raw chips using the generated .bin file, the assembled boards always boot directly into BSL mode upon power-up.

We suspect that the .bin file only contains the MAIN flash region, leaving the NONMAIN/BCR configuration sector blank (all 0xFF) on raw chips, which triggers the BSL due to the hardware pull-up.

Could you please guide us on how to correctly configure the project or post-build steps to generate a unified production image (combining both MAIN and NONMAIN sectors) so the factory can mass-program raw chips successfully?

MSP430G2553: External ADC code to check my Digital counts

Nishant Gupta — Fri, 12 Jun 2026 03:10:06 GMT

Part Number: MSP430G2553
Other Parts Discussed in Thread: ADS7049-Q1, MSP-EXP430G2ET,

Hello,

I am using the MSP-EXP430G2ET LaunchPad with the MSP430G2553 MCU and an external ADS7049-Q1 12-bit SPI ADC for temperature sensing.

The ADS7049-Q1 is configured with:

External reference voltage = 2.5 V
SPI interface using SCLK, SDO, and CS
ADC input range = 0 V to 2.5 V

I have a few questions regarding the hardware interface and software setup:

Since the ADS7049-Q1 operates with a 2.5 V supply/reference, should the SPI signals (SCLK, SDO, and CS) also be limited to 2.5 V?
The MSP430G2553 LaunchPad is powered from USB and its GPIO pins operate at approximately 3.3 V. Can the ADS7049-Q1 safely interface directly with these SPI signals, or is level shifting required to avoid damaging the ADC?
Is there any recommended TI example code or driver for interfacing the ADS7049-Q1 with the MSP430G2553 using the hardware SPI peripheral?
For software development, should I use Code Composer Studio (CCS) for the MSP430G2553 LaunchPad?Or any MSP430 software i need to download tell all. If so, could you please recommend the appropriate CCS version and any required MSP430 SDK or support packages?
Are there any recommended hardware or software considerations to ensure accurate conversion results and correct calculation of ADC counts when using a 2.5 V reference?

Thank you.

MSPM0L1105: Unable to communicate with ROM BSL when using invoke pin

Chris F — Thu, 11 Jun 2026 16:42:42 GMT

Part Number: MSPM0L1105
Other Parts Discussed in Thread: SYSCONFIG

Hello,

My company is using the MSPM0L1105 as a I2C slave device. We plan on having the ability to update the MSPM0 application code via the BSL. However, we are having issues when entering the BSL via the invoke pin.

Background:

We are using the MSPM0L1105 with the WQFN-16(RTR) package. The full product name is MSPM0L1105TRTRR. Notably, for this product, the default I2C SCL pin is on the same pin for NRST (the pin name is PA1/NRST).

The MSPM0 application blinks an LED. When the LED isn't blinking and the power is on, the MSPM0 is presumably in the BSL. The application slave address is 0x11.

The master I2C device is an ARM processor running Linux.

In the syscfg, the BSL invoke pin is PA23/PA25, and the BSL invoke pin level is high. The BSL slave address is 0x48.

In the syscfg, the NRST pin is disabled.

When the application enters the BSL with the function DL_SYSCTL_resetDevice(SYSCTL_RESETLEVEL_LEVEL_BOOTLOADERENTRY), the master able to communicate with the BSL. Running the command utility i2cdetect from the master results in the I2C driver on the master to timeout when querying for slave address 0x48. When firmware is programmed for the master device to interact with the BSL using the BSL protocol defined by TI, we are able to communicate with it just fine. The purpose of mentioning i2cdetect is to establish its behavior when we are able to communicate with the BSL.

Although it is great we can communicate with the BSL when entering it with this method, we need the ability the enter it without the application.

Problem:

When the invoke pin is set to high (invoke BSL) and the power is turned on, the LED does not blink. Presumably, this means the MSPM0 is in BSL. When the master runs i2cdetect, there is no timeout on address 0x48. Without turning off power, the invoke pin is set to low (invoke application). When i2cdetect is ran, the LED starts blinking, which means the application is running. Running i2cdetect again confirms there is a slave with the address 0x11.

I believe what is happening is that the BSL does not disable the NRST pin. Thus, when there is I2C communication, the MSPM0 is being reset. This is most clear when the invoke pin being set to invoke the application, and I2C communication results in the MSPM0 running the application.

Am I correct with my conclusion? Is there a way to fix this?

MSP430F5528: USB product ID

Jean-Philippe Verschueren — Thu, 11 Jun 2026 11:03:20 GMT

Part Number: MSP430F5528

I have already applied several times to receive an USB PID from TI using the form/email on your site. I have never get any answer.
Is it still possible to receive USB PID from TI when using TI VID?

MSPM0G5117: How to modify NOMAIN

Jerry Kuo — Thu, 11 Jun 2026 02:24:05 GMT

Part Number: MSPM0G5117
Other Parts Discussed in Thread: UNIFLASH

Hi team,

My customer use M0G5117. They want to modify the default BSL invoke pin. They ask if they need to use XDS110 (through SWD) & Uniflash/CCS to modify NOMAIN, else they can use I2C to modify NOMAIN ?

MSP430FR6043: The PGA of SDHS

Tommy — Wed, 10 Jun 2026 14:12:56 GMT

Part Number: MSP430FR6043

Hi E2E,

I would like to know the gain-bandwidth product, slew rate, and offset voltage of the PGA in the SDHS function block.

Thanks

MSP430FR5887: Code generation issue using FlowESIGUI

user4237831 — Wed, 10 Jun 2026 08:47:52 GMT

Part Number: MSP430FR5887

After generating code using FlowESIGUI, I found that it did not calibrate well during runtime. Upon reviewing the code, I discovered that VALID_RECALIBRATION and RECALIBRATION_TIMEOUT were not cleared. The consequences of not clearing VALID_RECALIBRATION were not identified, but the failure to clear RECALIBRATION_TIMEOUT resulted in the immediate exit of ReCalScanIF upon entering it for the second time. Therefore, I would like to inquire whether these two items not being cleared are a bug. Additionally, the RECAL_TIME_OUT is set to 2 seconds, so does it mean that the metal piece must rotate 4 times within 2 seconds for ReCalScanIF to complete normally? If the watch can only rotate once per second, would it never be able to complete ReCalScanIF.

MSPM0G3507-Q1: The rise and fall rate on the MSPM0G3507 general input.

shihui xu — Wed, 10 Jun 2026 07:26:11 GMT

Part Number: MSPM0G3507-Q1
Other Parts Discussed in Thread: TXB0104, MSPM0G3507

Does it matter when the input signal rises or falls between 0-3.3V at a super low rate(several minutes)? The GPIO of M0G3507 was configured as an edge-triggered input. The reason I ask is that we once had some problems using the level shifter product (TXB0104), which has a maximum rise and fall rate limit.