Arm-based microcontrollers forum - Recent Threads

AM2634-Q1: dual mac mode ethernet with same IP address

Varma SVRP — Wed, 06 May 2026 06:12:51 GMT

Part Number: AM2634-Q1

Hi,

I have a project specific requirement.

Both ports of the ethernet would be assigned same IP address and same subnet mask but in different networks. The use case states that both should acquire IP address using DHCP. Only one port is always communicating. On status/link failure or down for any reason, the second port is to be used. The 2nd port is expected to resume immediately. When the 1st port is up again, it shall resume the communications.

I was not be handle this in switch mode, for two reasons. First reason was communication was active on both ports at the same time. Second, when port 1 cable was disconnected, the entire communication stopped.

My question is how do we handle making 2nd port inactive until the 1st port is up again? Is this possible in either Switch mode or MAC only mode?

Regards

Varma

RE: AM2634-Q1: dual mac mode ethernet with same IP address

Shaunak Deshpande — Mon, 11 May 2026 13:03:51 GMT

Hi Varma,

To avoid ARP ambiguity, routing issues, duplicate IP advertisements, you will have to modify the code to:

1. Make sure only 1 NetIF gets initialized at the startup, even if both ports are available. So check if Port-1 link is good, then activate the netif, if not activate port-2 netif. Even if not being used together, i would say avoid having both NetIFs active and assigned with the same IP address. So only bring-up one netif at startup.

So netif_add(), netif_set_default(), netif_set_up() etc should be called only for 1 NetIF during init, and for other NetIF during the Link-Down event of primary NetIF.

2. During your Link down event, in the callback function check which netif went down, and then bringup the other netif, This will involve getting the IP address again from the DHCP server (unless static hardcoded IP is used)

You can follow the exact same flow that the SDK example shows, but make sure you only handle one NetIF at once, since you want to share the same IP address.

Regards,
Shaunak

RE: AM625: AM625: USB TEST MODE

Borislav Lazarkov — Mon, 11 May 2026 13:02:42 GMT

Hello Ryan,

Give me some time to connect to the USB expert and to review your thread.

Thank you for your patience!

Best Regards,

Borislav Lazarkov

AM625: AM625: USB TEST MODE

z ryan — Mon, 11 May 2026 03:09:11 GMT

Part Number: AM625

I need to perform USB waveform testing and output standard USB test signaling patterns.
The required test patterns include:
Test_SE0_NAK, Test_J, Test_K, Test_Packet, Test_Force_Enable.
According to the datasheet, I should configure the register:
VBP2AHB_CONTROLLER_VBP_USB3_CORE_DEV_DCTL.
However, configuring this register does not work. I have confirmed the values are correctly written into the register, as the readback values match exactly:
Write 0x3110c704 → Readback 0x00F00004
Write 0x3110c704 → Readback 0x00F00006
Write 0x3110c704 → Readback 0x00F0000A
I found a recommended register configuration from technical forums as below:
0x31100420 → 0xA0
0x31100020 → 0x4
0x31100424 → 0x40000000
This configuration can indeed output the USB test waveform, but it only works for RWE Port Test.
I need to separately configure and generate the standard USB test signaling patterns:
Test_SE0_NAK, Test_J, Test_K, Test_Packet, Test_Force_Enable.
Please advise what prerequisite dependencies this dedicated pattern configuration requires, and provide the official/standard configuration procedure.

AM13E23019: AM13E23019, how to allocate ISR in SRAM?

Ari Mendes — Fri, 08 May 2026 19:24:23 GMT

Part Number: AM13E23019

Hi,

The AM13E23019 SDK has an example project, "1sh_sl_foc_drv8329a", which demonstrates allocating a function in SRAM. This function is called from an ISR, but the ISR is allocated in flash memory. In the applications I create with the STM32G4, which also has an area of SRAM for executing code (CCM-SRAM), there's a procedure to allocate interrupt vectors in SRAM (AN4296 document, link below). This is done in the routine "startup_stm32g474xx.a", where after the RESET, the interrupt vectors are copied from flash memory to the SRAM area called CCMRAM. The advantage is that when an interrupt occurs, all the code runs in SRAM without needing to call a function allocated in SRAM, thus increasing performance.

How could I do something equivalent for the AM13E23019?

https://www.st.com/resource/en/application_note/an4296-use-stm32f3stm32g4-ccm-sram-with-iar-embedded-workbench-keil-mdkarm-stmicroelectronics-stm32cubeide-and-other-gnubased-toolchains-stmicroelectronics.pdf

Ari

RE: AM13E23019: AM13E23019, how to allocate ISR in SRAM?

Ari Mendes — Mon, 11 May 2026 12:59:59 GMT

Veena Kamath,

Using the RAMFUNC macro or "__attribute__((section(".TI.ramfunc")))", as explained in the linker.cmd file, for normal functions I had already tested and knew it worked, I was in doubt if it would work directly for an interrupt routine, because in the case of an STM32 project using gcc, it is necessary to copy the interrupt vectors to SRAM and inform the address of this vector in NVIC.

But to my surprise, when using "_attribute__((section(".TI.ramfunc")))" in the interrupt routine, it allocates the routine from SRAM and it is called correctly when the interrupt occurs, somehow the TI compiler, in addition to copying the routine to SRAM, modifies the interrupt vector in NVIC.
I just found it strange that in the example "1sh_sl_foc_drv8329a" it didn't use MOTOR_CTRL_RAMFUNC ADC0_INT1_IRQHandler(void) to allocate the interrupt directly in SRAM, and instead only allocated in SRAM the functions that are called by the ISR.

Ari

TMS570LS3137: SafeTi Library : SL_SelfTest_CCMR4F(CCMR4F_ERROR_FORCING_TEST, TRUE, &failInfoCCMR4FTest)

Marc Cifuentes — Mon, 11 May 2026 12:53:32 GMT

Part Number: TMS570LS3137

Hello,

Based on Ti demo project example and our analysis, after STC controller test and CPU self tests which are performed and triggers two CPU reset type (RESET_TYPE_CPU), we run below tests :

Here, we see a difference in terms of results regarding CCMR4F_ERROR_FORCING_TEST :

From a system Power ON (reset reason : RESET_TYPE_POWERON), the test PASS correctly.

But from a sequence with a software reset (RESET_TYPE_SWRST), for example after reprogramming our application with CAN services, at start up the test FAIL if we do not perform one system Power ON. Then any software reset will work afterwards.

The problematic effect is that we need to explicitly turn off/on the board after each time we program again.

Do you know why there is such effect with this test and if it is fine to perform this test only on system power ON (do not run it again after programming of new application and software reset for example)?

Thank you !

Regards,

Marc

TDA4VEN-Q1: TDA4VEN C7X Clock Startup Initialization Fault

Qiang Leo — Sat, 09 May 2026 10:12:48 GMT

Part Number: TDA4VEN-Q1

Hi,

During the development of C7x on TDA4VEN, we encountered an intermittent issue where the C7x core fails to start. After troubleshooting, we found that the program gets stuck at SOC_controlModuleUnlockMMR(SOC_DOMAIN_ID_MAIN, 2) within the Dpl_init() function when the startup fails. We would like to know the root cause and the corresponding solution.

RE: TDA4VEN-Q1: TDA4VEN C7X Clock Startup Initialization Fault

Shabary S Sundar — Mon, 11 May 2026 12:23:50 GMT

Hi Qiang Leo,

Could you please confirm which Processor SDK RTOS version and MCU+ SDK version you are currently using, and whether you have made any modifications to the SDK?

Regards,
Shabary S Sundar

AM263PX-MCAL-SDK: AM263PX-MCAL-SDK

Laszlo Kovacs — Sun, 10 May 2026 21:32:36 GMT

Part Number: AM263PX-MCAL-SDK

It’s been almost three weeks since I requested the AM263PX-MCAL-SDK download, but the request is still pending. What do I need to do to get access?

RE: AM263PX-MCAL-SDK: AM263PX-MCAL-SDK

Nikhil Dasan — Mon, 11 May 2026 11:20:29 GMT

Hi Laszlo,

The MCAL SDK is bound under NDA. May I know if your organization has NDA with TI and if yes, please let me know the registered name under NDA?

Note: For faster approvals, please contact your local TI support (field or sales team).

Thanks and Regards,

Nikhil Dasan

RE: AM13E23019: AM13E23019, how to allocate ISR in SRAM?

Veena Kamath — Mon, 11 May 2026 10:25:14 GMT

Hi Ari,

You can use the macro RAMFUNC similar to how it is done for some of the Flash driver functions

Eg: RAMFUNC void DL_FRI_setZeroReadWaitStates(void)

This places the function in a separate section which is loaded to Flash, and copied to RAM.

Regards,

Veena

RE: AM6421: Programming custom board with am6421bsefhaalvr, using only R5F core

s s — Mon, 11 May 2026 10:15:46 GMT

Hi !
The UART uniflash command flow is working now after removing the MMCSD/eMMC instance from example.syscfg.

However, when trying to connect using Uniflash GUI with XDS200 configured, we are getting the below error:

Run failed...
File Loader: Memory write failed: Timed out waiting for target to halt while executing am243x_alv_flasher.out

Also, when we connect to the UART terminal and press reset, we are continuously receiving "CCCC" instead of booting sbl_null.

Could you please suggest what could cause this issue in Uniflash GUI mode?

AM6421: Programming custom board with am6421bsefhaalvr, using only R5F core

Sarita Jangid — Wed, 06 May 2026 13:23:02 GMT

Part Number: AM6421

Request you for setting up a quick call. Please find the problem statement below.

Need your kind support on the first time programming issue.

We are using am6421 series processor. We have bootmode configurations as OSPI and also UART fall back boot mode. DDR is not populated using only R5F.

SW2 (0→7) : 1 1 0 0 1 1 1 0

SW3 (8→15): 0 1 1 1 0 0 0 0

We tried to use uart_uniflash.py. but we are getting stuck in second stage . cfg file used is default_sbl_null.cfg.

for your reference

C:\ti\mcu_plus_sdk_am64x_11_02_00_24\tools\boot>python uart_uniflash.py -p COM3 --cfg=sbl_prebuilt/am64x-evm/default_sbl_null.cfg

Parsing config file ...
Parsing config file ... SUCCESS. Found 2 command(s) !!!

Executing command 1 of 2 ...
Found flash writer ... sending sbl_prebuilt/am64x-evm/sbl_ospi.release.hs_fs.tiimage

Sent flashwriter sbl_prebuilt/am64x-evm/sbl_ospi.release.hs_fs.tiimage of size 325021 bytes in 29.77s.

Executing command 2 of 2 ...
Command arguments : --file=sbl_prebuilt/am64x-evm/sbl_null.release.hs_fs.tiimage --operation=flash --flash-offset=0x0
Sending sbl_prebuilt/am64x-evm/sbl_null.release.hs_fs.tiimage: 0%| | 0/296061 [00:00<?, ?

Kindly guide us on this. Thank you for your support

MSPM0C1104: M0C1104 have problem after flash_bsl.out

Jerry Kuo — Mon, 11 May 2026 10:00:49 GMT

Part Number: MSPM0C1104

Hi team,

My customer is developing M0C1104 and they find problem as below.

Duplicate steps:
1.Compiled the “flash_bsl” demo project and generated the flash_bsl.out file.
c:\ti\mspm0_sdk_2_10_00_04\examples\nortos\LP_MSPM0C1104\bsl\flash_bsl with below modification.

diff --git a/.settings/org.eclipse.core.resources.prefs b/.settings/org.eclipse.core.resources.prefs    
index 99f26c0..81a6803 100644
--- a/.settings/org.eclipse.core.resources.prefs
+++ b/.settings/org.eclipse.core.resources.prefs
@@ -1,2 +1,6 @@
 eclipse.preferences.version=1
+encoding//Debug/makefile=UTF-8
+encoding//Debug/sources.mk=UTF-8
+encoding//Debug/subdir_rules.mk=UTF-8
+encoding//Debug/subdir_vars.mk=UTF-8
 encoding/<project>=UTF-8
diff --git a/boot_config.h b/boot_config.h
index bff7dd4..3ae99b2 100644
--- a/boot_config.h
+++ b/boot_config.h
@@ -67,9 +67,10 @@
 #define DEF_I2C_SDA_MUX                                     ((uint8_t) 3)
:...skipping...
diff --git a/.settings/org.eclipse.core.resources.prefs b/.settings/org.eclipse.core.resources.prefs    
index 99f26c0..81a6803 100644
--- a/.settings/org.eclipse.core.resources.prefs
+++ b/.settings/org.eclipse.core.resources.prefs
@@ -1,2 +1,6 @@
 eclipse.preferences.version=1
+encoding//Debug/makefile=UTF-8
+encoding//Debug/sources.mk=UTF-8
+encoding//Debug/subdir_rules.mk=UTF-8
+encoding//Debug/subdir_vars.mk=UTF-8
 encoding/<project>=UTF-8
diff --git a/boot_config.h b/boot_config.h
index bff7dd4..3ae99b2 100644
--- a/boot_config.h
+++ b/boot_config.h
@@ -67,9 +67,10 @@
 #define DEF_I2C_SDA_MUX                                     ((uint8_t) 3)
 #define DEF_I2C_SCL_PAD                                     ((uint8_t) 11)
 #define DEF_I2C_SCL_MUX                                     ((uint8_t) 4)
-#define BSL_CFG_I2C_SLAVE_ADDRESS                           ((uint8_t) 0x48)
+#define BSL_CFG_I2C_SLAVE_ADDRESS                           ((uint8_t) 0x61)
 
 /* INVOCATION PIN Config */
+// btn
 #define DEFAULT_BSL_PIN_INVOCATION_DATA0                    ((uint8_t) 0x93)
 #define DEFAULT_BSL_PIN_INVOCATION_DATA1                    ((uint8_t) 0x12)
 
diff --git a/flashBSL_modules.h b/flashBSL_modules.h
index ea07489..b438d5b 100644
--- a/flashBSL_modules.h
+++ b/flashBSL_modules.h
@@ -44,8 +44,8 @@
  * Interfaces available for BSL Communication
  * Can select only one Interface
  * */
-#define UART_INTERFACE ENABLE
-#define I2C_INTERFACE DISABLE
+#define UART_INTERFACE DISABLE
+#define I2C_INTERFACE ENABLE
 
 /*
  * Select invocation mechanisms for Flash BSL
(END)

2.using CCR20.5.0 to flash flash_bsl.out to the device

3.encountered the following error:“Flash Programmer Error: Attempting NONMAIN write without erasing.”

4.To recover, I re-flashed a full application image via UniFlash using the configuration shown in the attached screenshot.

5.The loading process appeared to complete successfully with no errors reported.
But M0C1104 cannot detect any I2C devices. It seems M0C1104 cannot work normally.

6.However, since that operation, the device no longer accepts any new firmware uploads — every subsequent attempt fails instantly with the error below:

Is there a way to recover the device? Any guidance would be greatly appreciated!

RE: AM6421: Programming custom board with am6421bsefhaalvr, using only R5F core

Meet Thakar — Mon, 11 May 2026 09:38:56 GMT

Then you need to remove MMCSD instance from your SBL UART UNIFLASH application's example.syscfg, please refer to the 4th point in this FAQ: [FAQ] AM6XX:How to Port SBL UART UNIFLASH for a custom board

RE: AM6421: Programming custom board with am6421bsefhaalvr, using only R5F core

s s — Mon, 11 May 2026 09:35:50 GMT

No, we are only using R50 Core and OSPI boot mode supporting Uart fallback. DDR and eMMC are not populated/not used.

Boot mode:-

SW3 (0→7) : 1 1 0 0 1 1 1 0

SW2 (8→15): 0 1 1 1 0 0 0 0

RE: AM6421: Programming custom board with am6421bsefhaalvr, using only R5F core

Meet Thakar — Mon, 11 May 2026 09:33:09 GMT

Hi,

Does your custom board have an eMMC?

Best Regards,

Meet.

RE: AM6421: Programming custom board with am6421bsefhaalvr, using only R5F core

s s — Mon, 11 May 2026 09:27:16 GMT

Hi Aryamaan,

Yes, we rebuilt the UART Uniflash example properly after making the suggested changes and generated updated binaries before testing.

We are also sharing the example.syscfg file for review of the Flash and OSPI configurations.

e2e.ti.com/.../7411.example.zip

RE: AM6421: Programming custom board with am6421bsefhaalvr, using only R5F core

Aryamaan Chaurasia — Mon, 11 May 2026 08:50:30 GMT

Hi,

[quote userid="686310" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1643076/am6421-programming-custom-board-with-am6421bsefhaalvr-using-only-r5f-core/6335770"]

In that case, you can skip the steps from the Custom Flash Support Guide and focus only on the SBL UART Uniflash buffer changes required for a no-DDR system.

RE: AM2431: AM2431 – UART Uniflash to OSPI Flashing Failure with HS-FS SBL on Custom Board

[/quote]

After making changes to the UART Uniflash example by following the above reply, have you rebuilt the example properly?

Also can you share the example.syscfg file for the UART Uniflash example? I'd like to check the Flash and OSPI configurations of that example.

Regards,

Aryamaan Chaurasia

MSPM33-SDK: How to enable DAC8 output to be connected to the pin in syscfg

Brendon Lee — Mon, 11 May 2026 08:38:08 GMT

Part Number: MSPM33-SDK

Hi,

I would like to know how to enable the DAC8 output to be connected to the pin, as I saw in the slau962 shows that there are register to enable DAC8 output to be connected to the pin. However, I can't see the enable option in the syscfg.

SDK's version : 1.3.0.01

SysConfig : 1.27.0

RE: AM6421: Programming custom board with am6421bsefhaalvr, using only R5F core

s s — Mon, 11 May 2026 08:31:19 GMT

Hi,

We are trying to flash sbl_null.release.hs_fs.tiimage using the python UART uniflash utility with the below command:

python uart_uniflash.py -p COM3 --cfg=sbl_prebuilt/am64x-evm/default_sbl_null.cfg

However, we are still observing the same behaviour where the first command in the .cfg executes successfully, but the second command gets stuck at 0% and no further flash operation happens.

Before this, we successfully debugged the diagnostic application:

ospi_flash_diag_am64x-evm_r5fss0-0_nortos_ti-arm-clang

Also, we were able to manually send sbl_null.release.hs_fs.tiimage through XMODEM protocol using TeraTerm utility, after which the diagnostic application runs correctly.

The debug output from the diagnostic test is attached below. It is able to correctly detect the Flash Manufacturer ID and Device ID:

Flash Manufacturer ID : 0x34
Flash Device ID       : 0x5B1A

Initially it showed:

Executing Flash Erase on first block...
Erase Failed !!!

But later the complete diagnostics including read/write/erase operations are passing successfully.

We also tested another example project:

ospi_flash_io_am64x-evm_r5fss0-0_nortos_ti-arm-clang

In debug mode, flash read/write/erase operations are working correctly there as well.

So currently the issue seems specific to flashing through the UART uniflash python command only:

python uart_uniflash.py -p COM3 --cfg=sbl_prebuilt/am64x-evm/default_sbl_null.cfg

where the second command in the .cfg gets stuck at 0%.

Below is the diagnostic log output:


MAIN_Cortex_R5_0_0: [OSPI Flash Diagnostic Test] Starting ...

MAIN_Cortex_R5_0_0: [OSPI Flash Diagnostic Test] Flash Manufacturer ID : 0x34

MAIN_Cortex_R5_0_0: [OSPI Flash Diagnostic Test] Flash Device ID : 0x5B1A

MAIN_Cortex_R5_0_0: [OSPI Flash Diagnostic Test] Executing Flash Erase on first block...

MAIN_Cortex_R5_0_0: [OSPI Flash Diagnostic Test] Erase Failed !!!

MAIN_Cortex_R5_0_0: [OSPI Flash Diagnostic Test] Performing Write-Read Test...

MAIN_Cortex_R5_0_0: [OSPI Flash Diagnostic Test] Write-Read Test Passed!

MAIN_Cortex_R5_0_0: [QSPI Flash Diagnostic Test] SFDP Information : 

MAIN_Cortex_R5_0_0: ================================================

MAIN_Cortex_R5_0_0: SFDP 

MAIN_Cortex_R5_0_0: ================================================

MAIN_Cortex_R5_0_0: SFDP Major Revision : 0x1

MAIN_Cortex_R5_0_0: SFDP Minor Revision : 0x8

MAIN_Cortex_R5_0_0: Number of Parameter Headers in this Table : 6

MAIN_Cortex_R5_0_0: 

MAIN_Cortex_R5_0_0: Types of Additional Parameter Tables in this flash

MAIN_Cortex_R5_0_0: ---------------------------------------------------

MAIN_Cortex_R5_0_0: 4 BYTE ADDRESSING MODE INSTRUCTIONS TABLE

MAIN_Cortex_R5_0_0: NOR SPI PROFILE TABLE 

MAIN_Cortex_R5_0_0: STATUS CONTROL AND CONFIGURATION REGISTER MAP TABLE

MAIN_Cortex_R5_0_0: OCTAL DDR MODE COMMAND SEQUENCE TABLE

MAIN_Cortex_R5_0_0: SECTOR MAP TABLE

MAIN_Cortex_R5_0_0: 

MAIN_Cortex_R5_0_0: Parsing of OCTAL DDR MODE COMMAND SEQUENCE TABLE table not yet supported. 

MAIN_Cortex_R5_0_0: JSON Data for the flash :

MAIN_Cortex_R5_0_0: 

MAIN_Cortex_R5_0_0: {

MAIN_Cortex_R5_0_0: 

MAIN_Cortex_R5_0_0: "flashSize": 67108864,

MAIN_Cortex_R5_0_0: "flashPageSize": 256,

MAIN_Cortex_R5_0_0: "flashManfId": "0x34",

MAIN_Cortex_R5_0_0: "flashDeviceId": "0x5B1A",

MAIN_Cortex_R5_0_0: "flashBlockSize": 262144,

MAIN_Cortex_R5_0_0: "flashSectorSize": 4096,

MAIN_Cortex_R5_0_0: "cmdBlockErase3B": "0xDC",

MAIN_Cortex_R5_0_0: "cmdBlockErase4B": "0xDC",

MAIN_Cortex_R5_0_0: "cmdSectorErase3B": "0x21",

MAIN_Cortex_R5_0_0: "cmdSectorErase4B": "0x21",

MAIN_Cortex_R5_0_0: "protos": {

MAIN_Cortex_R5_0_0: "p111": {

MAIN_Cortex_R5_0_0: "isDtr": false,

MAIN_Cortex_R5_0_0: "cmdRd": "0x03",

MAIN_Cortex_R5_0_0: "cmdWr": "0x02",

MAIN_Cortex_R5_0_0: "modeClksCmd": 0,

MAIN_Cortex_R5_0_0: "modeClksRd": 0,

MAIN_Cortex_R5_0_0: "dummyClksCmd": 0,

MAIN_Cortex_R5_0_0: "dummyClksRd": 0,

MAIN_Cortex_R5_0_0: "enableType": "0",

MAIN_Cortex_R5_0_0: "enableSeq": "0x00",

MAIN_Cortex_R5_0_0: "dummyCfg": null,

MAIN_Cortex_R5_0_0: "protoCfg": null,

MAIN_Cortex_R5_0_0: "strDtrCfg": null

MAIN_Cortex_R5_0_0: },

MAIN_Cortex_R5_0_0: "p112": null,

MAIN_Cortex_R5_0_0: "p114": null,

MAIN_Cortex_R5_0_0: "p118": null,

MAIN_Cortex_R5_0_0: "p444s": null,

MAIN_Cortex_R5_0_0: "p444d": null,

MAIN_Cortex_R5_0_0: "p888s": null,

MAIN_Cortex_R5_0_0: "p888d": {

MAIN_Cortex_R5_0_0: "isDtr": true,

MAIN_Cortex_R5_0_0: "cmdRd": "0xEE",

MAIN_Cortex_R5_0_0: "cmdWr": "0x12",

MAIN_Cortex_R5_0_0: "modeClksCmd": 0,

MAIN_Cortex_R5_0_0: "modeClksRd": 0,

MAIN_Cortex_R5_0_0: "dummyClksCmd": 4,

MAIN_Cortex_R5_0_0: "dummyClksRd": 24,

MAIN_Cortex_R5_0_0: "enableType": "0",

MAIN_Cortex_R5_0_0: "enableSeq": "0x00",

MAIN_Cortex_R5_0_0: "dummyCfg": {

MAIN_Cortex_R5_0_0: "isAddrReg": true,

MAIN_Cortex_R5_0_0: "cmdRegRd":"0x65",

MAIN_Cortex_R5_0_0: "cmdRegWr":"0x71",

MAIN_Cortex_R5_0_0: "cfgReg":"0x00800003",

MAIN_Cortex_R5_0_0: "shift":0,

MAIN_Cortex_R5_0_0: "mask":"0x03",

MAIN_Cortex_R5_0_0: "bitP":11

MAIN_Cortex_R5_0_0: },

MAIN_Cortex_R5_0_0: "protoCfg": {

MAIN_Cortex_R5_0_0: "isAddrReg": true,

MAIN_Cortex_R5_0_0: "cmdRegRd": "0x65",

MAIN_Cortex_R5_0_0: "cmdRegWr": "0x71",

MAIN_Cortex_R5_0_0: "cfgReg": "0x00800006",

MAIN_Cortex_R5_0_0: "shift": 0,

MAIN_Cortex_R5_0_0: "mask": "0x00",

MAIN_Cortex_R5_0_0: "bitP": 0

MAIN_Cortex_R5_0_0: },

MAIN_Cortex_R5_0_0: "strDtrCfg": {

MAIN_Cortex_R5_0_0: "isAddrReg": true,

MAIN_Cortex_R5_0_0: "cmdRegRd": "0x65",

MAIN_Cortex_R5_0_0: "cmdRegWr": "0x71",

MAIN_Cortex_R5_0_0: "cfgReg": "0x00800006",

MAIN_Cortex_R5_0_0: "shift": 1,

MAIN_Cortex_R5_0_0: "mask": "0x00",

MAIN_Cortex_R5_0_0: "bitP": 1

MAIN_Cortex_R5_0_0: }

MAIN_Cortex_R5_0_0: },

MAIN_Cortex_R5_0_0: "pCustom": { 

MAIN_Cortex_R5_0_0: "fxn": null

MAIN_Cortex_R5_0_0: }

MAIN_Cortex_R5_0_0: },

MAIN_Cortex_R5_0_0: "addrByteSupport": "1",

MAIN_Cortex_R5_0_0: "fourByteAddrEnSeq": "0xA1",

MAIN_Cortex_R5_0_0: "cmdExtType": "REPEAT",

MAIN_Cortex_R5_0_0: "resetType": "0x10",

MAIN_Cortex_R5_0_0: "deviceBusyType": "1",

MAIN_Cortex_R5_0_0: "cmdWren": "0x06",

MAIN_Cortex_R5_0_0: "cmdRdsr": "0x05",

MAIN_Cortex_R5_0_0: "srWip": 0,

MAIN_Cortex_R5_0_0: "srWel": 1,

MAIN_Cortex_R5_0_0: "cmdChipErase": "0xC7",

MAIN_Cortex_R5_0_0: "rdIdSettings": {

MAIN_Cortex_R5_0_0: "cmd": "0x9F",

MAIN_Cortex_R5_0_0: "numBytes": 5,

MAIN_Cortex_R5_0_0: "dummy4": 0,

MAIN_Cortex_R5_0_0: "dummy8": 0

MAIN_Cortex_R5_0_0: },

MAIN_Cortex_R5_0_0: "xspiWipRdCmd": "0x65",

MAIN_Cortex_R5_0_0: "xspiWipReg": "0x00800000",

MAIN_Cortex_R5_0_0: "xspiWipBit": 0,

MAIN_Cortex_R5_0_0: "flashDeviceBusyTimeout": 256000000,

MAIN_Cortex_R5_0_0: "flashPageProgTimeout": 512

MAIN_Cortex_R5_0_0: }

MAIN_Cortex_R5_0_0: 

MAIN_Cortex_R5_0_0: All tests have passed!!

Could you please suggest what could cause the UART uniflash flow to get stuck only during the second command, even though manual XMODEM loading and debug-mode flash operations are working correctly?

RE: AM2634: AM2634 - CCS 20.4.1 ==> unable to debug from CCS

Lakshya Verma — Mon, 11 May 2026 07:40:16 GMT

Hi Sue,
I will get back to you

AM2634: AM2634 - CCS 20.4.1 ==> unable to debug from CCS

Sue A — Fri, 08 May 2026 18:31:23 GMT

Part Number: AM2634

Hi TI,

I am running a multicore project where core0 is run in lockstep mode. Below is my TCM memory assignments and sections from the linker.cmd file. Initially I was not using .tcmb_data memory region and I was able to enter into debug session from CCS. However, recently, I have added some variables to .tcmb_data region after which I am not able to enter debug session from CCS as it throws below error.
Could you please let me know how to resolve this issue as debugging from CCS is imporant to our project to run tests during development phase. And I don't see anything wrong with the TCM region memory assignment and usage.
Thanks in advance!

Cortex_R5_0: Trouble Writing Memory Block at 0x88000 on Page 0 of Length 0x440: (Error -1065 @ 0x0) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 20.5.0.3902)

Cortex_R5_0: File Loader: Verification failed: Target failed to write 0x00088000

Cortex_R5_0: GEL: File: C:\Users\ab123\workspace_ccstheia\AM263x_CORTEX_R5_0\Debug\AM263x_CORTEX_R5_0.out: Load failed.

MSPM0G1507: When communicating in Fast-mode (400kHz), the controller side shifts the data by 1 byte in repeated start operation

O.H — Tue, 21 Apr 2026 07:47:13 GMT

Part Number: MSPM0G1507

H iexperts,

This is a continuation of the thread below.
:(1) MSPM0G1507: When communicating in Fast-mode (400kHz), the controller side shifts the data by 1 byte. - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

I have confirmed the customer’s actual usage. The MSPM0G1507 will be used as the target device, and the controller may perform both normal START/STOP communication and repeated START communication.

In the actual use case, this is not an echo operation. As shown in the figure below, the data received from the controller is treated as address information, and the target returns the data stored in its address space starting from the address indicated by the last received data byte. Therefore, each time the target receives data, it needs to move the corresponding data into the TXFIFO in advance.

With that in mind, although this is a repeated question:
Q: When using repeated START, are there any concerns with moving data into the TXFIFO at the timing of the RxFIFO trigger (threshold = 1) as a method of preparing the TXFIFO before the repeated START trigger occurs? If there is any other recommended approach, please let me know.

For reference, I modified the program original thread provided as attached so that the data is moved into the TXFIFO at the timing of the RxFIFO trigger (threshold = 1). I would appreciate it if you could let me know whether there are any concerns with this method or whether there is another recommended approach.

[View:/cfs-file/__key/communityserver-discussions-components-files/908/i2c_5F00_target_5F00_rw_5F00_multibyte_5F00_fifo_5F00_interrupts.c:320:240]

Best regards,
O.H