https://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/en-USTelligent Community 13https://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1686420/tpsm33625fevm-ti-api-inventory-subscription-push-callback-blocked-by-ti-web-filter-403/6500118Fri, 02 Oct 2026 00:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2c2e6c24-f901-478b-96c8-821f438ffa77redtea tangThanks, Andrew. Yes, this is a general TI API inventory subscription callback delivery issue. I selected TPSM33625FEVM only because the required part selector did not offer TI-API. Could you please route this to the TI API team?https://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1686420/tpsm33625fevm-ti-api-inventory-subscription-push-callback-blocked-by-ti-web-filter-403/6500094Thu, 01 Oct 2026 23:46:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0c8039e2-1965-4147-909e-f6ae50819f89Andrew KutzlerHi red tea, It seemed to put you on the buck page. Let me see if this is the right team. Thanks, Andrewhttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1686420/tpsm33625fevm-ti-api-inventory-subscription-push-callback-blocked-by-ti-web-filter-403Thu, 01 Oct 2026 06:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1dab70a6-447b-4294-867f-169a6adeef10redtea tangPart Number: TPSM33625FEVM Other Parts Discussed in Thread: TI-API , Hello TI API Support, I am opening this new TI-API topic as advised in my previous E2E exchange. My TI Store API suite shows “Access approved” (29 September 2026). In the myTI Inventory Subscription API settings, the callback is configured as: API URL: https://mpnradar.com/api/ti/inventory/callback Data format: JSON Authentication: Basic (credentials are configured but are not included in this public post). When testing with POST transact.ti.com/.../test, webhook delivery fails. The test result includes an HTML “Restricted Site” page titled “Texas Instruments - Web Filter”, with /mwg-internal/ references, and reports a callback 403. Our application has not recorded an accepted test callback. From an external network, mpnradar.com resolves publicly, its HTTPS certificate validates, and TLS 1.2 connects successfully. Could you please confirm: 1. Is mpnradar.com blocked by TI’s outbound Web Filter or by a callback endpoint review policy? 2. Does this callback URL require explicit review, approval, or allowlisting? If so, what steps and expected review time apply? 3. If the callback hostname differs from the registered myTI customer domain, is that acceptable? 4. Can TI determine whether the test request reached our endpoint and which source IP or policy returned the 403? The support instructions requested “TI-API” as the part number, but the required part selector does not offer a TI-API entry. I selected TPSM33625FEVM (referenced in the related E2E discussion) only to satisfy the required selector. This is a general TI-API callback-delivery issue, not a device inventory question. Thank you.TPSM33625FEVMTI-APIhttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1684007/am263p2-clarification-on-efuse-register-access-in-hs-se-mode-am263px/6493695Thu, 24 Sep 2026 14:08:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7803ca18-2610-4780-a8c9-a09c85237f98FleenorHi Jayanthi, Thanks for double checking on this, correcting both my prior reply and your follow-up assumptions where needed: 1. "The JTAG lock eFuse would need to be programmed in HS-FS" — Incorrect, it's the opposite There is no documented requirement or mechanism tying the JTAG-disable eFuse write to the HS-FS state. In fact, the practical guidance from our support engineers is the reverse: the permanent JTAG-disable eFuse is written using the EFUSE driver in the TIFS SDK, on an HS-SE device . This means the device has already completed the HS-FS → HS-SE transition (customer keys + non-zero Customer Keys Revision/Count + PORZ) before this eFuse is ever touched — not before it, as your note suggests. 2. "Permanent loss of debug access for both host and HSM" — Correct Confirmed directly: this eFuse register is one-time writable, and writing it disables JTAG and the trace path permanently (same sticky, one-time class of register). There is no way to simulate, test, or recover from this — even in a development HS-SE environment, we confirmed there is no "undo" or dry-run option. It also disqualifies the device from RMA return to TI, since TI itself cannot re-enable debug access on a returned part once this eFuse is blown. This applies equally to host-core and HSM-core JTAG/trace access — both are gated by the same fuse. 3. "JTAG lock is one of the last eFuses, programmed after all keys" — Partially correct, but for a different reason than assumed Your conclusion is right, but not because the JTAG-disable eFuse is state-gated to follow key provisioning. It's an operational/sequencing best practice rather than a hardware-enforced dependency: The HS-FS → HS-SE transition (driven by Customer Keys Revision/Count + PORZ) is a separate, independent OTP operation from the JTAG-disable eFuse write. However, since debug access is invaluable during bring-up, key provisioning, and validation, it makes practical sense to defer the irreversible JTAG-disable eFuse write until last — after the device is already in HS-SE and all required keys/certificates are provisioned and validated. TI does not enforce this ordering in hardware, but it is the sequencing implicitly followed in TI's own guidance (the eFuse write is described as an HS-SE-time operation, not an HS-FS one) Recommended path (reiterating): For nearly all use cases, we recommend using the certificate-based JTAG lock/unlock mechanism (SBL certificate debug-disable extension, or the HSM debug-certificate service) rather than the irreversible eFuse write. This gives you the same default-locked-on-every-boot security posture in HS-SE, but remains reversible via your Root-of-Trust keys — avoiding the permanent, no-recovery, RMA-disqualifying risk of the direct eFuse route. Best Regards, Zackary Fleenorhttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1684007/am263p2-clarification-on-efuse-register-access-in-hs-se-mode-am263px/6493603Thu, 24 Sep 2026 12:21:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:db62e8a3-2d3a-48ae-b42e-3ddd13400de4Jayanthi GuruswamyHi Fleenor, Thank you very much for your timely reply. My understanding is that JTAG eFuses are accessible to Host and HSM core in the HS-FS state, whereas in the HS-SE state access is managed by the Security Manager. If so, the JTAG lock eFuse would need to be programmed in HS-FS, resulting in permanent loss of debug access for both the host and HSM. Is this correct? Furthermore, my assumption is that this eFuse is typically programmed only after all required keys have been provisioned. At that point, the device would transition to the HS-SE state, making the JTAG lock one of the last eFuses to be programmed, depending on the product's security requirements. Thanks in advance Regards Jayanthihttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1680966/am62a7-q1-dlinferer-run-call-blocks/6493347Thu, 24 Sep 2026 07:20:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ad77ef1e-f94a-46e5-a1a9-dcc0a85a85dfJay GoyalHi Junliang, I am not sure if the dl_inferer will parse the environment variable. You would have to use the debug_level config parameter: https://git.ti.com/cgit/edgeai/edgeai-dl-inferer/tree/dl_inferer/include/ti_dl_inferer_config.h?h=main#n185 Also, the logs you have shared should have more information from the C7x side. There should be details about the IPC Echo Test as well. Regards, Jayhttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1680966/am62a7-q1-dlinferer-run-call-blocks/6493182Thu, 24 Sep 2026 03:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7138f400-6c1b-48be-8ca4-575ee2398848junliang xiaHi Jay, Thanks for the suggestions. We followed them, but neither switch produces any TIDL output on our board. 1. debug_level — we set it to 2 , then 3 , and confirmed it reaches the process ( /proc/ /environ shows debug_level=2/3 ). However, the service journal contains no TIDL/debug output at all — no subgraph calls, no node/kernel logs, nothing from the TIDL EP. 2. TIDL_RT_DEBUG / TVM_RT_DEBUG — we set them to 2 and 1 , also confirmed in the process environment. But /tmp/tidl_trace/ stays empty (no tvm_c7x.trace ), and there is no trace output (not even Failed to map trace userdata object ). So in the 11.1.0 libraries shipped with our BSP, both the TIDL EP debug ( debug_level ) and the TIDL runtime trace ( TIDL_RT_DEBUG ) appear to be compiled out — the environment variables are read ( getenv ), but the debug/trace code produces no output. Could you confirm how to enable these in 11.1.0, or provide a debug/trace-enabled build of libtidl_onnxrt_EP.so and libvx_tidl_rt.so (and matching C7x firmware if needed)? Without the C7x-side trace we cannot see where the DSP hangs. Regards, Junliang e2e.ti.com/.../c7x_5F00_log.txthttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1680966/am62a7-q1-dlinferer-run-call-blocks/6492152Wed, 23 Sep 2026 08:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d2c094f9-4893-40f0-a7fd-2244701a503eJay GoyalHi Junliang, I don't see the logs attached. Maybe, they got missed. I would also suggest doing the following things: 1. Running the script in the background while the inference task is running. This would output remote core logs along with your application logs. 2. Try increasing the debug_level to 2 or 3 while running the model. Regards, Jayhttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1680966/am62a7-q1-dlinferer-run-call-blocks/6491815Wed, 23 Sep 2026 01:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f6a06304-b882-4f87-b610-015f9283f2d3junliang xiaHi Jay, Thanks for the details. Answers below. 1. SBL bootflow The evidence strongly points to SBL bootflow: The C7x remoteproc comes up in attached state (firmware already running before Linux). /lib/firmware/ contains no C7x/MCU firmware at all (only WiFi aic8800_sdio , codec wave521c_k3_codec_fw.bin , and regulatory DB). We are confirming with our BSP team, but it looks like SBL. 2. Important correction on dmesg / crash logs I need to clarify an earlier statement. Our board's dmesg is essentially empty — it contains only 4 lines, all from the very first moment of kernel boot: [ 0.000000] CPUs=4, Nodes=1 [ 0.000000] shr 0) [ 0.000000] 1984K init, 768K bss, 553580K reserved, 131072K cma-reserved) [ 0.000000] size: 98304 The Wind River BSP disables kernel printk (the dmesg buffer never fills up beyond these boot lines). So the absence of crash/recovery logs in dmesg does not mean the C7x did not abort — we simply cannot observe it via dmesg. This is consistent with your suspicion that the C7x is in some abort state. 3. On the de-init sequence This matches what we observed on our side. We already found and fixed an explicit memory leak in our own code: the input/output DlTensor objects returned by createBuffers() are allocated with new , and on de-init / re-init we were only calling clear() on the vector without delete -ing each DlTensor pointer, leaking both the objects and their data. This is fixed now, but the hang still reproduces — so the remaining issue is likely below our layer, i.e. in the TIOVX/TIDL de-init, as you suspected. We'll wait for your de-init sequence analysis and check our side against it. 4. Remote logger Confirmed — the SDK binary works when copied over; we ran it and captured both MCU1_0 and C7x_1 logs (attached c7x_log.txt ). The C7x is silent during inference though; its last output is at ~12.34 s (OpenVX kernel registration). Regards, Junlianghttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1680966/am62a7-q1-dlinferer-run-call-blocks/6491000Tue, 22 Sep 2026 13:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8f83f6ea-026e-456d-b15d-75a71528f326Jay GoyalHi Junliang, [quote userid="717315" url="~/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1680966/am62a7-q1-dlinferer-run-call-blocks/6490663"]How should I capture the C7x logs in this setup? Is there a standalone remote-logger binary I can copy over, or a way to build just the remote logger without the full vision_apps?[/quote] If you are not changing the memory map, you should be able to use the binary that we ship with our SDK. Just copy it to your rootfs. Otherwise, it should be a part of the vision_apps build that you are already doing. [quote userid="717315" url="~/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1680966/am62a7-q1-dlinferer-run-call-blocks/6490663"]When the hang happens, the C7x remoteproc is in the attached state, not running :[/quote] This concerns me a little because it might hint that the C7x is in some abort. I'll check the de-init sequence followed by the gst-apps and share that with you. It might be that you are missing something there and some TIOVX de-init is not handled correctly. I'll need a day to check this. [quote userid="717315" url="~/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1680966/am62a7-q1-dlinferer-run-call-blocks/6490663"]Linux is not the owner of this remote processor (the firmware was loaded before Linux boots), so we cannot reset it from Linux via stop/start[/quote] Are you using SBL bootflow? If yes, I'll try to find more information on that. Regards, Jayhttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1680966/am62a7-q1-dlinferer-run-call-blocks/6490663Tue, 22 Sep 2026 07:30:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1d4c0a09-d659-42e8-908d-d4263eb514e0junliang xiaHi Jay, Thanks for the suggestions. I tried the remoteproc reset and got an important result. When the hang happens, the C7x remoteproc is in the attached state, not running : # cat /sys/class/remoteproc/remoteproc0/state attached # cat /sys/class/remoteproc/remoteproc0/name 7e000000.dsp Because of this, echo "stop" > .../state fails with Invalid argument — Linux is not the owner of this remote processor (the firmware was loaded before Linux boots), so we cannot reset it from Linux via stop/start. Also, there is no crash/recovery indication on the Linux side: dmesg | grep -iE "remoteproc|dsp|rpmsg|c7x|crash|watchdog" → empty /sys/kernel/debug/remoteproc/remoteproc0/crash → empty So Linux sees no C7x crash, yet the A72 thread stays stuck in libvx_tidl_rt.so busy-waiting for the DSP. Given the C7x is in attached mode, could you let me know: How should I capture the C7x logs in this setup? Is there a standalone remote-logger binary I can copy over, or a way to build just the remote logger without the full vision_apps? Is there another way to reset/recover the attached C7x from Linux? Regards, Junliang e2e.ti.com/.../log.txthttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1683787/tpsm33625fevm-ti-inventory-subscription-push-api-callback-blocked-by-ti-web-filter-403/6489988Mon, 21 Sep 2026 18:37:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:73978da2-12cd-4ee7-ac1c-a9be399b4dd9Joshua AustriaHi Hui, You can reach out to the TI API team via E2E but by creating a new thread with "TI-API" as the part number. Please see here: https://api-portal.ti.com/support Thank you, Joshua Austriahttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1684007/am263p2-clarification-on-efuse-register-access-in-hs-se-mode-am263px/6489691Mon, 21 Sep 2026 14:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:94c7ea0e-c9f7-4d1c-b5b6-3708b16daeedFleenorHello Jayanthi, Thanks for the question. Here's our clarification on your understanding: JTAG eFuses specifically Your understanding is directionally correct, but the mechanism differs from a straightforward "eFuse revokes access" model: In HS-SE, the device's default state is JTAG locked. SecMgr_ isJTAGDisabled ( ) reads the EFUSE_JTAG_DISABLE_STATUS eFuse to reflect this. However, permanent JTAG disable via a direct OTP/eFuse write is explicitly not supported/recommended . The eFuse driver exists in the TIFS SDK, but TI's guidance advises against using it for JTAG lock. The recommended mechanism is the SBL certificate with the debug-disable extension : ROM enforces the JTAG-disabled state based on this signed certificate, not a blown eFuse bit. This is reversible — an authenticated user with access to the Root-of-Trust keys can re-sign/update the SBL certificate to unlock JTAG. If you do write the JTAG-disable eFuse directly, that is a true one-time, irreversible operation with no recovery path. So: JTAG lock in HS-SE is enforced, but the recommended production path is certificate-based ROM enforcement, not an outright "host-core access to the eFuse register is revoked" model. General statement (all eFuse registers) eFuses are OTP; each register/field behaves as WRITE_ONCE_ONLY — once programmed, it cannot be rewritten. Device-type and security-relevant eFuse fields are scanned into Security Manager registers within the HSM at POR. The HS-SE transition itself is a one-way, irreversible change, gated by non-zero "Customer Keys Revision" AND "Customer Keys Count" fields. Simply writing the SMPK/BMPK keys alone does not trigger the HS-FS → HS-SE transition — both fields must be non-zero, and a PORZ (power-on reset) is required afterward for the transition to take effect. Best Regards, Zackary Fleenorhttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1684007/am263p2-clarification-on-efuse-register-access-in-hs-se-mode-am263pxMon, 21 Sep 2026 12:16:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9ca79b7d-a96a-406c-a705-2406e52e4680Jayanthi GuruswamyPart Number: AM263P2 Hello TI Team, We are reviewing the security architecture for the AM263Px device and would like clarification regarding host-core access to eFuse/OTP registers after the device transitions to High Security - Security Enforced (HS-SE) mode. We are assuming that TI's foundational security architecture revokes host-core access to certian eFuse registers once the device transitions to HS-SE mode. Is our understanding correct on Jtag eFuses? or the above statement in general is wrong? Thanks in advance!Advanced Driver Assistance Systems (ADAS)AM263P2https://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1683787/tpsm33625fevm-ti-inventory-subscription-push-api-callback-blocked-by-ti-web-filter-403Sun, 20 Sep 2026 18:26:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:43775240-8822-4914-876c-f774fbd04ebeHui HePart Number: TPSM33625FEVM Other Parts Discussed in Thread: TI-API Hello TI API Team, This is a TI API support request, not a device-specific technical question. The part number field was populated only because the support form requires a valid TI product. Previous Customer Support case: CS3591219. We are integrating the TI Inventory Subscription Push API. Our callback endpoint is: https://push.chipharbo.com/api/ti/inventory-webhook The callback endpoint has already been verified from the public Internet: - DNS resolves correctly - HTTPS/TLS certificate is valid - Port 443 is publicly reachable - GET /health returns HTTP 200 - POST requests to the callback return HTTP 200 - Basic Authentication has been verified - The callback returns: {"status":"accepted"} Our TI Store API access is also working normally: - OAuth authentication succeeds - GET /v2/store/subscriptions/inventory succeeds with HTTP 200 - Active Inventory Subscriptions can be retrieved successfully However, when calling: POST transact.ti.com/.../test the API request itself returns HTTP 200, but the webhook delivery result is: status: failed responseCode: 403 The returned response contains: Restricted Site Texas Instruments - Web Filter /mwg-internal/ No webhook request reaches our server when this 403 occurs. We have also tested with different valid API credentials, and the same callback endpoint is still blocked by the TI Web Filter. Could the TI API Team please help confirm: 1. Whether push.chipharbo.com is currently blocked by the TI outbound Web Filter. 2. Whether the following callback endpoint requires TI-side review, approval, or allowlisting: https://push.chipharbo.com/api/ti/inventory-webhook 3. If the endpoint is blocked because of URL reputation, URL category, domain policy, or another TI security policy, what action is required for approval? 4. Whether callback endpoint approval is associated with: - the callback URL/domain, - the myTI company account, - or the API application / Client ID. 5. If the API Client ID / Client Secret is replaced or rotated in the future, whether the same approved callback endpoint can continue to be used without another review. Our main request is to have this callback endpoint approved for TI Inventory Subscription Push traffic. We can provide sanitized /inventory/test logs and exact test timestamps privately if required. Thank you.TPSM33625FEVMTI-APIData center & enterprise computinghttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1678274/am2434-regarding-the-ethercat-subdevice-the-processing-time-for-each-process-is-longer-than-expected/6488159Fri, 18 Sep 2026 11:41:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:aa5933b6-b24a-44f7-a1e9-d311443b7478?? ??Hello. Thank you for your reply. [quote userid="550875" url="~/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1678274/am2434-regarding-the-ethercat-subdevice-the-processing-time-for-each-process-is-longer-than-expected/6485282"]May I know which MainDevice is used for this test. Also, wireshark capture would help to analyze the traffic.[/quote] The main device is a TMDS64EVM board, and I'm testing it using acontis's EC-Master sample. Please wait a moment for the Wireshark results. [quote userid="550875" url="~/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1678274/am2434-regarding-the-ethercat-subdevice-the-processing-time-for-each-process-is-longer-than-expected/6485282"]Have you also tried at higher cycle time, say 500us or 1ms? [/quote] In the test, we increment the values ​​​​of specific RxPDO and TxPDO objects by 1 during each cycle to verify that the object values ​​​​are being updated correctly. When testing with the cycle time set to 500 µs, the system successfully transitioned to the Operational (Op) state, but a delay of approximately one cycle occurred in the test data. When testing with the cycle time set to 1 ms—a configuration expected to succeed—the transition to the Operational state failed (we will investigate this result further). Kind regards,https://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1680966/am62a7-q1-dlinferer-run-call-blocks/6488157Fri, 18 Sep 2026 11:39:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ff6b6d4c-d0da-497e-9725-fbd7dc5584f5Jay GoyalHi Junliang, Apologies for the delay in my response. There were a couple of high priority tasks requiring my attention. 1. For the C7x remote logger script, that gets the logs from a shared DDR region. remoteproc is not used for that. That script shouldn't have any dependencies and should be fairly easy to incorporate in your build. If you are using firmware builder, then it regenerates the remote logger as well. 2. It does look like I will need information on what is happening on C7x side. 3. I don't see any major issue with the pipeline. If the C7x is in an invalid state, trying to reset it from Linux might also help. You can try this: echo "stop" > /sys/class/remoteproc/remoteproc0/state echo "start" > /sys/class/remoteproc/remoteproc0/state Regards, Jayhttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1678274/am2434-regarding-the-ethercat-subdevice-the-processing-time-for-each-process-is-longer-than-expected/6485282Wed, 16 Sep 2026 11:54:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:11aec9ee-5f6f-4c4a-9dc1-5d6bda0307d7Aaron ThomasHi, [quote userid="615798" url="~/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1678274/am2434-regarding-the-ethercat-subdevice-the-processing-time-for-each-process-is-longer-than-expected/6482164"]However, when the main device requests an S→O transition from the sub-device, it fails to correctly verify the sub-device's response, resulting in a timeout.[/quote] May I know which MainDevice is used for this test. Also, wireshark capture would help to analyze the traffic. Have you also tried at higher cycle time, say 500us or 1ms? Regards, Aaronhttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1680688/tms320f2800156-q1-flashdriver/6483859Tue, 15 Sep 2026 13:35:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3272ff67-85a8-4c04-96a3-76c88b6b1461Arpit VarahmihirHi Youjun, Ready-made option: Simma Software (TI third-party partner) TI lists Simma Software as a third-party partner for C2000: - SIMMA-3P-UDS : a UDS client and server stack (ISO 14229, plus ISO 13400 over Ethernet and ISO 17987 for LIN) that runs over CAN, CAN-FD, LIN and Ethernet. It comes as full ANSI C source and is listed as ISO 26262 / ASIL B certified. Supported families listed: C2000, MSP432, Sitara and MSPM0. https://www.ti.com/tool/SIMMA-3P-UDS - SIMMA-3P-FLASHBOOTLOADER : a flash bootloader supporting UDS, J1939, CAN-FD, LIN and CANopen, with secure authentication and encryption. https://www.ti.com/tool/SIMMA-3P-FLASHBOOTLOADER TI doesn't ship a UDS (ISO 14229) stack or a ready-made "flashdriver.hex" for C2000. But what TI calls a flash kernel is the same idea as a UDS flashdriver: a separate image that is loaded into RAM over CAN, runs from RAM, and uses the Flash API to erase and program the application. So you can build your flashdriver from the pieces below if you don't want to use TI third party software 1. Flash API on F280015x is a library only (not in ROM) The F280013x/15x Flash API reference guide says: *"TMS320F280015x Flash API is NOT embedded into the Boot ROM of this device, it is wholly software."* You link `FAPI_F280015x_EABI_v2.00.10.lib` (C2000Ware > libraries > flash_api). That's why the flashdriver has to carry the library itself. Reference: https://www.ti.com/lit/pdf/spruj96 2. What has to run from RAM (the main reason for a separate flashdriver) Flash API functions, the user application functions that call the Flash API functions, and any Interrupt service routines (ISRs) must be executed from RAM, because there should not be any read/fetch access from the Flash bank when an erase/program operation is in progress. F280015x has a single flash bank (Bank0, 128 sectors), so the flashdriver, your CAN/UDS receive path, and every ISR that can fire during erase/program must all run from RAM (M0/M1, LS0/LS1). Your Bootloader must also not read its own flash (constants, lookup tables, vector table) while an erase/program is in progress. References : https://www.ti.com/lit/pdf/spruj96 , https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/951668/faq-faq-on-flash-api-usage-for-c2000-devices (Q3, Q16, Q18) 3. You can also refer to the DCAN flash kernel for F280015x C2000Ware > driverlib > f280015x > examples > flash > `flash_kernel_ex5_dcan_flash_kernel` , with the host tool `dcan_flash_programmer` (C2000Ware > utilities > flash_programmers). How it works: - The ROM CAN bootloader loads the kernel into RAM (GPIO24=1, GPIO32=0 selects CAN boot; default pins GPIO4 = CANTXA, GPIO5 = CANRXA). - The kernel then switches to 1 Mbps with 8-byte frames, erases the sectors it's configured for ( `Application_Flash_Banks` , `WE_Protection_A_Masks` , `WE_Protection_B_Masks` ), programs the application in 512-bit blocks, verifies it, and branches to the application entry point. For UDS, the difference is who loads the RAM image: your Bootloader (in flash) receives flashdriver over CAN with RequestDownload/TransferData into RAM, instead of the ROM loader. The erase/program/verify code in this kernel is the part you can reuse as your flashdriver. References: https://www.ti.com/lit/pdf/sprad51 (CAN Flash Programming of C2000 MCUs, Sections 4.1–4.1.2, 6.2) https://www.ti.com/lit/ug/sprujh3/sprujh3.pdf (Getting Started with Bootloading on C2000, Sections 3.2, 4.2.3) 4. Basic Flash API usage example for this device `driverlib\f280015x\examples\flash\flashapi_ex1_programming.c` Reference: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1193398/tms320f2800155-q1-issue-with-flash-api 5. Call sequence your flashdriver's erase/write functions should follow Refer Sections 2.3.1, 3.2, 4.2, 4.4 of TMS320F280015x Flash API Version 2.00.10.00 Reference Guide (Rev. A) 6. You can also refer to the following FAQ and threads: See FAQ Q36: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/951668/faq-faq-on-flash-api-usage-for-c2000-devices https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/999838/tms320f280025c-q1-developing-can-stack-j1939-uds-for-scania-man-on-tms320f28002x Regards, Arpithttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1678274/am2434-regarding-the-ethercat-subdevice-the-processing-time-for-each-process-is-longer-than-expected/6482164Mon, 14 Sep 2026 10:33:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5b910810-b6b4-4c17-a77f-fea1b997eeee?? ??Hello. Thank you for your reply. [quote userid="550875" url="~/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1678274/am2434-regarding-the-ethercat-subdevice-the-processing-time-for-each-process-is-longer-than-expected/6474768"]As per EtherCAT SubDevice: Datasheet , the maximum process data payload size is 1KB, with the cycle time as low as 50us:[/quote] Looking at this, the payload size and cycle time fall within the acceptable range, so it appears that Test Case 2—as we have envisioned it—is feasible. [quote userid="550875" url="~/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1678274/am2434-regarding-the-ethercat-subdevice-the-processing-time-for-each-process-is-longer-than-expected/6474768"]While we are at 1KB Process Data test case, can you provide more details on the state transition failure for 1KB PD? Are you seeing any value in AL Status Code (ESC Reg 0x0134)?[/quote] Checking the value of ESC register 0x0134 reveals that it returns sub-device 0x00. However, when the main device requests an S→O transition from the sub-device, it fails to correctly verify the sub-device's response, resulting in a timeout. The following is an excerpt of measurements taken using FreeRTOS hook functions to track the start and end of the task during the sub-device's S→O transition. Index Proc Task Name Time[us] Diff[us] 944 Task End Appl_LoopTask 32,068,148 　 945 Task Start Appl_LoopTask 32,068,156 8 946 Task End Appl_LoopTask 32,068,267 111 947 Task Start Appl_LoopTask 32,068,274 7 948 Task End Appl_LoopTask 32,068,315 41 949 Task Start BEPDItask 32,068,323 8 950 Task End BEPDItask 32,068,382 59 951 Task Start Appl_LoopTask 32,068,392 10 952 Task End Appl_LoopTask 32,068,496 104 953 Task Start Appl_LoopTask 32,068,504 8 954 Task End Appl_LoopTask 32,068,613 109 955 Task Start Appl_LoopTask 32,068,621 8 956 Task End Appl_LoopTask 32,068,737 116 957 Task Start Appl_LoopTask 32,068,744 7 958 Task End Appl_LoopTask 32,068,853 109 959 Task Start Appl_LoopTask 32,068,861 8 960 Task End Appl_LoopTask 32,068,970 109 961 Task Start Appl_LoopTask 32,068,978 8 962 Task End Appl_LoopTask 32,069,094 116 963 Task Start Appl_LoopTask 32,069,102 8 964 Task End Appl_LoopTask 32,069,211 109 965 Task Start Appl_LoopTask 32,069,219 8 966 Task End Appl_LoopTask 32,069,336 117 967 Task Start Appl_LoopTask 32,069,344 8 968 Task End Appl_LoopTask 32,069,384 40 969 Task Start BEPDItask 32,069,392 8 970 Task End BEPDItask 32,069,451 59 Looking at this, it takes approximately 1 ms for the BEPDItask to be called; this likely prevents the sub-device from processing data at the correct timing, causing the main-device to abort the transition to Op. [quote userid="550875" url="~/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1678274/am2434-regarding-the-ethercat-subdevice-the-processing-time-for-each-process-is-longer-than-expected/6474768"]I'll let the expert comment on this.[/quote] We are awaiting a response from an expert. Kind regards,