Arm-based microcontrollers forum - Recent Threads

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

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

TMS570LS3137: Secure Bootloader

Marc Cifuentes — Fri, 19 Jun 2026 14:24:03 GMT

Part Number: TMS570LS3137

Hello,

We need to implement a secure boot which will be as our root of thrust using the TMS570LS3137. Then it will allows application software to be checked when download and run.

Do you have any knowledge or reference where to look about how we could implement reliably a such secure boot ? This microcontroller does not have specfic hardware for it.

Thank you !

Regards,

Marc

AM263P4-Q1: Writing to User OTP from Custom HSM (AM263Px)

Jidhin Angadithazha — Fri, 19 Jun 2026 11:38:41 GMT

Part Number: AM263P4-Q1

Hello,

I am currently working on integrating a custom HSM firmware on the AM263Px device in HS-SE mode, and I would like to write data to the User OTP section from my custom HSM application.

However, I have not been able to find sufficient or clear documentation covering it.

Most of the available documentation appears to focus primarily on TI-SDK.

If the write_prtoection is not enabled, is there any limit on the number of write cycle in OTP regions. because the OTP sections like SWREV can be incremented.

I would like to understand the behaviour .

Thanks ,

Jidhin

AM13E23019: Missing information regarding sector erase time

Solomiia Matiichuk — Fri, 19 Jun 2026 10:30:38 GMT

Part Number: AM13E23019

Hi, could you please provide information on flash memory characteristics for AM13E23019, especially we would like to know sector erase time (max value). Haven't been able to find this information in the datasheet.

BR,
Solomiia

MSPM0-SDK: PWM Signal Glitch when phase shifted

Yesol Lee — Fri, 19 Jun 2026 08:49:04 GMT

Part Number: MSPM0-SDK

Hi team,

I tested the phase shift in PWM, using TIMG(standard) to TIMA(shift), and I can see the glitch on phase shifted PWM signal.

Channel 5: Main_Cross trigger, TIMG (Standard)
Channel 6: Secondary_Cross trigger, TIMG (Phase shifted X)
Channel 7: Secondary_Cross trigger, TIMA (Phase shifted O)

On Channel 6 without phase shift, this signal is clear, but there's some glitchs on Channel 7 very randomly, which is shifted the phase.

But when I tested with TIMA to TIMA, it doesn't happen the glitch. (but there's only one TIMA in M0L1227, so I need to use TIMG for standard)

Do you know the reason why the glitch happend when I use the TIMG as standard, and do you have any idea to fix this issue?

Many thanks,

Yesol

MSPM33C321A: Ease of Porting Code Between the MSPM0 and MSPM33

Michael V — Fri, 19 Jun 2026 07:25:09 GMT

Part Number: MSPM33C321A
Other Parts Discussed in Thread: MSPM0G5117, SYSCONFIG,

Hello,

I received a question on software compatibility between the MSPM0G and MSPM33 from one of my clients, and would appreciate some insights into the similarities/differences, and ease of porting code between the two SDKs.

My client plans to use a dual-MCU architecture (MSPM33C321 as main + MSPM0G5117 as sub MCU) and would like to reuse as much code as possible between the two.

I have currently explained that much of the DriverLib appears to be shared/similar between the two, and that application code using the same peripherals may be reusable with minor adjustments.

However, I am only able to speak vaguely on the topic, so I would appreciate assistance with the following:

What are the main similarities and differences between the MSPM33 and MSPM0 SDKs?
How easy is it to port software between the two? What can be reused, what can't be reused?
1. Please also provide application notes or helpful documents if any exist.
Are there any current or planned features in SysConfig to support easier migration or cross-device configuration reuse between MSPM0 and MSPM33?
1. (similar to how switching between different MSPM0 devices is currently supported)

Code reusability/porting is a key factor for them in their part selection so I would appreciate any helpful information.

Best regards,

Michael

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.

LP-AM261: Required Software Modification by PHY change (DP83869->DP83826A)

Ted Huh — Thu, 18 Jun 2026 13:56:20 GMT

Part Number: LP-AM261
Other Parts Discussed in Thread: DP83869, SYSCONFIG

Hello ASM Team,

My customer built the custom board with same pinmap as LP-AM261.

but they changed PHYs from DP83869(enhanced mode) to DP83826A(basic mode).

with this change, Link down occurs and it cannot commnicate with TwinCAT PC.

I changed PHY setting from DP83869 to DP83826A in sysconfig. also cleared the check box for enhanced mode but still it does not work.

is there any modification required for firmware side also?

Regards,

Ted

MSPM0-SDK: Unable to connect target DAP Connection Error - MSPM0C1104(20 Pin) Controller

Nandini VK — Thu, 18 Jun 2026 12:48:42 GMT

Part Number: MSPM0-SDK
Other Parts Discussed in Thread: MSPM0C1104, UNIFLASH

Hi Team,

I am using the MSPM0C1104 microcontroller. While flashing the application, I encountered the error shown in the attached image.

I reviewed previous forum discussions related to the same issue and followed the suggested recovery procedure of holding the reset pin and performing a factory reset. However, I was unable to complete the factory reset successfully.

I also attempted to perform a factory reset using UniFlash, the GUI tool, and CCS IDE, but the issue persists and I am still unable to flash the program onto the device.

Could you please help me resolve this issue?

Thank you.

MSPM0G3507: BIM together with secondary BSL

Zq — Thu, 18 Jun 2026 11:13:36 GMT

Part Number: MSPM0G3507

Hi there,

I am currently integrating BIM and a secondary BSL, and I am facing an issue after combining all components.

Memory Layout

My memory allocation is shown below.

Software Flow

Perform DFU using the BIM demo to manage the boot process.
BIM starts correctly after power-up.
BIM successfully selects and launches the latest application image.
The application runs normally.
The application then invokes the secondary BSL.

Before integration, each component was tested independently and worked correctly:

BIM
Application image
Secondary BSL
BSL host communication

Problem

After integrating everything together:

MCUboot boots correctly.
The application starts correctly.
The application jumps to the secondary BSL.
However, communication with the BSL host no longer works.

To debug, I loaded the secondary BSL symbols into the debugger without a dedicated project. The debugger stops in:

Default_Handler
NMI_Handler

This suggests that an exception or interrupt was occurring after the jump to the secondary BSL.

Questions

What could cause the secondary BSL to enter Default_Handler or NMI_Handler after being invoked from the application?
Has anyone encountered similar issues when integrating MCUboot with a secondary BSL?

Any suggestions on what to check next would be appreciated.

Thanks.

AM625: SWS_Mcu_00134 implementation for AM62x MCAL

Supriya Chintalapudi — Thu, 18 Jun 2026 11:02:04 GMT

Part Number: AM625

Hello Team,

MCAL Package: MCAL_SitaraMPU_12.00.00.03

As per SWS_Mcu_00134, The MCU module shall provide at least the values MCU_POWER_ON_RESET and MCU_RESET_UNDEFINED for the enumeration Mcu_ResetType.

For AM62X MCAL Package, it is implemented as MCU_POWER_ON_RESET_MAIN_DOMAIN and MCU_POWER_ON_RESET_MCU_DOMAIN.

{code}

typedef enum
{
/* Requirements: SWS_Mcu_00134 */
MCU_POWER_ON_RESET_MAIN_DOMAIN = 0, /*!< POR Reset from Main domain */
MCU_POWER_ON_RESET_MCU_DOMAIN, /*!< POR Reset from Mcu domain*/
MCU_WATCHDOG_RESET, /*!< WatchDog reset */
MCU_DEBUG_RESET, /*!< Cold reset */
MCU_MAIN_WARM_RESET_MAIN_DOMAIN, /*!< SW Main Warm reset from Main domain */
MCU_MAIN_WARM_RESET_MCU_DOMAIN, /*!< SW Main Warm reset from Mcu domain*/
MCU_RESET_UNDEFINED, /*!< UNDEFINED reset */
MCU_RESET_CLEAR /*!< Reset Reason Cleared */
} Mcu_ResetType;

{code}

and missing value MCU_POWER_ON_RESET.

Could you please provide your feedback on this?

AM2434: AM243x Secure Boot (SBL OSPI) – 256KB Decryption Limit vs Total MSRAM

Martin Gschwendner — Thu, 18 Jun 2026 09:42:02 GMT

Part Number: AM2434

Hello,

while working with Secure Boot on the AM243x-LP, I came across the following limitation described in the TI documentation:

https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/latest/exports/docs/api_guide_am243x/SECURE_BOOT.html

In the section related to SBL OSPI secure boot, it is mentioned that:

Decryption of application images larger than 256 KB is not possible due to the limitation that only 256 KB of MSRAM is available for temporary storage during decryption. This is because the image must be copied from flash to RAM before decryption, as flash is not directly writable.

My Questions

The AM243x device provides ~2 MB of internal MSRAM in total.

Is the 256 KB limitation strictly related to the default SBL memory layout?
- Would it be possible to increase the temporary decryption buffer by adjusting the memory usage (e.g., MSRAM minus SBL reserved memory)?
Or is this limitation fundamentally imposed by the HSM/SBL implementation, making it non-configurable?
Does this 256 KB limitation apply only to SBL-related image handling, or does it also affect firmware / application images in general during secure boot?

Context

I am working with multicore application images, which can easily exceed 256 KB. I would like to understand whether this is:

a strict architectural limitation, or
a software/configuration constraint that can be worked around

This would help decide on strategies such as image partitioning or SBL modification.

Thanks in advance for your clarification!

Best regards,
Martin

MSPM0G3218-Q1: Missing Bit description in IOMUX Register PINCM

Caspar Bean — Thu, 18 Jun 2026 09:41:39 GMT

Part Number: MSPM0G3218-Q1

Hello TI Team,

I noticed that Bits 22 and 23 in PINCM register are missing out on definition in the Reference Manual, I have the newest Version of the TRM but can't find any info about these bits. I am therefore not sure which consequences a write or read to these bits can have.

AM263P4-Q1: AM263 hardware resolver to digital converter RDC questions

WhiteNoise — Thu, 18 Jun 2026 09:40:40 GMT

Part Number: AM263P4-Q1

1) The AM263 Technical Reference Manual states the hardware RDC has open and short detection. I see two hardware options for interfacing a resolver to the AM263, one involving op-amps and one involving a resistor divider network.
Will the open/short detection work in both these cases ? If the detection is really short and open detection I can't see how a front end with op-amps won't interfere with this.
Does the choice of front end type then impact the safety case that has been used to provide the stated ASIL ratings ?

Links stating an op-amp front end is useable:
https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1553276/am263p2-q1-signal-conditioning-required-or-not-for-resolver
https://www.ti.com/lit/ug/tidudp0/tidudp0.pdf
https://software-dl.ti.com/mcu-plus-sdk/esd/AM263PX/latest/exports/docs/api_guide_am263px/EXAMPLES_DRIVERS_RESOLVER_DIAGNOSITCS.html

Links stating a Resistor Divider Network is useable:
https://software-dl.ti.com/mcu-plus-sdk/esd/AM263PX/latest/exports/docs/api_guide_am263px/EXAMPLES_DRIVERS_RESOLVER_DIAGNOSITCS.html

2) Can you share access to FMEDA documentation covering the resolver, including its failure modes. In addition, it would be useful to understand which failure modes
are addressed by each diagnostic described in the microcontroller safety manual. Is this covered in the "AM263PX-RESTRICTED-SAFETY — AM263Px restricted functional safety content"?
I am currently awaiting download approval for this.

Thank you.

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,

MSPM33C321A: M33C321A flash operation checked by interrupt

Xiaodong LI — Thu, 18 Jun 2026 07:48:51 GMT

Part Number: MSPM33C321A

We need add the M33C321A flash operation checked by interrupt example code

Thanks

AM2612: xip file programming question

Kita Li — Thu, 18 Jun 2026 05:50:21 GMT

Part Number: AM2612
Other Parts Discussed in Thread: UNIFLASH

Hi experts,

I am asking for customer.

The XIP file generated after compilation should contain both actual data and packaging information. Is it possible to write only the actual data without the packaging information? Because the mcelf_xip write interface first caches the delivered data in RAM and then writes it all at once, which requires a very large RAM space.

Best Regards

Kita

PMP41114: Need Digital Control SW and HW Support

Murlidhar Mandal — Thu, 18 Jun 2026 03:54:32 GMT

Part Number: PMP41114
Other Parts Discussed in Thread: PMP23338

Hi,

Need Confirmation of the Design PMP41114, did we have the Evalauation baord readlly available for check and How SW is deady for the experiment purpose.

BR/

Murli

MSPM0G3529-Q1: M0G3519QPMRQ1 vs M0G3529QPMRQ1

Austin Trudeau — Thu, 18 Jun 2026 03:25:46 GMT

Part Number: MSPM0G3529-Q1
Other Parts Discussed in Thread: SYSCONFIG, MSPM0G3519

Hello,

I'm evaluating the M0G3529QPMRQ1 (MSPM0G352x-Q1) as an alternate to the M0G3519QPMRQ1 (MSPM0G351x-Q1), both in the 64-pin PM (LQFP) package, for an automotive project. The two datasheets look feature-identical in the PM package, and I expect the SysConfig-generated files (ti_msp_dl_config.c/.h) to be the same for a given configuration. Could you please confirm:

1. Are these the same die at the register/peripheral level, such that firmware is bit-compatible in the PM package?
2. Would SysConfig generate identical config files for both?

One thing I can't reconcile: the MSPM0G352x-Q1 functional block diagram has a footnote stating "CAN-FD available in MSPM0G351x devices only," yet the 3529 feature list specifies two CAN-FD interfaces. Does the 3529 fully support CAN-FD? It's required for my design.

Finally, I can't find the MSPM0G3529 in the SysConfig device migration list. Which SDK/SysConfig version adds MSPM0G352x support?

Thanks!

AM263P4-Q1: Questions about MSRAM allocation in AM263Px SBL (OSPI) linker.cmd

Imaoka Daisaku — Wed, 17 Jun 2026 23:18:11 GMT

Part Number: AM263P4-Q1

AM263Px MCU+SDK (mcu_plus_sdk_am263px_10_01_00_31) SBL (OSPI): Question about linker.cmd memory map intent

I would like to confirm the intent of the memory map in the linker script for the AM263Px MCU+SDK SBL (OSPI). I am referencing the following file:
...\examples\drivers\boot\sbl_ospi\am263px-lp\r5fss0-0_nortos\ti-arm-clang\generated\linker.cmd

Q1: MSRAM_VECS start address 0x70002000
In the linker script, MSRAM_VECS starts at 0x70002000.
Can the address range 0x70000000–0x70001FFF (the first 8KB) be used by the SBL?
If this region is reserved, what is it used for?

Q2: Reducing MSRAM_HSMRT size
From my side, it looks like MSRAM_HSMRT actual usage is only about ~26KB.
Is it safe to reduce the allocated size of MSRAM_HSMRT? If there is a minimum required size or any constraint, could you please advise?

Requested response date: June 19, 2026

LP-EM-CC2340R5: LP-EM-CC2340R5

Atilano Valadez — Wed, 17 Jun 2026 22:07:00 GMT

Part Number: LP-EM-CC2340R5
Other Parts Discussed in Thread: LP-XDS110, CC2340R5

Besides

LP-EM-CC2340R5

Will we need extra Hardware to connect the LP-EM-CC2340R5 to my USB PC?

If yes, please let me know what else will be needed

Thanks

TMS570LC4357: TMS570LC43457 multi Buffer SPI RX not triggering RXDMA

Fabian Hof — Wed, 17 Jun 2026 19:47:20 GMT

Part Number: TMS570LC4357

Hi,

I am trying to get RXDMAENA (DMACTRL[0] bit 15) to generate an automatic
hardware-triggered DMA request when MibSPI1 receives data, so the
TMS570 DMA controller copies received data from MibSPI1 RXRAM into
application RAM (s_rx_buf) without CPU intervention.

From testing I confirmed that a software DMA trigger will trasnfer the data from RXRAM to the desired buffer, but I can't seem to figure out how to wire mibSPI->DMACTRL to trigger an RX DMA transfer when I received N bytes in RXRAM via the SPI.

I attached my test code with detailed comments and things i tried, and hope someone can point me in the right direction.

Once this is working, the goal is to also use the TXRAM + DMA to pipe data out of the SPI while using the DMA to receive data.

I appreciate any help.

mibspi_dma_testing.c

AM62P: AM62P DDR test: DDR Basic read/write test Failed

Dániel Zoltán Nagy — Wed, 17 Jun 2026 16:48:38 GMT

Part Number: AM62P

Hi,

I am trying to run DDR tests on the SK-AM62P-LP EVM board.

I have successfully done the steps described in this post: AM62P: AM62P DDR tests: Error -1170 @ 0x0 Unable to access the DAP. - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

I am able to connect to the board with the XDS110 Debug probe using JTAG, and I can see the DDR test scripts.

I can successfully run Scripts -> AM62 DDR Initialization -> AM62P_DDR_Initialization_ECC_Disabled.

However, when I try to run Scripts > AM62P DDRSS Memory Debug > Data Tests > Data_WrRd_test, I get:

!!!!! DDR Basic read/write test Failed !!!!

I am using a fresh install of CCS 20.5.1, I have not modified any DDR timing/config parameters, and I am using the out-of-box files provided with CCS.

Here is the full GEL Output:

WKUP_R5FSS0: ***WARNING: Please close all Memory Browser Windows before attempting to initialize DDR with GELs
WKUP_R5FSS0: Running from R5
WKUP_R5FSS0:

DDR not initialized with R5 connect.

Go to menu Scripts --> AM62 DDR Initialization -> AM62P_DDR_Initialization_ECC_Disabled to initialize DDR.

====

WKUP_R5FSS0: --->>> ECC Disabled! <<<---
WKUP_R5FSS0: --->>> LPDDR4 Initialization is in progress ... <<<---
WKUP_R5FSS0: --->>> DDR controller programming in progress.. <<<---
WKUP_R5FSS0: --->>> DDR controller programming completed... <<<---
WKUP_R5FSS0: --->>> DDR PI programming in progress.. <<<---
WKUP_R5FSS0: --->>> DDR PI programming completed... <<<---
WKUP_R5FSS0: --->>> Set PHY registers for all FSPs simultaneously (multicast)... <<<---
WKUP_R5FSS0: --->>> DDR PHY Data Slice 0 programming in progress.. <<<---
WKUP_R5FSS0: --->>> DDR PHY Data Slice 0 programming completed... <<<---
WKUP_R5FSS0: --->>> DDR PHY Data Slice 1 programming in progress.. <<<---
WKUP_R5FSS0: --->>> DDR PHY Data Slice 1 programming completed... <<<---
WKUP_R5FSS0: --->>> DDR PHY Data Slice 2 programming in progress.. <<<---
WKUP_R5FSS0: --->>> DDR PHY Data Slice 2 programming completed... <<<---
WKUP_R5FSS0: --->>> DDR PHY Data Slice 3 programming in progress.. <<<---
WKUP_R5FSS0: --->>> DDR PHY Data Slice 3 programming completed... <<<---
WKUP_R5FSS0: --->>> DDR PHY Address Slice 0 programming in progress.. <<<---
WKUP_R5FSS0: --->>> DDR PHY Address Slice 0 programming completed... <<<---
WKUP_R5FSS0: --->>> DDR PHY Address Slice 1 programming in progress.. <<<---
WKUP_R5FSS0: --->>> DDR PHY Address Slice 1 programming completed... <<<---
WKUP_R5FSS0: --->>> DDR PHY Address slice 2 programming in progress.. <<<---
WKUP_R5FSS0: --->>> DDR PHY Address Slice 2 programming completed... <<<---
WKUP_R5FSS0: --->>> DDR PHY programming in progress.. <<<---
WKUP_R5FSS0: --->>> DDR PHY programming completed... <<<---
WKUP_R5FSS0: Running from R5 or A53
WKUP_R5FSS0: Setting MAIN_PLL12_HSDIV0_CLKOUT_25MHz
WKUP_R5FSS0: Setting PLL in integer mode
WKUP_R5FSS0: Waiting for Calibration Lock...
WKUP_R5FSS0: Cal locked
WKUP_R5FSS0: Waiting for PLL Lock...
WKUP_R5FSS0: PLL is locked.
WKUP_R5FSS0: MAIN_PLL12_HSDIV0_CLKOUT set.
WKUP_R5FSS0: --->>> Set DDR to 25MHz for FSP F0... <<<---
WKUP_R5FSS0: --->>> DDR PI initialization started... <<<---
WKUP_R5FSS0: --->>> DDR CTL initialization started... <<<---
WKUP_R5FSS0: --->>> Inside DDR_Change_freq_ack function ... <<<---
WKUP_R5FSS0: --->>> Waiting for first frequency change request ... <<<---
WKUP_R5FSS0: Waiting for clock change request...
WKUP_R5FSS0: Iter 1: Frequency change request type 2 received from controller
WKUP_R5FSS0: Running from R5 or A53
WKUP_R5FSS0: Setting MAIN_PLL12_HSDIV0_CLKOUT_800MHz
WKUP_R5FSS0: Setting PLL in integer mode
WKUP_R5FSS0: Waiting for Calibration Lock...
WKUP_R5FSS0: Cal locked
WKUP_R5FSS0: Waiting for PLL Lock...
WKUP_R5FSS0: PLL is locked.
WKUP_R5FSS0: MAIN_PLL12_HSDIV0_CLKOUT set.
WKUP_R5FSS0: Setting the FSP ack bit...
WKUP_R5FSS0: Waiting for the request to go away...
WKUP_R5FSS0: Clearing the ack bit...
WKUP_R5FSS0: Waiting for clock change request...
WKUP_R5FSS0: Iter 2: Frequency change request type 0 received from controller
WKUP_R5FSS0: Running from R5 or A53
WKUP_R5FSS0: Setting MAIN_PLL12_HSDIV0_CLKOUT_25MHz
WKUP_R5FSS0: Setting PLL in integer mode
WKUP_R5FSS0: Waiting for Calibration Lock...
WKUP_R5FSS0: Cal locked
WKUP_R5FSS0: Waiting for PLL Lock...
WKUP_R5FSS0: PLL is locked.
WKUP_R5FSS0: MAIN_PLL12_HSDIV0_CLKOUT set.
WKUP_R5FSS0: Setting the FSP ack bit...
WKUP_R5FSS0: Waiting for the request to go away...
WKUP_R5FSS0: Clearing the ack bit...
WKUP_R5FSS0: Waiting for clock change request...
WKUP_R5FSS0: Iter 3: Frequency change request type 2 received from controller
WKUP_R5FSS0: Running from R5 or A53
WKUP_R5FSS0: Setting MAIN_PLL12_HSDIV0_CLKOUT_800MHz
WKUP_R5FSS0: Setting PLL in integer mode
WKUP_R5FSS0: Waiting for Calibration Lock...
WKUP_R5FSS0: Cal locked
WKUP_R5FSS0: Waiting for PLL Lock...
WKUP_R5FSS0: PLL is locked.
WKUP_R5FSS0: MAIN_PLL12_HSDIV0_CLKOUT set.
WKUP_R5FSS0: Setting the FSP ack bit...
WKUP_R5FSS0: Waiting for the request to go away...
WKUP_R5FSS0: Clearing the ack bit...
WKUP_R5FSS0: Waiting for clock change request...
WKUP_R5FSS0: Iter 4: Frequency change request type 0 received from controller
WKUP_R5FSS0: Running from R5 or A53
WKUP_R5FSS0: Setting MAIN_PLL12_HSDIV0_CLKOUT_25MHz
WKUP_R5FSS0: Setting PLL in integer mode
WKUP_R5FSS0: Waiting for Calibration Lock...
WKUP_R5FSS0: Cal locked
WKUP_R5FSS0: Waiting for PLL Lock...
WKUP_R5FSS0: PLL is locked.
WKUP_R5FSS0: MAIN_PLL12_HSDIV0_CLKOUT set.
WKUP_R5FSS0: Setting the FSP ack bit...
WKUP_R5FSS0: Waiting for the request to go away...
WKUP_R5FSS0: Clearing the ack bit...
WKUP_R5FSS0: Waiting for clock change request...
WKUP_R5FSS0: Iter 5: Frequency change request type 2 received from controller
WKUP_R5FSS0: Running from R5 or A53
WKUP_R5FSS0: Setting MAIN_PLL12_HSDIV0_CLKOUT_800MHz
WKUP_R5FSS0: Setting PLL in integer mode
WKUP_R5FSS0: Waiting for Calibration Lock...
WKUP_R5FSS0: Cal locked
WKUP_R5FSS0: Waiting for PLL Lock...
WKUP_R5FSS0: PLL is locked.
WKUP_R5FSS0: MAIN_PLL12_HSDIV0_CLKOUT set.
WKUP_R5FSS0: Setting the FSP ack bit...
WKUP_R5FSS0: Waiting for the request to go away...
WKUP_R5FSS0: Clearing the ack bit...
WKUP_R5FSS0: --->>> Frequency Change request handshake is completed... <<<---
WKUP_R5FSS0: pi_int_status = 0x27C02001...
WKUP_R5FSS0: - PI_INIT_DONE_BIT set: The power-on initialization training in PI has been completed.
WKUP_R5FSS0: - PI_LVL_DONE_BIT set: The leveling operation has completed.
WKUP_R5FSS0: - PI_RDLVL_GATE_DONE_BIT set: A read leveling gate training operation has been completed.
WKUP_R5FSS0: - PI_RDLVL_DONE_BIT set: A read leveling operation has been completed.
WKUP_R5FSS0: - PI_WRLVL_DONE_BIT set: A write leveling operation has been completed.
WKUP_R5FSS0: - PI_CALVL_DONE_BIT set: A CA training operation has been completed.
WKUP_R5FSS0: - PI_WDQLVL_DONE_BIT set: A write DQ training operation has been completed.
WKUP_R5FSS0: - Not documented bit set.
WKUP_R5FSS0: ctl_int_status = 0x80002400...
WKUP_R5FSS0: --->>> DDR Initialization completed... <<<---
WKUP_R5FSS0: --->>> LPDDR4 Initialization is DONE! <<<---
WKUP_R5FSS0: Starting WrRd Test 1: *wr32_ptr=i
WKUP_R5FSS0: Data verification failed at 0x80000000 Expected = 0x00000000 Actual= 0x00000000
WKUP_R5FSS0: Data verification failed at 0x80000004 Expected = 0x01010101 Actual= 0x00000000
WKUP_R5FSS0: Starting WrRd Test 2: *wr32_ptr=~i
WKUP_R5FSS0: Data verification failed at 0x80000000 Expected = 0x030100FF Actual= 0x40007300
WKUP_R5FSS0: Data verification failed at 0x80000004 Expected = 0x0100FFFE Actual= 0x41004100
WKUP_R5FSS0:
!!!!! DDR Basic read/write test Failed !!!!

Given that DDR initialization completes successfully and all training steps report done, I was expecting the basic read/write test to pass without needing any modifications.

Has anyone seen this behavior on the SK-AM62P-LP EVM with the default GEL configuration?

Could I be missing a required step?

AM2434: Addition of IEEE Std 802.1ASdm™︎‐2024

Florian Ertl — Wed, 17 Jun 2026 15:37:05 GMT

Part Number: AM2434

Hello,

do you know when Amendment 3 of IEEE Std 802.1AS — Hot Standby and Clock Drift Error Reduction (IEEE Std 802.1ASdm-2024) — will be added to the TSN code base?

In particular, the drift tracking functionality (especially rateRatioDrift) would be very interesting for our use case.

Best regards,

Florian Ertl

AM3352: BSDL file AM3352BZCED60

Ivan Fil — Wed, 17 Jun 2026 12:34:09 GMT

Part Number: AM3352

Hello support team,

could you please provide us with bsdl file for AM3352BZCED60, in order to conduct the boundary scan test with the MCU.

Or we could we download it?

Could we find information in the bsdl file about conditions, how to activate the boundary scan?

Regards