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/1691165/lmg3526r030-synchronous-boost-implementation/6519518Fri, 23 Oct 2026 09:12:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c598451d-2783-48b7-81ff-75bfa56e912bMichele SantucciYes I'm using LMG3525R030Q because the board on which I'm working is a modified PMP22650E2(001) board. Anyway I didn't found int into the product list when creating the case so I took the more similar PN... I didnt found much docs about it and I think that it never reached the production stage. The main issue I'm having with this component is the lack of a body diode, the emulation works but with a pretty high voltage drop. This lead to some issue into BOOST bootstrap sequence coding. I solved it by simply driving high-side GaN statically on and low-side statically off until the bootstrap capacitor reach almost VIN and then I start PWM controller driving both leg mosfet with complementary duty cycles (deadband and so on). This work but since I'm not an expert and not really sure this's a 100% fault proof behaviour. I'm looking for specific firmware rather than schematics the board I'm working is already been built and it has a pretty standard schematics. The target output voltage is about 90V but right now I need to work with a low voltage setup (12-24V). BTW There's a pin-to-pin compatibile component with a more efficient body-diode emulation feature?https://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1690568/am6422-am6422-iic-rtc-linux-rtos/6519209Fri, 23 Oct 2026 03:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:90baa992-f1d3-4075-8f52-7a3ef6e4f00dWendyHello， Is there a solution to the question I raised above?https://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1691165/lmg3526r030-synchronous-boost-implementation/6518229Thu, 22 Oct 2026 08:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3b1e0580-8de2-4a7f-8605-82acc9573c33Adithya AnkamIt looks like I am having some difficulty pulling up a direct reference design or firmware example specifically for a synchronous boost implementation using the LMG3525 or LMG3526 series with a C2000 MCU. To help me narrow down the right information for you, could you clarify a few details? First, could you confirm which part number you are focusing on? You mentioned the LMG3525R030Q, but the subject line references the LMG3526R030; knowing the exact device will help ensure I look for the correct documentation. Are you looking for specific schematic examples or perhaps C2000 firmware code snippets for the control loop? Finally, what are your target output voltage and power requirements for this converter? Knowing your specific power level and target application can help me identify if there are similar TI reference designs or application notes that might serve as a good starting point for your development.https://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1691165/lmg3526r030-synchronous-boost-implementationTue, 20 Oct 2026 14:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b0fdf169-1302-417b-8207-7e5855a6ace1Michele SantucciPart Number: LMG3526R030 I'm using LMG3525R030Q and C2000 mcu to implement a synchronous boost converter. I'm having some problem in finding examples about this kind of convterer. Somehone can give me an hint?power deliveryLMG3526R030https://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1690212/am2434-am2434-follow-up-on-october-2026-industrial-communications-sdk-release-and-profinet-configuration-support/6515254Mon, 19 Oct 2026 23:32:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4c795ad2-5fed-4d85-9318-720fc47c74faLee Uie-TaeHello Kamil, Thank you for your update. I understand that the dynamic configuration feature has been postponed due to higher-priority stack upgrades. Could you please clarify the following points? When is the next standard release expected to be available? Will the next standard release include support for a 1-port PROFINET Device configuration through the dynamic configuration feature? This information would be very helpful for our development planning. Thank you for your continued support. Best regards, Uie-Tae Lee Autonics R&D Centerhttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1690568/am6422-am6422-iic-rtc-linux-rtos/6514879Mon, 19 Oct 2026 17:39:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:06c2da84-b71e-4e6d-97c4-39b8b167796aAnshu MadweshHello Wendy, The thread owner is out of office through Oct 20, please ping the thread if you do not get a response by Oct 23.https://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1690568/am6422-am6422-iic-rtc-linux-rtosMon, 19 Oct 2026 05:32:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d1715979-b5a0-474f-b073-0c23479be8e5WendyPart Number: AM6422 Hello, We have an idea like this and would like to see whether the current use scenario supports it. We use the AM6422. Under Linux, there is an RTC clock chip with an I2C interface. At power-on, the Linux system initially obtains the time from the RTC as the system time. After the Linux system starts the R5F0-0 real-time core, the R5F0-0 core reads the time from the RTC clock chip through the I2C interface and uses it as the core's own system time. This I2C interface is I2C1 in both cases. Later, during operation, R5F0-0 receives a standard time update to modify the RTC time and passes it to Linux through shared memory. Linux only implements writing the system's software clock and does not operate the RTC. Is this feasible under these circumstances? If there is a method, we hope you can give some suggestions.AM6422Wired networkinghttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1690212/am2434-am2434-follow-up-on-october-2026-industrial-communications-sdk-release-and-profinet-configuration-support/6514047Mon, 19 Oct 2026 02:57:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d13267f3-1f55-43cf-8cbc-9ceaddd51ab3Kamil AlkhouriHello Uie-Tae Lee, Unfortunately due to higher priority stack upgrades, we had to push the dynamic configuration feature until the next standard release. Please note that you always have the option to switch to custom/premium support model in which you get a library built especially for your company with your own config options. Kind regards, Kamilhttps://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1690212/am2434-am2434-follow-up-on-october-2026-industrial-communications-sdk-release-and-profinet-configuration-supportFri, 16 Oct 2026 07:08:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4bcc129b-0e44-4225-94d6-87afbe10ac2fLee Uie-TaePart Number: AM2434 Hello TI Support Team, I hope you are doing well. I previously contacted TI regarding PROFINET configuration limitations in the profinet_device_demo example for AM243x. In my previous inquiry, I was informed that the second Industrial Communications SDK release of 2026 was expected in October, and that many configuration options in pn_app_iod_cfg.h would become dynamically configurable. As we are now in mid-October, I would like to kindly ask for an update on the release schedule. In particular, could you please confirm the following? Is the new Industrial Communications SDK still expected to be released in October 2026? Will the new release support configuring PN_API_IOD_PDEV_NUM_OF_PORTS to 1 for single-port PROFINET devices? Will it also support configuring PN_API_IOD_NUM_OF_BYTES_PER_SUBSLOT to 1008 bytes? These capabilities are important for our ongoing PROFINET device development, so any updates on their availability would be greatly appreciated. For reference, here is my previous E2E discussion: https://e2e.ti.com/support/enterprise-automation-integration-group/enterprise-automation-integration/f/api-solutions-forum/1635696/am2434-questions-about-modifying-profinet_device_demo-on-am243x-lp Thank you for your continued support. Best regards, Uie-Tae Lee Autonics R&D CenterAM2434https://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.txt