Processors forum - Recent Threads

TDA4VM: OSPI PHY Tuning vectors

Prasanna Raghunathan — Wed, 06 May 2026 23:17:51 GMT

Part Number: TDA4VM

Hi,

I am currently working on bringing up our custom board with TD4AVM platform. Most of our board is based on the J721E-SOM with an exception being the OSPI Flash device. The board is using the same device as on the SK-TDA4VM - Infineon S28HL512T.

Do I need to run the PHY Tuning algorithm to generate the vectors before I can start using the flash device ? Is there any defaults that I can use for this flash device ?
On the AM2431 EVM, the mcu_plus_sdk has some defaults defined for the flash in the uart_uniflash tool. I am wondering if those vectors can be re-used ?
I got the board up and running with UART Boot. I loaded a linux image and then performed some flash access, it does seem to work but it is very slow compared to the EVM.
Based on my previous experince with the AM2431 EVM , If the vectors are not present , I believe the R5 SPL will automatically fallback to configure the Controller to use the slower speeds in regular SPI mode.
Using the same tiboot3.bin, sysfw and tispl, I am not able to boot from the OSPI Flash. I am not sure if this is due to the PHY not tuned or a secondary issue with my images. Simple flash reads and writes are working from Uboot.

Thanks,

Prasanna

RE: TDA4VM: OSPI PHY Tuning vectors

Brijesh Jadav — Sat, 09 May 2026 06:06:27 GMT

Hi,

PHY tuning algo is already available in the SDK. When you boot SBL from xSPI/OSPI, SBL runs the phy tuning, when PHY is enabled. You would just need to write tuning data in last sector of the flash.

Regards,

Brijesh

RE: AM62A7: Failed to Load the model in AM62A when using TIDL as the backend.

Biao Li — Sat, 09 May 2026 02:13:38 GMT

Hi Jay,

can you help try this model in your side directly? I think it don't make sense to me if customer can run it using PC TIDLExecutionProvider but failed in EVM, it will be more efficiently to help customer fix this issue.

BR,

Biao

AM62A7: Failed to Load the model in AM62A when using TIDL as the backend.

Yongbing Li — Wed, 06 May 2026 10:34:06 GMT

Part Number: AM62A7

Hi Team,

I am debugging a YOLOv8 model on the AM62A platform. The model compiles successfully, but an error occurs when loading the compiled artifacts on the AM62A board. The input image resolution for this model is 1280x1280. The logs during loading are as follows:

libtidl_onnxrt_EP loaded 0x3c94d2a0
Final number of subgraphs created are : 2, - Offloaded Nodes - 231, Total Nodes - 234
APP: Init ... !!!
6556.195943 s: MEM: Init ... !!!
6556.196024 s: MEM: Initialized DMA HEAP (fd=5) !!!
6556.196208 s: MEM: Init ... Done !!!
6556.196239 s: IPC: Init ... !!!
6556.213555 s: IPC: Init ... Done !!!
REMOTE_SERVICE: Init ... !!!
REMOTE_SERVICE: Init ... Done !!!
6556.217774 s: GTC Frequency = 200 MHz
APP: Init ... Done !!!
6556.217946 s: VX_ZONE_INFO: Globally Enabled VX_ZONE_ERROR
6556.217972 s: VX_ZONE_INFO: Globally Enabled VX_ZONE_WARNING
6556.217981 s: VX_ZONE_INFO: Globally Enabled VX_ZONE_INFO
6556.218837 s: VX_ZONE_INFO: [tivxPlatformCreateTargetId:169] Added target MPU-0
6556.219596 s: VX_ZONE_INFO: [tivxPlatformCreateTargetId:169] Added target MPU-1
6556.220038 s: VX_ZONE_INFO: [tivxPlatformCreateTargetId:169] Added target MPU-2
6556.220295 s: VX_ZONE_INFO: [tivxPlatformCreateTargetId:169] Added target MPU-3
6556.220322 s: VX_ZONE_INFO: [tivxInitLocal:202] Initialization Done !!!
6556.220356 s: VX_ZONE_INFO: Globally Disabled VX_ZONE_INFO
6556.327341 s: VX_ZONE_ERROR: [ownContextSendCmd:1001] Command ack message returned failure cmd_status: -1
6556.327387 s: VX_ZONE_ERROR: [ownNodeKernelInit:704] Target kernel, TIVX_CMD_NODE_CREATE failed for node TIDLNode
6556.327402 s: VX_ZONE_ERROR: [ownNodeKernelInit:705] Please be sure the target callbacks have been registered for this core
6556.327414 s: VX_ZONE_ERROR: [ownNodeKernelInit:706] If the target callbacks have been registered, please ensure no errors are occurring within the create callback of this kernel
6556.327430 s: VX_ZONE_ERROR: [ownGraphNodeKernelInit:793] kernel init for node 0, kernel com.ti.tidl:6:1 ... failed !!!
6556.327480 s: VX_ZONE_ERROR: [ TIDL subgraph output0 ] Node kernel init failed
6556.327494 s: VX_ZONE_ERROR: [ TIDL subgraph output0 ] Graph verify failed

Inference results are normal when using the CPU as the backend.

Below is my compilation configuration:

"yolov8_dahao_onnx": create_model_config(
# Determines which set of test images the script selects, which post-processing branch is triggered,
# and the 'model_type' field written into param.yaml.
# Options: classification / detection / segmentation
task_type="detection", source=dict(
infer_shape=True, # No download needed, model_url left empty; infer_shape executes even if the file exists
),
preprocess=dict(
resize=1280, crop=1280,

# data_layout: Memory layout of the ONNX Runtime input tensor; ONNX models are fixed to NCHW.
data_layout="NCHW",

# reverse_channels: Written to param.yaml for reference by the board-side program.
# PIL reads images as RGB, and Ultralytics training also uses RGB, so no flipping is needed.
# Set to True to indicate "RGB input expected".
# (Note: infer_image does not actually perform channel flipping, only records it in the config file)
reverse_channels=True,

# resize_with_pad: [True, "corner"] indicates Letterbox scaling (maintain aspect ratio + gray padding).
# Ultralytics uses Letterbox during training, so calibration data preprocessing must be consistent with this.
resize_with_pad=[True, "corner"],

# pad_color: Letterbox padding color; Ultralytics strictly uses [114, 114, 114] (medium gray).
pad_color=[114, 114, 114],
),

session=dict(
# session_name: Fixed to "onnxrt" to identify the use of the ONNX Runtime path.
session_name="onnxrt",

# model_path: Path to the ONNX file (relative to the script working directory examples/osrt_python/ort/).
# models_base_path = '../../../models/public/', place the file in this directory.
model_path=os.path.join(models_base_path, "yolov8_dahao.onnx"),

# input_mean / input_scale: infer_image() normalizes calibration images as follows:
# normalized = (pixel_value - mean) * scale
# Ultralytics YOLOv8 expects [0, 1] float input:
# mean = [0, 0, 0], scale = 1/255 ≈ 0.003921568627 → pixel [0,255] → [0,1]
input_mean=[0.0, 0.0, 0.0],
input_scale=[0.003921568627, 0.003921568627, 0.003921568627],
meta_arch_type = -1,
# input_optimization: When True, embeds mean/scale as pre-processing nodes permanently into the ONNX file.
# Trigger condition: model_path file does not exist (optimizes immediately after download).
# This item is invalid if the local file already exists; setting it to False makes the semantics clearer.
input_optimization=False,

# meta_arch_type / meta_layers_names_list not set (default -1 / ""):
# TIDL does not enable built-in post-processing acceleration, compiling the ONNX graph as-is;
# Operators unsupported by TIDL in the Detect module (such as NonMaxSuppression) automatically fallback to the ARM CPU.
),

# The formatter is only used for the inference visualization stage after compilation (det_box_overlay).
# Post-processing is not executed during the compilation (-c) stage, but the field must exist
# to ensure gen_param_yaml can correctly write param.yaml.
# DetectionBoxSL2BoxLS: Swaps the 4th and 5th columns of the output tensor (score ↔ label),
# matching the YoloV5 visualization branch of onnxrt_ep.py (output[0][i][4] is confidence).
postprocess=dict(
formatter="DetectionBoxSL2BoxLS",
),

extra_info=dict(
# od_type: Branch selection key for det_box_overlay() during inference visualization;
# Ultralytics standard output format (includes NMS, 6 columns per box: x1 y1 x2 y2 conf cls).
# Matches the "YoloV5" branch (output[0][i][4] = confidence).
od_type="YoloV5",

# framework: MMDetection branch key for det_box_overlay(), leave empty to skip this branch.
framework="",

# num_images: Controls the number of frames in the compilation/inference loop (numImages=3 on x86);
# Actual calibration frames are taken as min(num_images, calibration_frames), overridden by runtime_options.
num_images=numImages,

num_classes=80,

# label_offset_type / label_offset: Used by gen_param_yaml to generate the label_offset_pred field,
# for the board-side post-processing program to perform class ID mapping.
# "80to90" + offset=1: COCO 80 classes → 91 class ID offset (skip background=0);
# Selecting this combination for custom datasets is harmless, affecting only the offset table in param.yaml, not the compilation itself.
label_offset_type="80to90",
label_offset=1,
),

runtime_options={
# calibration_frames: Number of frames used for calibration.
# Default value in common_utils.py is 2 (very low, for demonstration only);
# Documentation recommends at least 10, production compilation recommends ≥ 20.
# The script will loop and reuse the calib_images list (only 2 images) to reach this quantity.
"advanced_options:calibration_frames": 20,

# calibration_iterations: Number of bias calibration iterations (valid when accuracy_level=1).
# Default value in common_utils.py is 5; documentation recommends at least 10, production compilation recommends ≥ 50.
"advanced_options:calibration_iterations": 50,
},
),
}

I saw similar issues on E2E but did not find a definite conclusion or solution. Please analyze whether my compilation configuration is correct.

Thank you very much.

LP-AM243: How to Flash Firmware to Flash Memory So It Can Run After a Power Cycle

Bayu Eko — Sat, 09 May 2026 01:59:37 GMT

Part Number: LP-AM243

Hi, I'm new to the LP-AM243. Currently, I am still developing the firmware and wondering how to flash the firmware into the flash memory so that it can still run after a power cycle.

Currently, I am using the LP-AM243 development board, and I have set the boot DIP switch to QSPI boot mode. The bootloader is currently running the NULL bootloader, so whenever I reset or power cycle the board, I need to flash the firmware again.

By the way, the memory allocation in my code looks like this:

I wonder if I need a larger flash memory to store the firmware, because as you can see, the MSRAM usage is around 1262 KB.

TDA4VH-Q1: After porting the camera code from SDK 8.6 to SDK 11.1 access to the serializer within the camera module failed

Linda Wang — Mon, 13 Apr 2026 03:40:17 GMT

Part Number: TDA4VH-Q1

After porting the camera code from SDK 8.6 to SDK 11.1, access to the MAX96722 deserializer was successful, and the GMSL link was established; however, access to the serializer within the camera module failed.

More details:

Camera: Huayang

Serializer: MAX96705

RE: TDA4VH-Q1: After porting the camera code from SDK 8.6 to SDK 11.1 access to the serializer within the camera module failed

Yong Zhang — Sat, 09 May 2026 01:56:33 GMT

update from customer.

customer fix the issue, could be some timing requirement on SERDES.

Dear Gokul.

close this ticket.

thanks for the support!

yong

LP-AM243: ModbusTCP Server does not update the data registers (coils, discrete inputs) in real time

Bayu Eko — Sat, 09 May 2026 01:48:35 GMT

Part Number: LP-AM243

Hi, I have a problem with the Industrial Modbus TCP Server example.

I am using:

ind_comms_sdk_am243x_2025_00_00_08
mcu_plus_sdk_am243x_11_01_00_19

Previously, I already asked a related question on this thread:
LP-AM243: How to improve Modbus TCP server response time performance? - Processors forum - Processors - TI E2E support forums

I already tried the suggested workaround by adding:

#define TCP_TMR_INTERVAL 10

to the lwipopts.h file in the lwIP library:

C:\ti\mcu_plus_sdk_am243x_11_01_00_19\source\networking\lwip

Then I recompiled the library successfully and included it in the Industrial Communications Modbus TCP Server example.

However, when I tested it, the result was still the same.

I tested several Modbus functions such as:

Read Discrete Inputs (FC 2)
Write Multiple Coils (FC 15)

I used several Modbus TCP client applications on my computer and monitored the traffic using Wireshark. I calculated the time difference between the request and response packets.

The response times are:

FC 2: around 1 ms
FC 15: around 14 ms

However, the strange thing is that the data values are not updated simultaneously. The data only gets updated after around 200 ms.

Could you help explain what may cause this delay and which part of the example project or stack should be checked?

RE: AM62L-LINUX-SDK: Am6254 GPMC0_A[16-19] not output address signal.

Yi Yang — Sat, 09 May 2026 01:37:21 GMT

Hi Mark,

Thank you for your reply. I have identified my issue. I should use GPMC0_A[1-4], but on the PCB, it is directly connected to GPMC0_A[16-19]. I have already communicated with the hardware engineer to modify the PCB.

Best,

-Yi

AM62L-LINUX-SDK: Am6254 GPMC0_A[16-19] not output address signal.

Yi Yang — Mon, 27 Apr 2026 06:33:39 GMT

Part Number: AM62L-LINUX-SDK

Hi:

The current requirement is to configure GPMC for communication with FPGA. Use the 16-bit data address multiplexing mode. However, the address lines do not meet the requirements and need to use GPMC0_A[16-19] for address expansion. I configured the pin attributes of GPMC0_A[16-19], but was unable to output the address signal. The content of the device tree file is as follows:

/* =========================================================
* Genegeo AM62x GPMC configuration
* ========================================================= */

/* ---------------------------------------------------------
* Reserved memory for GPMC DMA
* --------------------------------------------------------- */
&{/}
{
dma_memcpy {
status = "okay";
compatible = "dma_memcpy";
};
};

&reserved_memory {
gpmc_dma: gpmc-dma@9c000000 {
compatible = "shared-dma-pool";
reg = <0x00 0x9c000000 0x00 0x00700000>; // 7MB
no-map;
};
};

&main_bcdma {
status = "okay";
};

/* ---------------------------------------------------------
* GPMC pinmux configuration
* --------------------------------------------------------- */
&main_pmx0 {
main_gpmc_pins_default: main_gpmc_pins_default {
pinctrl-single,pins = <
AM62X_IOPAD(0x00b8, PIN_OUTPUT, 1) /* VOUT0_DATA0 GPMC0_A0 */
AM62X_IOPAD(0x00bc, PIN_OUTPUT, 1) /* VOUT0_DATA1 GPMC0_A1 */
AM62X_IOPAD(0x00c0, PIN_OUTPUT, 1) /* VOUT0_DATA2 GPMC0_A2 */
AM62X_IOPAD(0x00c4, PIN_OUTPUT, 1) /* VOUT0_DATA3 GPMC0_A3 */
AM62X_IOPAD(0x00c8, PIN_OUTPUT, 1) /* VOUT0_DATA4 GPMC0_A4 */
AM62X_IOPAD(0x00cc, PIN_OUTPUT, 1) /* VOUT0_DATA5 GPMC0_A5 */
AM62X_IOPAD(0x00d0, PIN_OUTPUT, 1) /* VOUT0_DATA6 GPMC0_A6 */
AM62X_IOPAD(0x00d4, PIN_OUTPUT, 1) /* VOUT0_DATA7 GPMC0_A7 */
AM62X_IOPAD(0x00d8, PIN_OUTPUT, 1) /* VOUT0_DATA8 GPMC0_A8 */
AM62X_IOPAD(0x00dc, PIN_OUTPUT, 1) /* VOUT0_DATA9 GPMC0_A9 */
AM62X_IOPAD(0x00e0, PIN_OUTPUT, 1) /* VOUT0_DATA10 GPMC0_A10 */
AM62X_IOPAD(0x00e4, PIN_OUTPUT, 1) /* VOUT0_DATA11 GPMC0_A11 */
AM62X_IOPAD(0x00e8, PIN_OUTPUT, 1) /* VOUT0_DATA12 GPMC0_A12 */
AM62X_IOPAD(0x00ec, PIN_OUTPUT, 1) /* VOUT0_DATA13 GPMC0_A13 */
AM62X_IOPAD(0x00f0, PIN_OUTPUT, 1) /* VOUT0_DATA14 GPMC0_A14 */
AM62X_IOPAD(0x00f4, PIN_OUTPUT, 1) /* VOUT0_DATA15 GPMC0_A15 */
AM62X_IOPAD(0x00f8, PIN_OUTPUT, 1) /* VOUT0_HSYNC GPMC0_A16 */
AM62X_IOPAD(0x00fc, PIN_OUTPUT, 1) /* VOUT0_DE GPMC0_A17 */
AM62X_IOPAD(0x0100, PIN_OUTPUT, 1) /* VOUT0_VSYNC GPMC0_A18 */
AM62X_IOPAD(0x0104, PIN_OUTPUT, 1) /* VOUT0_PCLK GPMC0_A19 */

AM62X_IOPAD(0x003c, PIN_INPUT, 0) /* GPMC0_AD0 */
AM62X_IOPAD(0x0040, PIN_INPUT, 0) /* GPMC0_AD1 */
AM62X_IOPAD(0x0044, PIN_INPUT, 0) /* GPMC0_AD2 */
AM62X_IOPAD(0x0048, PIN_INPUT, 0) /* GPMC0_AD3 */
AM62X_IOPAD(0x004c, PIN_INPUT, 0) /* GPMC0_AD4 */
AM62X_IOPAD(0x0050, PIN_INPUT, 0) /* GPMC0_AD5 */
AM62X_IOPAD(0x0054, PIN_INPUT, 0) /* GPMC0_AD6 */
AM62X_IOPAD(0x0058, PIN_INPUT, 0) /* GPMC0_AD7 */
AM62X_IOPAD(0x005c, PIN_INPUT, 0) /* GPMC0_AD8 */
AM62X_IOPAD(0x0060, PIN_INPUT, 0) /* GPMC0_AD9 */
AM62X_IOPAD(0x0064, PIN_INPUT, 0) /* GPMC0_AD10 */
AM62X_IOPAD(0x0068, PIN_INPUT, 0) /* GPMC0_AD11 */
AM62X_IOPAD(0x006c, PIN_INPUT, 0) /* GPMC0_AD12 */
AM62X_IOPAD(0x0070, PIN_INPUT, 0) /* GPMC0_AD13 */
AM62X_IOPAD(0x0074, PIN_INPUT, 0) /* GPMC0_AD14 */
AM62X_IOPAD(0x0078, PIN_INPUT, 0) /* GPMC0_AD15 */

AM62X_IOPAD(0x00a8, PIN_OUTPUT, 0) /* GPMC0_CSn0 */
AM62X_IOPAD(0x0084, PIN_OUTPUT, 0) /* GPMC0_ADVn_ALE */
AM62X_IOPAD(0x0088, PIN_OUTPUT, 0) /* GPMC0_OEn_REn */
AM62X_IOPAD(0x008c, PIN_OUTPUT, 0) /* GPMC0_WEn */
>;
};
};

/* ---------------------------------------------------------
* Enable GPMC controller
* --------------------------------------------------------- */
&gpmc0 {
status = "okay";

#address-cells = <2>;
#size-cells = <1>;

pinctrl-names = "default";
pinctrl-0 = <&main_gpmc_pins_default>;

ranges = <0 0 0x00 0x50000000 0x01000000>; /* CS0 space. Min partition = 16MB */

nor@0,0 {
compatible = "genegeo-gpmc";

reg = <0 0x00000000 0x01000000>; /* 16MB FPGA window */

dmas = <&main_bcdma 0x20 0 0>, <&main_bcdma 0x21 0 0>,
<&main_bcdma 0x22 0 0>, <&main_bcdma 0x23 0 0>,
<&main_bcdma 0x24 0 0>, <&main_bcdma 0x25 0 0>,
<&main_bcdma 0x26 0 0>, <&main_bcdma 0x27 0 0>;

dma-names = "rbc", "wbc", "diff", "crp1", "crp2", "crp3", "crp4", "tsfile";

#address-cells = <1>;
#size-cells = <1>;

bank-width = <2>; /* 16-bit */
gpmc,mux-add-data = <2>;

gpmc,cs-on-ns = <0>;
gpmc,cs-rd-off-ns = <180>;
gpmc,cs-wr-off-ns = <180>;

gpmc,adv-on-ns = <0>;
gpmc,adv-rd-off-ns = <40>;
gpmc,adv-wr-off-ns = <40>;

gpmc,oe-on-ns = <60>;
gpmc,oe-off-ns = <180>;
gpmc,we-on-ns = <60>;
gpmc,we-off-ns = <180>;

gpmc,rd-cycle-ns = <200>;
gpmc,wr-cycle-ns = <200>;
gpmc,access-ns = <120>;
gpmc,page-burst-access-ns = <0>;

gpmc,bus-turnaround-ns = <0>;
gpmc,cycle2cycle-delay-ns = <50>;
gpmc,wr-data-mux-bus-ns = <80>;

gpmc,cycle2cycle-samecsen = <10>;
gpmc,cycle2cycle-diffcsen = <0>;
};
};

AM69A: Need Rev E TRM

Rez Ameli — Fri, 08 May 2026 22:58:16 GMT

Part Number: AM69A

Hi team,

customer is looking for rev E of the TRM.

where can we find it?

thank you

RE: AM69A: Need Rev E TRM

Jared McArthur — Sat, 09 May 2026 00:46:53 GMT

Hi Rez Ameli,

You can find it here: https://www.ti.com/lit/zip/spruj52

The link will automatically go to revision E (the most recent revision). When a new revision is released, it will then go to that revision.

Best,
Jared

RE: AM62A7: Use of VISS components without DSP

Jianzhong Xu — Fri, 08 May 2026 22:26:51 GMT

Hello,

The SDK 9.2 doesn't support powering down C7x DSP. Can you try with the latest SDK, 11.1?

Please also refer to instructions at Booting Remote Cores.

Regards,

Jianzhong

AM62A7: Use of VISS components without DSP

Sathiya Narayanan — Thu, 07 May 2026 13:12:13 GMT

Part Number: AM62A7

I am using SDK 9.2 for my battery operated appllication.

I am using camera with external ISP. So I actually don't want to use internal ISP.

As it is battery operated device, I need to put the system into deepsleep. But AM62A will not support deep sleep with C7X DSP. For that, I disabled the DSP completely.

I want to utilize tiovxldc and tiovxmultiscaler for colorconvert and downscaling the stream. But current architechture has built in DSP dependency. Because of which the pipeline is not starting.

Please suggest me a way to unlock LDC and MSC (even ISP if possible) without querying for DSP.

To disable DSP, add this at the end of device tree (k3-am62a7-sk.dts):

/delete-node/&c7x_0;
/delete-node/&c7x_0_dma_memory_region;
/delete-node/&c7x_0_memory_region;

Here is the pipeline I used:

gst-launch-1.0 v4l2src device=/dev/video2 io-mode=5 ! video/x-raw,width=2592,height=1944,format=UYVY !  tiovxldc ! video/x-raw,width=2592,height=1944,format=NV12 ! fakesink

RE: AM62A7: Use of VISS components without DSP

Jianzhong Xu — Fri, 08 May 2026 22:25:01 GMT

Hello,

The SDK 9.2 doesn't support powering down C7x DSP. Can you try with the latest SDK, 11.1?

Please also refer to instructions at Booting Remote Cores.

Regards,

Jianzhong

AM6412: launching LPDDR4 Eye Tool from uboot

Thomas Langhammer — Tue, 21 Apr 2026 09:01:39 GMT

Part Number: AM6412

Hi,
I am trying to launch the AM64x LPDDR4 eye tool on our custom board. For security reasons I do not have JTAG test points, so I would like to try to launch the image via u-boot.
However u-boot does not accept any of the images supplied or generated (.out, .rprc, .appimage). The readme.txt from the eye tool also mentions UART boot, but we do not have the *.tiimage files for our board, only tiboot3.bin, tispl.bin and u-boot.img (which contain DRAM init code for our board).
Is there any possibility to run the eye tool from u-boot command line or with tiboot3.bin and tispl.bin?

RE: AM6412: launching LPDDR4 Eye Tool from uboot

Lucas Bowe — Fri, 08 May 2026 22:17:58 GMT

Greetings Thomas,

I had some trouble installing dependencies (some kind of IT issue) for the most recent SDK version, so I ended up using an older version that was installed on the PC I hooked the board up to, 11.01.00.17. The steps should be the same regardless of version.

Rename the board_ddrReginit.h from sysconfig to board_lpddrReginit.h
Place board_lpddrReginit.h under source\drivers\ddr\v0\soc\am64x_am243x, which will replace the version already there.
Recompile the drivers used by the sbl_uart application, which should be the r5f nortos version of the drivers. The command I used is below, though the location of your SDK may differ
1. ```
gmake -C C:\ti\mcu_plus_sdk_am64x_11_01_00_17\source\drivers --makefile C:\ti\mcu_plus_sdk_am64x_11_01_00_17\source\drivers\makefile.am64x.r5f.ti-arm-clang.nortos
```

Once the drivers are recompiled, then recompile the actual sbl_uart application with the updated drivers

gmake -C C:\ti\mcu_plus_sdk_am64x_11_01_00_17\examples\drivers\boot\sbl_uart\am64x-sk\r5fss0-0_nortos\ti-arm-clang\

If you have not already, you'll need to convert the firmware from an elf file to an appimage (and will likely need to sign it as well).

Convert to rprc

node .\out2rprc\elf2rprc.js .\AM64X_TEye_A53_read.out

Convert to appimage

node .\multicoreImageGen\multicoreImageGen.js --devID 55 .\AM64X_TEye_A53_read.rprc@0 --out .\AM64X_TEye_A53_read_unsigned.appimage

Sign the appimage

python ..\..\source\security\security_common\tools\boot\signing\appimage_x509_cert_gen.py --bin .\AM64X_TEye_A53_read_unsigned.appimage --authtype 1 --key ..\..\source\security\security_common\tools\boot\signing\app_degenerateKey.pem --output .\AM64X_TEye_A53_read_signed.appimage

Once you have the signed appimage and the recompiled UART SBL, you can boot the device over UART like so (I also chained the command into the serial software installed on that PC to save some clicks, but yours may differ):
1. ```
python .\uart_bootloader.py -p COM21 --bootloader=..\..\examples\drivers\boot\sbl_uart\am64x-sk\r5fss0-0_nortos\ti-arm-clang\sbl_uart.release.hs_fs.tiimage --file=.\AM64X_TEye_A53_read_signed.appimage ; ttermpro.exe /C=21
```

Sincerely,

Lucas

AM625: CLKOUT0 frequency configuration

Tony Tang — Thu, 23 Apr 2026 06:15:57 GMT

Part Number: AM625

This question was asked many times on the forum. would like to get a conclusion.

The CLKOUT0(A18) pin is just a pin to observe clock output, but seems it is bond with CPSW RMII mode configuration to enable it and output 50MHz.

#1. How to configure it output 25MHz/50MHz alone without CPSW in Linux?

#2. The same question for wkup_clkout0?

RE: AM625: CLKOUT0 frequency configuration

Bin Liu — Fri, 08 May 2026 21:50:48 GMT

Hi Tony,

Using kernel devicetree k3-am625-beagleplay.dts as an example, CLKOUT0 is defined as

&cpsw3g {
        pinctrl-names = "default";
        pinctrl-0 = <&rgmii1_pins_default>, <&spe_pins_default>,
                    <&gbe_pmx_obsclk>;
        assigned-clocks = <&k3_clks 157 70>, <&k3_clks 157 20>;
        assigned-clock-parents = <&k3_clks 157 72>, <&k3_clks 157 22>;
};

The second element in line 5 and 6 configures CLKOUT0. You can copy the following two lines to any DT node to configure CLKOUT0, it is not tied to cpsw3g.

assigned-clocks = <&k3_clks 157 20>;
assigned-clock-parents = <&k3_clks 157 22>;

In the first line, "157" is the device ID which CLKOUT0 belongs to, "20" is the clk ID for CLKOUT0.

In the second line, the second number is the clk ID for the clk mux input selected for CLKOUT0. "22" PLL2_HSDIV1_CLKOUT/5 (50MHz), while "23" is PLL2_HSDIV1_CLKOUT/10 (25MHz).

WKUP_CLKOUT0 can be configured in the same way. The device ID will still be "157", the clk ID for WKUP_CLKOUT0 is "158", and the clk IDs for its clkmux input are 159 ~ 165. So an example of WKUP_CLKOUT0 configuration:

assigned-clocks = <&k3_clks 157 158>;
assigned-clock-parents = <&k3_clks 157 159>;

All these device ID and clk ID details are in

AM62X Clock Identifiers — TISCI User Guide

RE: MSP430-SDK: CCS 12.4.0

Ki — Fri, 08 May 2026 21:42:37 GMT

[quote userid="474063" url="~/support/processors-group/processors/f/processors-forum/1643068/msp430-sdk-ccs-12-4-0/6337954"]

Does the command:

eclipse -data <WORKSPACE> -nosplash -application com.ti.ccstudio.apps.modifyProject -ccs.project <PROJECT> --define=HWID_VARIANT=4711

work?

[/quote]

No. Try (assuming you are on Linux):

eclipse -data <WORKSPACE> -nosplash -application com.ti.ccstudio.apps.modifyProject -ccs.project <PROJECT> --ccs.setCompilerOptions "--define=HWID_VARIANT=4711"

MSP430-SDK: CCS 12.4.0

Andreas Kaeberlein — Wed, 06 May 2026 13:08:22 GMT

Part Number: MSP430-SDK

I need to modify a CCS project via command line. There i like to set the value of a predefined symbol:

For instance i like to set HWID_VARIANT=4711. How i can do this with the CLI similar to the scrennshoot from above.

I need a command in the style below:

eclipse -data <WORKSPACE> -nosplash -application com.ti.ccstudio.apps.modifyProject -ccs.project <PROJECT>

Thanks for your support.

AM3358: Dual-sourcing NAND (different OOB sizes) with a single source in uboot of oldversion

GIHWAN AHN — Mon, 20 Apr 2026 06:27:21 GMT

Part Number: AM3358

Hi TI Experts,

We are developing a single firmware image to support two different NAND flashes on our AM335x custom board.

NAND A (Micron): OOB size 224
NAND B (Macronix): OOB size 256

We are using an older TI SDK (U-Boot 2014.07, Linux Kernel 3.14).

[Our Hardware Constraints & Identification Method] To be fully transparent about our hardware situation: our custom board currently has absolutely NO spare GPIO pins, and the I2C EEPROM addresses/data fields are fully utilized. The ONLY pin available for board revision identification is ADC channel 4 (AIN4). Therefore, we are forced to read the ADC voltage during the U-Boot stage to determine which NAND flash is mounted.

Given this strict hardware limitation, we want to ensure our software architecture is robust and doesn't break the ONFI detection. We are planning the following flow:

[Our Proposed Software Architecture]

U-Boot Stage: U-Boot reads the ADC (AIN4) to identify the board revision. It then appends a custom parameter to the bootargs (e.g., appending nand_type=macronix via U-Boot environment variables). We do NOT override the OOB size in U-Boot's board_nand_init.
Linux Kernel Stage: The Linux kernel parses the nand_type from bootargs.
MTD Driver Override: Inside the Linux NAND driver (e.g., omap2.c), after nand_scan_ident() finishes (so ONFI is respected) but before nand_scan_tail() is called, we intercept and override mtd->oobsize and chip->ecc.layout based on the parsed nand_type.

[Our Questions]

Is this bootargs passing and Linux MTD driver override approach the safest and most recommended way to handle dual-sourcing NANDs with different OOB sizes?
Are there any known issues, GPMC hardware quirks, or MTD subsystem limitations in Kernel 3.14 that we should be careful about when overriding the OOB size and ECC layout dynamically like this?
We understand that using an ADC for board identification is not the standard approach, but given our strict pin constraints, is this overall handoff architecture (U-Boot ADC -> bootargs -> Linux MTD) solid enough for mass production?

Any architectural advice or validation would be highly appreciated.

Thank you, Ki-hwan Ahn

RE: AM3358: Dual-sourcing NAND (different OOB sizes) with a single source in uboot of oldversion

Hong Guan64 — Fri, 08 May 2026 21:28:04 GMT

Hi Hi Ki-hwan Ahn,

[quote userid="483002" url="~/support/processors-group/processors/f/processors-forum/1638118/am3358-dual-sourcing-nand-different-oob-sizes-with-a-single-source-in-uboot-of-oldversion/6316237"]

For the hardware, both NAND A (Micron) and NAND B (Macronix) share the exact same physical specifications, except for the total OOB size:

Page Size: 4096 bytes
BCH Scheme: BCH16 (26 bytes of ECC per 512-byte sector)
ECC Layout: Both chips use the identical CONFIG_SYS_NAND_ECCPOS mapping (from index 2 to 209). The ECC bytes and positions are exactly the same.
The only difference is the total OOB size (224 vs 256 bytes).

[/quote]

[quote userid="483002" url="~/support/processors-group/processors/f/processors-forum/1638118/am3358-dual-sourcing-nand-different-oob-sizes-with-a-single-source-in-uboot-of-oldversion/6337624"]Based on your advice to keep configurations consistent across all stages, I have implemented an ID-based branching logic to handle different NAND devices (128B vs. 224B OOB) in SPL/U-Boot and Kernel.[/quote]

What is one of NAND device OOB size? 256B or 128B?
Best,
-Hong

AM6442: How to generate U‑Boot ELF with .debug_frame / .eh_frame for AM6442 (TI SDK 10.00.07.04)?

masanobu.tsuchiya — Tue, 28 Apr 2026 02:38:53 GMT

Part Number: AM6442

Hello,

I’m trying to debug U‑Boot built for the AM6442 using a JTAG‑ICE (DTS Insight adviceXross). I’m using TI Processor SDK 10.00.07.04, which includes U‑Boot. I build U‑Boot and load the resulting binary into the debugger.

With the JTAG‑ICE attached to U‑Boot, I can set breakpoints and perform single‑step execution. However, the generated ELF binary does not include the debugging sections .debug_frame or .eh_frame, so next/step‑over and variable watch features do not work. According to the JTAG‑ICE vendor’s support team, the absence of .debug_frame/.eh_frame is indeed the root cause.

I have tried:

Setting each of the following Kconfig options to Yes:
- CONFIG_CC_OPTIMIZE_FOR_SIZE
- CONFIG_CC_OPTIMIZE_FOR_DEBUG
Adding the following GCC compile options:
- -fno-omit-frame-pointer
- -fno-asynchronous-unwind-tables

None of these changes helped. I have not altered anything else in the build scripts.

When I set the following in KBUILD_CFLAGS, there was a difference in whether .debug_frame is included:

KBUILD_CFLAGS += -Os -g -fno-omit-frame-pointer -fno-asynchronous-unwind-tables

Results:

R5 SPL (u-boot-spl): .debug_frame present, .eh_frame absent
A53 SPL (u-boot-spl): .debug_frame and .eh_frame both absent
A53 U‑Boot (u-boot): .debug_frame and .eh_frame both absent

Does anyone know how to configure U‑Boot’s build so that the generated ELF contains .debug_frame and/or .eh_frame? Any advice or examples would be greatly appreciated.

Note: In Japan, there is a long holiday from April 29 to May 6, so my responses may be delayed until after May 7. Thank you for your understanding.

RE: AM6442: How to generate U‑Boot ELF with .debug_frame / .eh_frame for AM6442 (TI SDK 10.00.07.04)?

Bin Liu — Fri, 08 May 2026 20:50:42 GMT

Hi Tsuchiya-san,

I believe I have done once in condition value modification in CCS for U-Boot debugging many years ago, and I didn't need special u-boot build, other than the debug symbols.

The AM64x EVM has an on board JTAG debugger, can you please try to see if can do condition value debugging on AM64x EVM with the on-board JTAG without modifying the U-Boot build system?