Arm-based microcontrollers forum - Recent Threads

RE: AM263P4: UniFlash reset

Neil Wilson — Sat, 27 Jun 2026 05:56:25 GMT

What is happening when UniFlash says:

[INFO] Cortex_R5_0: GEL Output: CPU reset (soft reset) has been issued through GEL on program load

I very often see no reset of the processor and UniFlash fails.

Are there reasons why a "soft reset" would fail to reset the MCU?

The only way I can program the board is to try and time a physical reset and click "Load Image"

Regards

Neil

AM263P4: UniFlash reset

Neil Wilson — Tue, 23 Jun 2026 13:07:36 GMT

Part Number: AM263P4

I'm using the XDS110 JTAG debugger connected via a 10pin Cortex cable to our AM263P4 board.

When I use UniFlash (v 9.5.0.5651) I quite often find the board not being reset by the XDS110 and consequently the programming fails.

I can see this line in the console output on UniFlash but no reset happens.

[INFO] Cortex_R5_0: GEL Output: CPU reset (soft reset) has been issued through GEL on program load.

Is there a way to get the XDS110 and/or UniFlash to provide a proper hardware reset using the RESET output ?

Regards

Neil

AM13E23019: AM13E23019: JTAG Connection Error -6305 (PRSC module failed to write to a router register) on Custom Board

Junsin Park — Fri, 19 Jun 2026 05:54:14 GMT

Part Number: AM13E23019

Hello TI Experts,

I am experiencing a JTAG debugging issue with the AM13E23019 MCU on our newly assembled custom boards. Out of 4 boards tested, 2 boards work fine, but the other 2 boards consistently fail to launch the debug session in Code Composer Studio (CCS).

Interestingly, the "Test Connections" (Integrity scan-test) ALWAYS succeeds on all boards, regardless of the actual debug launch success or failure.

Below are the detailed system configurations and test results.

1. Hardware

Target MCU: AM13E23019
Power Supply: 3.3V is supplied by the TPS65036501RAYRQ1 PMIC.
Debugger: XDS110
Emulation Package: 20.5.0.3920

2. Problem Symptoms

Debug Launch Error Log (Fails on Board #8 and #9):

Error connecting to the target: (Error -6305) PRSC module failed to write to a route

Scope Measurements during Failure:
- The 3.3V power rail remains clean and completely stable.
- The RESET pin stays stable at High (3.3V).
- The 25MHz crystal (XTAL) clock is outputting a normal, clean waveform.

JTAG Configuration Adjustment:
- Lowering the JTAG TCLK from 5.5MHz down to 1.0MHz or 100kHz does not solve the issue.

3. Detailed Test Results by Board

Board #10 (Partially Working / Timing Dependent)

Condition: Kept unpowered for more than 24 hours to completely discharge.
Case 1: Constant Power Continuous Test
- Turned on the power supply (48V / 0.5A) and executed DEBUG 10 times consecutively without power-cycling.
- Result: 10/10 Successfully connected. (Successfully loads Flash Loader and programs flash).

Case 2: Power-Cycle Test
- Power-cycling (Off/On) between each debug launch.
- Result: 4/10 Success. (Intermittent success/fail pattern: Fail, Fail, Success, Fail, Fail, Success, Fail, Success, Fail, Success).

Board #9 (Consistently Failing)

Condition: Kept unpowered for 30 minutes.
Case 1 (Constant Power) & Case 2 (Power-Cycle): 0/10 Success (100% Fail with Error -6305).
Case 3 & 4 (Power Variation): Changed power input to 48V/1.0A or 12V/1.0A. Still 100% Fail.

Board #8 (Consistently Failing)

Condition: Kept unpowered for more than 24 hours.
Case 1 & Case 2: Tested at 12V / 1.0A input. 0/5 Success (100% Fail).
Case 3 (TCLK change): Dropped TCLK down to 100kHz. Still 100% Fail.

RE: AM13E23019: AM13E23019: JTAG Connection Error -6305 (PRSC module failed to write to a router register) on Custom Board

Matt Kukucka — Fri, 26 Jun 2026 22:28:02 GMT

Hello,

Thank you for this information. I will be OoO for the next few weeks so I re-assigned this thread to another expert to help support. Please expect a delay in assistance.

Best,
Matt

MSPM0G1507: MCLK Switch and SYSOSC Sleep1 Behavior

Stuart Baker — Fri, 19 Jun 2026 21:43:19 GMT

Part Number: MSPM0G1507

Customer is trying to setup the device with the following configuration:

Start with MCLK=SYSOSC in 32MHz mode.
Transition MCLK to LFCLK (LFXT already started ~30 seconds earlier).
Set SYSOSC to 4MHz.
Goto Sleep 1 (with SYSOSC running at 4MHz).

Both the customer and myself have prototyped the impelemntation, using similar sequencing, but cannot get the desired result.

    DL_SYSCTL_switchMCLKfromSYSOSCtoLFCLK(false);
    DL_SYSCTL_setSYSOSCFreq(DL_SYSCTL_SYSOSC_FREQ_4M);
    __WFI();

When I run the above sequence, the result is the following problems:

The switch over from SYSOSC to LFCLK is taking ~700+ microseonds. That is way too long for the customer applicaiton, and I can't understand why it would need so much time. This is verified by GPIO toggle instrumentation.
The SYSOSC frequency is still 32MHz (verified by routing it to the CLKOUT pin).

I have tried various alternatives such as switching the SYSOSC to 4MHz before the MCLK switch over, and substituting DL_SYSCTL_switchMLKfromSYSOSCtoLFCKL() API for DL_SYSCTL_setPowerPolicyRUN1SLEEP1(). The result is always the same. If we look at where the bulk of the ~700 microseconds is being spent, it looks like it is being spent in the following loop:

while ((DL_SYSCTL_getClockStatus() & SYSCTL_CLKSTATUS_CURMCLKSEL_MASK) !=
           DL_SYSCTL_CLK_STATUS_MCLK_SOURCE_LFCLK) {
        ;
    }

Why does it take so long since the 32kHz crystal is already running (30 seconds prior)? Do we need to wait in this loop? What are the consequences if we don't wait in the loop?

Also, how to get the SYSOSC to be 4MHz after switching the MCLK away from it?

Thanks,

Stuart

RE: MSPM0G1507: MCLK Switch and SYSOSC Sleep1 Behavior

Stuart Baker — Fri, 26 Jun 2026 21:31:30 GMT

Customer believes the 32kHz crystal is stable before they start the switch over. They start the 32kHz crystal 30 seconds before starting the switch over. I also did the same when reproducing the result.

The while loop at the end of the clock switch API is where we observe the largest component of the ~700us total. What is the consequence if we do not wait in this delay loop (extract the method and remove the while loop) and instead go directly to sleep (__WFI())?

Thanks,

Stuart

TM4C1294KCPDT: DIVSCLK PQ4 MCU pin 102 no MOSC, PIOSC, SYSCLK divided output

Genatco — Fri, 26 Jun 2026 16:28:48 GMT

Part Number: TM4C1294KCPDT

Hello,

Configuring the divsclk output for any of the clock sources produces no signal. The crystal MOSC is 25MHZ and SYSCLK 120MHz and the application is functional only divsclk outptu is not. I need 20MHz clock source for another MCU without a crystal and this really should be a no brainer.

SysCtlClockOutConfig(SYSCTL_CLKOUT_SYSCLK | SYSCTL_DIVSCLK_EN, 6);

Yet when PQ4 is configured as GPIO and write 1 to the output it asserts the comanded state. Is there some reason the GPIO will not work as an alternate or is there an undocumented method left out opf the data sheet to make it produce DIVSCLK? This same control worked on the 1294NCPDT laucn pad dilicon revision RA2 but it is doing nothing on 1294KCPDT and not listed as an eratta.

RE: TM4C1294KCPDT: DIVSCLK PQ4 MCU pin 102 no MOSC, PIOSC, SYSCLK divided output

Genatco — Fri, 26 Jun 2026 21:28:24 GMT

The datasheet leaves out a WPU is required for the GPIO PQ4 output, and it must be configured a peripheral, The last part is ridiculous since it is illustrated as part of the clock tree Fig.5-5 and not a peripheral alternate function. The datasheet only mentions that if PQ4 if made NMI source must first unlock the pin same as for GPIO PD7 to use as analog input.

Anyhow after seeing another post that Charles answered without the very important point that a weak pullup is required to get a signal output on PQ4.

RE: MSPM0G1507: MCLK Switch and SYSOSC Sleep1 Behavior

Owen Li — Fri, 26 Jun 2026 21:25:21 GMT

Hi Stuart,

You are right, it is not possible to output MCLK from CLKOUT. I overlooked this in my previous reply.

I would suggest analyzing how many instructions and clock cycles it takes for the code executes between the GPIO toggling.

When I performed my own test, I observe the delay to only be ~280us. I tested this on a LP-MSPM0G3507 where I inserted a 30s delay upon the LFCLK starting up, then extracted the DL_SYSCTL_switchMCLKfromSYSOSCtoLFCLK() function where I set a GPIO output before MCLK is switched and clear the GPIO after the while loop.

Did the customer observe that the crystal was stable?

Best,

Owen

EK-TM4C123GXL: EK-TM4C123GXL cannot get to work on my laptop

Josel Go — Fri, 19 Jun 2026 16:10:18 GMT

Part Number: EK-TM4C123GXL

Hi Experts,

So sorry for not responding, but I have a TM4C123GXL that I cannot get to work on my laptop at all, can you help me out please?

It's not showing up on the device manager or on the LM Flash Programmer or the CCS, so I dont know what to do to get it to show up.

My TM4C123GXL when connected via DEBUG mode lights up the PWR LED but does not show on the laptop, so I cannot flash it or unlock it

I attempted to press and hold RESET while connecting to PC, but still nothing is happening, and I tried to troubleshoot it, but I cannot

I am using Tiva C Series LaunchPad Evaluation Kit EK-TM4C123GXL

It was working before, but when I tried to do a firmware update using LMFLASHPROGRAMMER it instantly stopped responding and I cannot get it to respond any more. but the PWR LED is still ON, so it is getting power, but no longer connecting via USB.

Regards,

Josel

RE: EK-TM4C123GXL: EK-TM4C123GXL cannot get to work on my laptop

Erik Vaughn — Fri, 26 Jun 2026 21:21:37 GMT

Hi Josel,

I believe there's an issue with the XDS110 on the board. If you have another Launchpad you can flywire the XDS110 launchpads together.

Please let me know if you have another one available.

RE: MSPM0G1507: MCLK Switch and SYSOSC Sleep1 Behavior

Stuart Baker — Fri, 26 Jun 2026 20:54:55 GMT

Owen,

How can I bring MCLK out to the CLKOUT pin? It does not look like an option either in the TRM or in SysCfg.

Thanks,

Stuart

RE: MSPM0G1507: MCLK Switch and SYSOSC Sleep1 Behavior

Owen Li — Fri, 26 Jun 2026 20:50:06 GMT

Hi Stuart,

Changing SYSOSC to run at 4MHz is possible. However, it should not be changed after switching MCLK to be sourced from LFCLK (See the screenshot at the bottom of my previous reply).

With that in mind, this makes me want to believe that it is not possible to have SYSOSC run at 4MHz while MCLK is sourced from LFCLK.

As for the delay you observed, the design team gave a guts-feel number of maybe 200us that they would expect for the switch. A suggestion is to bring out the MCLK frequency out on the CLKOUT pin so that you can observe when the clock signal actually changes, rather than relying on SW clock cycle uncertainty. You could still utilize a GPIO signal to represent the "timestamp" before switching to LFCLK.

Best,

Owen

AM3356: When the CPU governor is set to "ondemand," some IRQ threads occupy the CPU for a long period.

Takeharu Katsuyama — Thu, 25 Jun 2026 02:16:47 GMT

Part Number: AM3356

Hi, expert

When the CPU governor is set to "ondemand," some IRQ threads sometimes occupy the CPU for periods of 400 to 500 ms.
Please refer to the ftrace logs below.
The IRQ threads in question are `irq/42-mmc0-60` and `irq/57-wl18xx-260`.

This issue occurs when transmitting a file of approximately 4 MB via CAN0.
The CAN frame transmission interval is approximately 0.5 ms.
The communicating device aborts the connection if it fails to receive frames for 200 ms or longer.
Therefore, it is necessary to prevent this situation.

This phenomenon did not occur with kernel version 4.19.94.
It also does not occur when the CPU governor is set to "performance" or "userspace" to lock the clock speed.
The issue does not occur even when the clock speed is fixed at 300 MHz using the "userspace" setting.

As a temporary workaround, we plan to set the CPU governor to "performance" in the transmitting.
We believe a permanent solution requires fixing the problematic section within the kernel.
Could you please advise us on the cause of this phenomenon and the appropriate countermeasures?

- conditions
- SDK: 9.3
- kernel version: 4.1.119 00b127e50fa09f9bd35c66ac3011861392d9a750
- kernel config: '.config-governor' in attached config_devicetree.tar.gz
- device tree: 'am335x-jrn430k.dts' in attached config_devicetree.tar.gz

- ftrace log
------ case 1 ftrace start --------------------------------------
MW_CAN0-3070 [000] d..2. 676.839206: sched_switch: prev_comm=MW_CAN0 prev_pid=3070 prev_prio=118 prev_state=S ==> next_comm=kworker/0:5 next_pid=52 next_prio=120
kworker/0:5-52 [000] d..2. 676.839255: sched_switch: prev_comm=kworker/0:5 prev_pid=52 prev_prio=120 prev_state=D ==> next_comm=rcu_preempt next_pid=13 next_prio=120
rcu_preempt-13 [000] d..2. 676.839287: sched_switch: prev_comm=rcu_preempt prev_pid=13 prev_prio=120 prev_state=I ==> next_comm=kworker/0:0 next_pid=4019 next_prio=120
kworker/0:0-4019 [000] d..2. 676.840676: sched_switch: prev_comm=kworker/0:0 prev_pid=4019 prev_prio=120 prev_state=R+ ==> next_comm=ksoftirqd/0 next_pid=12 next_prio=48
ksoftirqd/0-12 [000] d..2. 676.842618: sched_switch: prev_comm=ksoftirqd/0 prev_pid=12 prev_prio=48 prev_state=S ==> next_comm=irq/42-mmc0 next_pid=60 next_prio=49
--> irq/42-mmc0-60 [000] d..2. 677.239713: sched_switch: prev_comm=irq/42-mmc0 prev_pid=60 prev_prio=49 prev_state=R+ ==> next_comm=ksoftirqd/0 next_pid=12 next_prio=48
ksoftirqd/0-12 [000] d..2. 677.240032: sched_switch: prev_comm=ksoftirqd/0 prev_pid=12 prev_prio=48 prev_state=S ==> next_comm=irq/42-mmc0 next_pid=60 next_prio=49
irq/42-mmc0-60 [000] d..2. 677.240380: sched_switch: prev_comm=irq/42-mmc0 prev_pid=60 prev_prio=49 prev_state=S ==> next_comm=APL_WS next_pid=599 next_prio=120
APL_WS-599 [000] d..2. 677.242447: sched_switch: prev_comm=APL_WS prev_pid=599 prev_prio=120 prev_state=S ==> next_comm=kworker/0:4 next_pid=51 next_prio=120
------ case 1 ftrace end ----------------------------------
------ case 2 ftrace start ---------------------------------
APL_MC-533 [000] d..2. 1295.469869: sched_switch: prev_comm=APL_MC prev_pid=533 prev_prio=120 prev_state=R+ ==> next_comm=ksoftirqd/0 next_pid=12 next_prio=48
ksoftirqd/0-12 [000] d..2. 1295.472254: sched_switch: prev_comm=ksoftirqd/0 prev_pid=12 prev_prio=48 prev_state=S ==> next_comm=irq/57-wl18xx next_pid=260 next_prio=49
-->irq/57-wl18xx-260 [000] d..2. 1295.986965: sched_switch: prev_comm=irq/57-wl18xx prev_pid=260 prev_prio=49 prev_state=D ==> next_comm=APL_MC next_pid=532 next_prio=120
APL_MC-532 [config_devicetree.tar.gz 000] d..2. 1295.989754: sched_switch: prev_comm=APL_MC prev_pid=532 prev_prio=120 prev_state=R+ ==> next_comm=ksoftirqd/0 next_pid=12 next_prio=48
------ case 2 ftrace end ---------------------------------

RE: AM3356: When the CPU governor is set to "ondemand," some IRQ threads occupy the CPU for a long period.

Bin Liu — Fri, 26 Jun 2026 20:41:56 GMT

Hi Katsuya-san,

This is an known issue on AM335x. Please check the following e2e threads.

soft lockup when use usb serial port on am335x.

AM3352: Kernel hangs with ondemand scaling governor

Here is the recommendation from AI response:

========

System lockups on an AM335x (such as a BeagleBone Black) when using the ondemand CPU frequency governor are typically caused by voltage/frequency (OPP) table mismatches, I/O DMA stalls during frequency changes, or insufficient transient power delivery (droop).

Key Causes of the Lockup

Voltage-Frequency (OPP) Mismatches: The ondemand governor frequently changes the core clock. If your device tree (DTS) or board configuration defines a core voltage that is too low for the newly requested, higher frequency, the CPU core will become unstable and instantly freeze.
Bus and I/O DMA Stalls: On the AM335x, CPU clock transitions can disrupt peripheral DMA transfers (especially over USB, Ethernet, or McASP). When the governor changes frequency, the interconnect bus briefly pauses, causing a bus-master lockup if an active DMA transaction expects continuous clock cycles.
Power Supply Transient Droop: When stepping up from low frequencies (e.g., 300 MHz) to maximum frequency (e.g., 1000 MHz), the processor requires a massive, instantaneous surge in current. If your PMIC (Power Management IC, like the TPS65217C) or the board's 5V input cannot handle this rapid inrush, the core voltage rail drops out (voltage droop), causing a hard lockup.

How to Diagnose and Fix the Issue

1. Switch to the performance or schedutil Governor
To test if dynamic frequency scaling is the root of the problem, disable ondemand and set a static frequency or a more advanced scaling governor.

2. Update your Device Tree (DTS) and Kernel
If you are using a custom carrier board or an older kernel, make sure your operating power point (OPP) tables accurately match the silicon-specific eFuse limits. Check the Texas Instruments Processor SDK Linux for power management and DVFS (Dynamic Voltage and Frequency Scaling) patches.

3. Check Hardware Reliability (Hardware Specific)
Ensure your AM335x is rated for 1GHz operation if your max scaling frequency is set to 1GHz. Overclocking an 800MHz-rated chip will often cause freezes when scaling up dynamically.

RE: AM3351: u-boot 2026.04 defconfig Build Issues

Bin Liu — Fri, 26 Jun 2026 19:12:07 GMT

Hi Bob,

Before the assigned engineer looking into your query, can you please clarify on what you are trying to do with both u-boot 2026.04 and 2017 sdk u-boot? I am a bit confused by your description. It seems you are trying to use the u-boot defconfig from 2017 to build 2026.04, is this correct?

Regardless the u-boot version, it already provides configs/am335x_evm_defconfig. You'd better to use it as the baseline but please do not take the defconfig file across u-boot versions.

Please also note, for latest u-boot, the TI officially supported version is 2026.01, not 2026.04 and any other 2026 versions.

AM3351: u-boot 2026.04 defconfig Build Issues

Bob Groves — Thu, 25 Jun 2026 23:19:35 GMT

Part Number: AM3351

Using the U-Boot 2026.04 release, I built a MLO file based on the am335x_evm_defconfig file.

Redoing the u-boot build using the 2017 Linux 4.9 product baseline ‘devel_am335x_defconfig’ file, the build fails with various ‘make’ pre-script check errors.

Reviewing the 2017 Linux 4.9 product baseline ‘devel_am335x_defconfig’ file, I also found missing ‘oMap’ configuration statements.

Need TI help in addressing the 2017 Linux 4.9 product baseline ‘devel_am335x_defconfig’ file u-boot build issues.

I see two paths forward to resolve the u-boot build issues:

Modify the U-Boot 2026.04 release am335x_evm_defconfig file --

Using u-boot menuconfig, modify the ‘am335’ configuration statements for our product hardware.

Modify the 2017 Linux 4.9 product baseline ‘devel_am335x_defconfig’ file --

Add the missing ‘oMap’ configuration statements.
Resolve the 2026.04 MLO build issues by updating the defconfig file.

TMS570LC4357: Generate complementary pwm outputs with dead band using N2HET

Veena Saluja — Fri, 26 Jun 2026 14:50:11 GMT

Part Number: TMS570LC4357

Hi,

Is there an example program, using N2HET for generating complementary pwm outputs with dead band for tms570lc4357?

MSPM0G3507: How to use MDIV of G3507

Ryuuichi machida — Thu, 18 Jun 2026 09:36:53 GMT

Part Number: MSPM0G3507

Hi,

I would like to set CPUCLK to 1MHz.
According to technical reference manual, when user want to set less than 4MHz, it seems that we can use MDIV.
So, I set MDIV following caution of technical reference manual, I can see less than 4MHz signal but I see something strenge point. So could you please confirm about below ?

Q1 : When I set 2MHz setting, I could see following signal (observe this signal by enabling CLK_OUT function.)

Actually, frequency is 2MHz but duty ratio is strange (For clock, in my understanding, duty ratio should be 1:1.)
Is it expected result ?

Q2 :
When I set 1MHz setting, I could NOT see 1MHz signal. (same signal as 2MHz pattern.)
Is it expected result ?

Best Regards,

RE: MSPM0G3507: How to use MDIV of G3507

Zoey Wei — Fri, 26 Jun 2026 13:39:27 GMT

Hi,

2M->1M would help to deduce more much power. Since they MDIV is still working.

The result is expected

RE: EK-TM4C123GXL: EK-TM4C123GXL cannot get to work on my laptop

Josel Go — Fri, 26 Jun 2026 13:38:51 GMT

Hi Erik,

Nope, I don't see it anywhere at all

I don't know what else to do, but I've tried so many troubleshooting steps and I cannot seem to get it to show up at all on my laptop. It's being incredibly stubborn, and I was really hoping to get to learn on the Tiva, but if it's not even connecting, I can't even get started with it.

Regards,

Josel

AM2632: Adding the QSPI module led to the entry of the HwiP_user_data_abort_handler_c function

Wang Mason — Fri, 26 Jun 2026 12:16:19 GMT

Part Number: AM2632

Hello,

In our multi-core demo project, when adding the QSPI function to the R5 1-0 core, we entered the HwiP_user_data_abort_handler_c function. What could be the reason for this?

Addendum: The development board is currently in SE mode. Only the following points need to be modified in the demo.

MSPM0G3519: MSPM0G3519 – J-Link Flash Erase Failure ("RAMCode did not respond in time"), but Programming Succeeds via XDS110 and Later Recovers

Dilip M — Wed, 24 Jun 2026 07:08:25 GMT

Part Number: MSPM0G3519

Hello TI Team,

I am working with a custom board based on the MSPM0G3519.

I encountered an issue where programming and erase operations failed when using a SEGGER J-Link debugger and J-Scope also failed (J-Flash/J-Scope).

But the same device could be programmed successfully using a TI XDS110 debugger through CCS using an external MSP0G3519 MCU. After programming once with XDS110, I was able to program the device again using J-Link/J-Flash without any issues.

I am trying to understand the root cause of this behavior.

Hardware Setup:

MCU: MSPM0G3519
Custom board
SWD interface
Vref = 3.25V to 3.3V (on SWD all the necessary signals required for flashing were correct)
Stable power supply (no observed voltage drop during flash operations)

Debuggers Used:

SEGGER J-Link (J-Flash / J-Scope)
TI XDS110 (CCS)

Observed J-Link Error:

Timeout while preparing target; RAMCode did not respond in time!
Failed to perform RAMCode-sided Prepare()
Failed to erase chip.

Recovery Observation:

Since J-Link could not erase/program the device, I connected the same board using a TI XDS110 debugger and programmed the application successfully through CCS.

After that:

J-Link J-Flash started working again
Programming and erase operations completed successfully
No hardware modifications were made
Power supply and SWD connections remained unchanged

Questions:

Is there any known MSPM0G3519 condition where the device can enter a state that prevents J-Link RAMCode execution but can be recovered by a CCS/XDS110 programming operation?
Does CCS/XDS110 perform any additional unlock, mass erase, recovery, or initialization sequence that differs from J-Link?
Is there a recommended method to diagnose the root cause if this issue occurs again?

Any guidance would be appreciated.

Thank you.

RE: MSPM0G3519: MSPM0G3519 – J-Link Flash Erase Failure ("RAMCode did not respond in time"), but Programming Succeeds via XDS110 and Later Recovers

Sal Ye — Fri, 26 Jun 2026 12:13:18 GMT

Hi Dilip,

I suggest you can update the J-Link and then take a try. We have fixed some issues in the latest J-link version.

B.R.

Sal

RE: MSPM0G5117: MSPM0G5117

Sal Ye — Fri, 26 Jun 2026 11:50:47 GMT

Hi Ale,

You can check the design flow guide for MSPM0 sereis:MSPM0 Design Flow Guide

And MSPM0G5117 can fully share the same schematic with G5187. The LP-MSPM0G5187 can be your reference also.

B.R.

Sal