API solutions Forum - Recent Threads

AM263X-MCAL-SDK: Bitrate Calculation for CAN Communication On AM2634 Controller

Harika Badri — Tue, 07 Jul 2026 03:41:16 GMT

Part Number: AM263X-MCAL-SDK

Hi TI Team,

I am working on the AM2634 MCU using the MCU+ SDK MCAN driver.

I would like to understand the complete CAN bit rate calculation used by the AM2634 MCAN peripheral.

From the MCU+ SDK documentation, I understand that the nominal bit rate is calculated as:

Bit Rate = CAN Clock / (BRP × (1 + TSEG1 + TSEG2)),BUT i am not getting the exact value while using this formula.give the brief explanation on this.

Thank you for your support.

RE: AM263X-MCAL-SDK: Bitrate Calculation for CAN Communication On AM2634 Controller

Fleenor — Mon, 13 Jul 2026 15:31:41 GMT

Hi Harika,

Your formula is correct, but the reason you're not getting the expected value is almost certainly due to the "+1" offset between programmed register values and actual hardware-interpreted values.

The Key Issue: Register Values vs. Actual Values

The MCU+ SDK documentation explicitly states 1:

"Values selected in Sysconfig / the values set in structure are directly programmed in MCAN register bit fields. The actual interpretation by the hardware of this value is such that one more than the value programmed."

This means:

Actual BRP = programmed BRP + 1
Actual TSEG1 = programmed TSEG1 + 1
Actual TSEG2 = programmed TSEG2 + 1

The Complete Formula

The MCAN_NBTP register documentation confirms the bit time length is (NTSEG1 + NTSEG2 + 3) tq, where the "+3" accounts for Sync_Seg plus the two "+1" offsets on the programmed TSEG values 2.

Using programmed (register) values:

Bit Rate = fCAN / [(BRP_programmed + 1) × (TSEG1_programmed + TSEG2_programmed + 3)]

Using actual (functional) values:

Bit Rate = fCAN / [BRP_actual × (1 + TSEG1_actual + TSEG2_actual)]

Where the "1" represents the Sync_Seg 3.

Worked Example: 1 Mbps Nominal Bit Rate

Using the SDK's default parameters 1:

Parameter	Programmed Value	Actual Value (HW interprets)
CAN Clock	—	80 MHz
nomRatePrescalar	7	BRP = 8
nomTimeSeg1	5	TSEG1 = 6
nomTimeSeg2	2	TSEG2 = 3

Calculation:

Bit Rate = 80 MHz / [8 × (1 + 6 + 3)] = 80 MHz / [8 × 10] = 1 Mbps

Which SDK Driver Are You Using?

The offset handling differs depending on the SDK driver layer:

MCAN LLD driver (MCAN_BitTimingParams): programmed value nomRatePrescalar = 7 → actual BRP = 8 1
CANFD HLD driver (CANFD_MCANBitTimingParams): programmed value nomBrp = 4 → the documentation shows 80MHz / 4 / 20 = 1Mbps, using the programmed value directly in the formula 1

This inconsistency between driver layers is likely the source of your confusion. Verify which driver API you're using and whether the "+1" offset is applied by the driver before writing to registers, or if you must account for it yourself.

Summary

To get the correct bit rate, always confirm:

Your CAN functional clock frequency (typically 80 MHz on AM2634)
Whether your BRP/TSEG values are programmed values (need +1) or actual values (use directly)
That Sync_Seg (= 1 tq) is included in the total bit time

Follow up: What specific BRP, TSEG1, TSEG2 values and target bit rate are you configuring? Sharing those would allow us to pinpoint exactly where the mismatch occurs.

Best Regards,

Zackary Fleenor

RE: AM263X-MCAL-SDK: AM2634 MCAN Mailbox Support

Fleenor — Mon, 13 Jul 2026 15:08:34 GMT

Hi Harika,

Thank you for your patience, and apologies for the delayed response. Please see the answers to your questions below.

1. Mailbox support on AM2634 MCAN

The AM2634 MCAN peripheral is based on the Bosch M_CAN IP and does not support the traditional mailbox model. It uses a unified Message RAM architecture instead, with:

Up to 32 dedicated Tx Buffers (configurable as dedicated buffers, Tx FIFO, or Tx Queue)
Up to 64 dedicated Rx Buffers
2 configurable Rx FIFOs (up to 64 elements each)
A configurable Tx Event FIFO
Up to 128 filter elements

Since dedicated mailboxes aren't available, dedicated Tx Buffers are the recommended equivalent for periodic messaging:

Configure a fixed Tx Buffer per periodic message (ID + data length).
On each transmit interval, update the payload in Message RAM (
```
MCAN_writeMsgRam()
```
) and set the corresponding bit in TXBAR (Tx Buffer Add Request) to trigger transmission.
Monitor TXBRP (Tx Buffer Request Pending) for pending status and TXBTO (Transmission Occurred) to confirm completion. Note: TXBTO is only cleared on the next TXBAR request for that buffer — this is expected hardware behavior, not a bug.
Arbitration priority is based on Message ID (lowest ID = highest priority), same as FIFO/Queue mode.

Known limitation: If using Tx Queue mode,

MCAN_getTxFIFOQueStatus()

(TXFQS register) does not correctly report get-index/free-level in Queue mode. Use

MCAN_getTxBufReqPend()

(TXBRP) instead for status tracking.

2. eDMA Support

Yes — eDMA is supported, but with limitations:

Tx: Only 4 DMA channels per MCAN instance are supported via EDMA_XBAR). Channels 4–31 are not supported.
Rx: 7 Filter Event DMA channels are supported via EDMA_XBAR), useful for DMA-driven reception on Rx Buffer filter matches.
Debug DMA is not supported — use the Rx FIFO for debug/trace purposes instead.

There isn't currently a combined MCAN+eDMA reference example in the MCU+ SDK.

4. Recommendation for BMS Applications (Periodic Messages)

For your BMS use case, we recommend dedicated MCAN Tx Buffers over eDMA:

BMS payloads (cell voltage, temperature, SOC, faults) are small and fixed-size — DMA overhead isn't justified.
Dedicated Tx Buffers give precise per-message control and priority, ideal for cyclic transmission driven by a periodic timer/RTI interrupt calling
```
MCAN_writeMsgRam() + MCAN_txBufAddReq()
```
eDMA is better suited to high-throughput/bulk transfers (e.g., large CAN FD payloads or high message-rate logging) — not typically needed for standard periodic BMS telemetry.
Given the limited Tx DMA channel count and Queue-mode status-reporting quirks, the Tx Buffer + interrupt/polling approach is the more robust and commonly used pattern for this type of application.

Reference Documents

Resource	Link
AM263x TRM – MCAN chapter (13.4.1)	https://www.ti.com/lit/ug/spruj17i/spruj17i.pdf
AM64x/AM243x TRM – detailed MCAN register descriptions (same IP)	https://www.ti.com/lit/ug/spruim2d/spruim2d.pdf
AM2634 Datasheet	https://www.ti.com/lit/ds/sprsp74e/sprsp74e.pdf
MCU+ SDK Example Support Note	https://www.ti.com/lit/an/sprada3/sprada3.pdf
MCU+ SDK MCAN Loopback Example (Interrupt)	https://software-dl.ti.com/mcu-plus-sdk/esd/AM263X/latest/exports/docs/api_guide_am263x/EXAMPLES_DRIVERS_MCAN_LOOPBACK_INTERRUPT.html

Best Regards,

Zackary Fleenor

AM263X-MCAL-SDK: AM2634 MCAN Mailbox Support

Harika Badri — Wed, 01 Jul 2026 06:25:02 GMT

Part Number: AM263X-MCAL-SDK

Hi TI Team,

I am developing a BMS application on the AM2634 using the MCAN peripheral.

I have the following questions:

Does the AM2634 MCAN support the traditional Mailbox-based CAN communication, or does it only support Message RAM with TX Buffers, RX Buffers, and RX FIFOs?
If mailbox support is available:
- Is there any MCU+ SDK example.
- How are mailboxes configured for transmit and receive.
If mailbox support is not available:
- Is it recommended to use dedicated TX Buffers as mailboxes for periodic CAN messages?Does the MCAN peripheral support eDMA for CAN transmit and receive?
  - If yes, is there any SDK example or reference available.
For an automotive BMS application with periodic CAN messages, which approach does TI recommend.
- MCAN TX Buffers (mailbox-like implementation)
- MCAN with eDMA

Could you also provide any reference documents or examples explaining the recommended implementation.

Thank you.

AM2434: Question about I2C_transfer() timeout handling and EEPROM read not returning / AM2434

Shimodome Ryo — Thu, 09 Jul 2026 05:16:28 GMT

Part Number: AM2434

Hello,

We are experiencing an issue where an EEPROM read does not return, and while investigating the cause we would like to confirm a few points regarding the I2C driver behavior.

■ Environment

SDK: ind_comms_sdk_am243x_2025_00_00_08 and mcu_plus_sdk_11_01_00_19
Device: AM2434
I2C configuration (Sysconfig):
- Transfer Mode: Blocking
- Enable Interrupt: Enabled
- Bit Rate: 100 kHz, I2C Instance: I2C0, I2C Address: 0x50 (AT24C)

■ Symptom

When reading the EEPROM via EEPROM_AT24C_read(), the call sometimes does not return.
It does not happen every time; after rebooting, it reproduces roughly 1 out of 3 times.
If we insert a delay of about 100 us immediately before the read, the issue no longer reproduces.

■ What we have confirmed so far

In EEPROM_AT24C_read(), transaction->timeout is not set, so it keeps its initial value of SystemP_WAIT_FOREVER (-1). Because of this, when the issue occurs, the code appears to wait forever and the read never returns.
As a test, we set timeout to 100000. After this, the processing continues once the timeout period elapses (it no longer waits forever).
However, the read function does not return a timeout error and is treated as a successful completion, even though the EEPROM data is actually not read.
Note: we have not verified the initial value of transaction->status.

■ Questions

1. Regarding the return value behavior of I2C_transfer() With Transfer Mode = Blocking and Enable Interrupt = Enabled, we looked at I2C_transfer(). It appears that when SemaphoreP_pend() times out, retVal is first set to SystemP_TIMEOUT, but then in the interrupt-mode branch (the enableIntr == true path), retVal is overwritten by retVal = transaction->status;. In this case, unless transaction->status has been updated to I2C_STS_ERR_TIMEOUT, we suspect that a successful completion (SystemP_SUCCESS) is returned even though a timeout actually occurred. Is this the intended behavior? Could you please confirm whether this is expected behavior or a defect? Relevant location: I2C_transfer() in C:\ti\mcu_plus_sdk_am243x_11_01_00_19\source\drivers\i2c\v0\i2c_v0.c

2. Regarding the likely root cause of the timeout Could you advise on the possible reasons why a timeout (a wait that never completes) occurs during the read in the first place? Since it reproduces roughly 1 out of 3 times and disappears when we insert about a 100 us delay just before the read, we suspect that the EEPROM may not yet be ready (not fully powered up) right after power-on, i.e., a device start-up timing issue. Could you share your view on whether this assumption is reasonable, and any other possible causes?

3. Regarding an immediate workaround Separately from the root-cause fix in item 2, could you advise on any workaround or recommended action we can apply right now on our side? (Currently the 100 us delay before the read works around the issue, but we consider it only a temporary measure.)

Best regards,

RE: AM2434: Question about I2C_transfer() timeout handling and EEPROM read not returning / AM2434

Tushar Thakur — Fri, 10 Jul 2026 10:20:53 GMT

Hi,

This looks like a bug. As the default value of the transaction->status is I2C_STS_SUCCESS and it will always remain as is. The transaction->status value is changed in the transfer callback function of I2C when a I2C transfer is finished either successfully or with errors. For your case the timeout is coming from the semaphore and not from I2C driver, the I2C callback is never executed and the transaction->status always return success.

This needs to be fixed in the SDK by using the below code.

The code needs to be placed in the I2C_transfer function at i2c_v0.c file. The location should be else part of the polling mode condition check.

[quote userid="675123" url="~/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1662629/am2434-question-about-i2c_transfer-timeout-handling-and-eeprom-read-not-returning-am2434"]EEPROM may not yet be ready (not fully powered up) right after power-on,[/quote][quote userid="675123" url="~/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1662629/am2434-question-about-i2c_transfer-timeout-handling-and-eeprom-read-not-returning-am2434"] Regarding an immediate workaround[/quote]

The above could be the issue where EEPROM is not ready. In this case, please call I2C_Probe() API before going with I2C transactions.

Regards,

Tushar

AM6442: HS-SE tiboot3 Flash Read Issue

ZHEN BEI SIN — Tue, 07 Jul 2026 15:35:59 GMT

Part Number: AM6442

Issue: HS-SE tiboot3 Unable to Read Flash Data.

On the AM64x HS-FS platform, tiboot3 is able to successfully read NOR flash contents using tiboot3-am64x_sr2-hs-fs-evm.bin.
On the AM64x HS-SE platform, tiboot3 is unable to read NOR flash contents using tiboot3-am64x_sr2-hs-evm.bin.
From the API perspective, the flash read operation completes successfully; however, the returned buffer contains only 0x00 data.
Verification confirms that valid data exists in the flash region. The same region can be read correctly from U-Boot using the sf read command.
This behavior suggests that access to the Flash SubSystem (FSS) may be restricted on the HS-SE device, potentially due to firewall configuration or security settings.

Question:

Is there any method to check whether firewall configuration is affecting flash access, or any additional information about firewall settings that could impact flash reads on AM64x HS-SE in tiboot3?

RE: AM6442: HS-SE tiboot3 Flash Read Issue

Hong Guan64 — Thu, 09 Jul 2026 22:50:29 GMT

Hi Zhen,

By design, "arch/arm/mach-k3/am642_init.c" serves the SoC architecture-specific initialization sequence such as MMU and exception vectors, MMR unlocking, early debug hook etc...

The next stage loading is handled in "/common/spl/spl.c" along with "/common/spl/spl_spi.c" for ospi flash...

Best,
-Hong

AM6442: Combined Keyring (Signed and Encrypted) Import Failure

ZHEN BEI SIN — Tue, 07 Jul 2026 15:39:36 GMT

Part Number: AM6442

Issue : Combined Keyring (Signed and Encrypted) Import Failure

A combined keyring (asymmetric key + symmetric key) was generated and packaged as a signed-and-encrypted image. (keyring.bin)
The KEYRING import operation fails with return code -19.

Reference:

KEYRING Documentation: https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/keyring.html

TI E2E FAQ: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1484330/faq-sysfw-keyring-importing-support-on-am62x

Patch: 0001-calling-sysfw-keyring-import-API-in-r5-spl.patch: calling sysfw keyring import API in r5-spl

The example provided in keyring_init.h appears to cover only:

Single keyring images (Signed-only)

Question

Can TI provide a valid combined keyring (asymmetric key + symmetric key) signed by SMPK and encrypted by SMEK sample image for reference?
Is importing a combined keyring in signed-and-encrypted format supported on AM64x HS-SE devices?
Is there any known limitation or additional requirement when importing a signed-and-encrypted combined keyring on AM64x HS-SE devices?

RE: AM6442: Combined Keyring (Signed and Encrypted) Import Failure

Hong Guan64 — Thu, 09 Jul 2026 20:38:54 GMT

Hi Zhen,
Let me run some testing on my side, and get back to you.
Best,
-Hong

RE: AM2434: Question about I2C_transfer() timeout handling and EEPROM read not returning / AM2434

Anshu Madwesh — Thu, 09 Jul 2026 16:25:19 GMT

Hello,

This thread just got assigned to the correct engineer. Please allow sometime for a response.

RE: AM6442: Combined Keyring (Signed and Encrypted) Import Failure

ZHEN BEI SIN — Thu, 09 Jul 2026 00:41:14 GMT

As referenced in the TI Keyring documentation:
software-dl.ti.com/.../keyring.html

We have tested the following keyring import scenarios:
- Case 1: Combined Asymm + Symm → Not working
- Case 5: Independent Asymm + Independent Symm → Working

Based on the successful Case 5 test, we believe our TIFS version does support both asymmetric and symmetric keyring import.

The main issue appears to be that the keyring_gen_sign patch provided only generates keyrings containing the asymmetric key.
We do not currently have a method to generate a Combined Asymm + Symm keyring for Case 1 testing.

Could you please provide:
- A script/tool that can generate a valid Combined Asymm + Symm keyring (Case 1), or
- A sample valid Combined Asymm + Symm keyring blob that can be passed to TISCI_MSG_KEYRING_IMPORT for validation/testing?

This would help us determine whether the issue is related to the keyring generation process or the keyring import handling.

RE: AM6442: Combined Keyring (Signed and Encrypted) Import Failure

ZHEN BEI SIN — Thu, 09 Jul 2026 00:35:52 GMT

We are using

U-Boot 2026.01
ATF 2.14+
OPTEE 4.9.0+
TIFS Firmware v12.00.02

Component	Branch Info	Tag Info	Config Info
U-Boot	ti-u-boot-2026.01	12.00.00.07	Build Config
TF-A	master	v2.14+
OPTEE	master	4.9.0+	k3-am64x

From the boot log:
U-Boot SPL 2026.01 (Jul 08 2026 - 18:18:36 +0800)
SYSFW ABI: 4.0 (firmware rev 0x000c '12.0.2--v12.00.02 (Clever Cat)')

RE: AM6442: HS-SE tiboot3 Flash Read Issue

ZHEN BEI SIN — Thu, 09 Jul 2026 00:26:02 GMT

Just to confirm, have you tested invoking spl_flash_read() from board_init_f() in am642_init.c with the guard of (CONFIG_CPU_V7R)?
I'm interested to know whether OSPI NOR access is already functional at that point and if the flash data can be read successfully.

RE: AM2434: Inquiry: Frame-Loss Tolerance of PRU-ICSS EtherCAT Slave Sample in DC Sync Mode

Shimodome Ryo — Wed, 08 Jul 2026 22:38:58 GMT

Dear TI Support Team,

Thank you for your response.

The issue we are currently observing is that the EtherCAT master detects Lost Frames. In other words, EtherCAT frames are being lost somewhere along the communication path and are not successfully returning to the master.

The root cause has not yet been identified, but we currently suspect that temporary communication errors caused by electrical noise may be responsible.

Our objective is to maintain PDO communication while continuing to use DC synchronization, even when such temporary frame losses occur. For example, we would like the slave to remain operational and continue communication without immediately leaving the OP state when approximately 5 to 10 consecutive frames are lost.

Our current understanding is that, with the default TI sample implementation and configuration, PDO communication may not be able to continue when several consecutive frames are lost. Could you please confirm whether this understanding is correct?

In addition, if there is a recommended approach to increase tolerance against consecutive frame losses, we would greatly appreciate your guidance.

Best regards,

Ryo Shimodome

AM2434: Inquiry: Frame-Loss Tolerance of PRU-ICSS EtherCAT Slave Sample in DC Sync Mode

Shimodome Ryo — Tue, 07 Jul 2026 22:58:02 GMT

Part Number: AM2434

Dear TI Support Team,

We are developing an EtherCAT slave device using your Industrial Communications SDK, and would like your guidance on the recommended approach to improve frame-loss tolerance in DC Sync mode.

Environment

Target device: AM2434
Industrial Communications SDK version: 2025_00_00_08
Synchronization mode: DC Sync (SYNC0 enabled)
Cycle time: 500 µs

Our Goal

We would like the slave to remain in the OP state even when several process data frames (e.g., 5 to 10 frames) are lost consecutively, while continuing to use DC synchronization.

Questions

In DC Sync mode, with the default TI sample configuration, after how many consecutive lost process data frames does the slave transition from OP to SAFEOP? Also, which AL Status Code is reported in that case?
Could you advise the simplest way to increase frame-loss tolerance? We are considering the following options:
- (a) Modifying only the initial values of ESC registers
- (b) Modifying only the ESI XML / EEPROM settings
- (c) Modifying the TI sample source code
Are there any side effects we should be aware of when applying such changes — for example, DC clock drift, SYNC0 jitter, or impact on ETG Conformance Test compliance?

Thank you very much for your support. We look forward to your response.

Best regards,

RE: AM6442: Combined Keyring (Signed and Encrypted) Import Failure

Hong Guan64 — Wed, 08 Jul 2026 21:52:12 GMT

The symmetric keyring support was recently added in TIFS 12.0.2 (Linux SDK 12.0.0.7.4).
Which Linux SDK version was used in your testing?
Best,
-Hong

RE: AM6442: HS-SE tiboot3 Flash Read Issue

Hong Guan64 — Wed, 08 Jul 2026 16:36:15 GMT

In standard u-boot flow, r5-spl is loaded by ROM from ospi-nor, and runs from on-chip SRAM, and then r5-spl loading the next stage -- a53-spl from ospi-nor is handled in
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/common/spl/spl.c?h=12.00.00.07#n626

There's no special firewall configurations required to load/boot from flash device (i.e. ospi-nor) in standard u-boot flow on HS-SE.

Best,
-Hong

RE: AM2434: Inquiry: Frame-Loss Tolerance of PRU-ICSS EtherCAT Slave Sample in DC Sync Mode

Harsha Begihally Shanmukhaswamy — Wed, 08 Jul 2026 11:44:10 GMT

Hello Shimodome Ryo,

Please help us to understand the scenario where many process data frames are lost consecutively.

Kind Regards,

RE: AM6442: HS-SE tiboot3 Flash Read Issue

ZHEN BEI SIN — Wed, 08 Jul 2026 05:34:42 GMT

The spl_flash_read() is performed in board_init_f() (within am642_init.c) before k3_fix_rproc_clock() is called.

RE: AM6442: Combined Keyring (Signed and Encrypted) Import Failure

Meet Thakar — Wed, 08 Jul 2026 05:09:25 GMT

Hi,

I am assigning this thread to the concerned expert, please wait for their response.

Best Regards,
Meet.

RE: AM6442: HS-SE tiboot3 Flash Read Issue

Hong Guan64 — Tue, 07 Jul 2026 19:27:38 GMT

I'm attaching a flashing/booting log from OSPI-NOR on AM64x EVM (HS-SE) with AM64x Linux SDK 12.0.0.7.4, where the reported issue is not observed.
Best,
-Hong

e2e.ti.com/.../am64_5F00_12.0.0.7.4_5F00_ospi_5F00_flash_5F00_boot.log

RE: AM263X-MCAL-SDK: AM2634 MCAN Mailbox Support

Harika Badri — Sat, 04 Jul 2026 06:09:25 GMT

Hi TI Team,

I hope you're doing well.

I'm following up on my previous request. I understand from your earlier email that the expert was out of the office and expected to return late last week.

Could you please let me know if there are any updates regarding my request? I would appreciate any information when you have a chance.

Thank you for your time, and I look forward to hearing from you.

RE: TMS320F280025C: TMS320F280025C Flash API Source Code Request

Aswin P — Fri, 03 Jul 2026 11:07:21 GMT

Moving the ticket to closed state, please feel free to reopen

TMS320F280025C: TMS320F280025C Flash API Source Code Request

Hakan TOPUZ — Wed, 17 Jun 2026 07:13:19 GMT

Part Number: TMS320F280025C

I am a member of the Software Development Team. We are currently working with the TMS320F280025C microcontroller from the C2000 family and developing a custom bootloader. Therefore, we would like to request access to the source code of the Flash API related to this device.

Can you help us with this?

NOTE: We already have an NDA agreement in place.