https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1663439/cc1312r-power_idlefunc/6453652Tue, 18 Aug 2026 06:17:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1c4cc136-6b2f-40f5-a138-bb539b7334d9shingo sezakie2e.ti.com/.../PowerCC26X2_5F00_nortos.c I have figured out the logic behind the &quot;9 hours = ultra-low current consumption&quot; and &quot;approx. 3 hours = 1mA current draw&quot; behavior. When low-power operation is active, the function `void PowerCC26XX_standbyPolicy(void)`—found in the attached `PowerCC26X2_nortos.c` file—is presumably being called. It turns out that a situation was occurring where the condition on line 127— `if (time &gt; Power_getTransitionLatency(PowerCC26XX_STANDBY, Power_TOTAL))` —was not met, preventing the transition to `Power_sleep(PowerCC26XX_STANDBY);` on line 139. In this case, the system remained in &quot;Idle mode,&quot; which I believe accounts for the 1mA current draw. This state persisted for approximately 3 hours. During the 9-hour period, the condition was met, and `Power_sleep(PowerCC26XX_STANDBY);` was successfully called. So, I have a question: How should I modify the implementation to ensure the system always transitions to `Power_sleep(PowerCC26XX_STANDBY);`? Should I create a custom policy that operates independently of the scheduler, using `PowerCC26XX_standbyPolicy` as a reference?https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1663439/cc1312r-power_idlefunc/6453523Tue, 18 Aug 2026 04:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2f156c66-1d4c-4527-8b40-b45d2662d4e7SiriIf you want us to investigate this further, you need to provide an easier way for us to reproduce this issue. You suspect that the problem is related to the AON_RTC, meaning that you should try to make a VERY simple example were you simply use the AON_RTC to wake up the device at a given interval. You should try to decrease this interval to see if it can trigger it to fail sooner. Sirihttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1668150/cc1314r10-can-i-use-xds100v2-with-cc1314r10/6453011Mon, 17 Aug 2026 18:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4dd08548-2882-44c3-a4b3-80438d688a0ddesouzaHi, Just one remark: the XDS100v2 does not support cJTAG, only JTAG. To support cJTAG, you must have a XDS100v3. Regards, Rafaelhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1663439/cc1312r-power_idlefunc/6451689Sat, 15 Aug 2026 04:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:dd842f02-357e-40b7-a9eb-a30773b5adfdshingo sezakiThank you for your response. I have a few follow-up questions regarding the information you provided; could you please review them? This phenomenon has been verified on the CC1312 evaluation board; are there no plans to investigate reports of this nature? The issue begins to manifest approximately nine hours after power-on. Since it occurs simply by leaving the device running with an ammeter connected, I believe it would be prudent to investigate the root cause—what are your thoughts on this? Does this mean that the `aon_rtc` function should not be used directly by the application? I understand the design intends for the application to utilize it via the driver, but how exactly is it used through the driver? In this specific application, the requirement is for a function that triggers a wakeup if no external input interrupt occurs within a certain period. 1. Understood; however, the AonRtc function did not malfunction when 1 mA was generated. 2. This processing was included to verify whether an interrupt occurs in AonRtc, so in reality, it does not trigger. 3. I have not disabled the AON_RTC interrupt. Regarding the timing &quot;before entering sleep,&quot; do you mean I should enable it immediately before `Power_idleFunc` is called? Since this implies a risk of preventing proper power-down or causing the oscillator to keep running, are there any ways to investigate this? Is analyzing the `Power_sleep` function the only option? 4. No interrupt re-entry is occurring with the AonRTC; this has been confirmed via UART logs. As previously reported, the waveforms show that no external interrupts are occurring, while the AonRTC interrupt continues to operate at 5-minute intervals. Since the waveform sampling interval is 5 seconds, we are capturing very few samples during the Active state; however, the issue lies in the sustained 1 mA current draw (e.g., 2.93h, 2.89h), compared to 0.8 mA on the evaluation board.https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1665231/lp-xds110et-request-for-altium-design-files-lp-xds110et/6451255Fri, 14 Aug 2026 15:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a8cf34e3-9110-4cb4-9eeb-406a048d1928ZCHi, Please make a separate thread for new requests, it helps tracking and ensure threads handle single issues (so that other users find solutions easier). Regards, Zackhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1668458/cc1354p10-configuring-2-4-ghz-with-high-pa/6451253Fri, 14 Aug 2026 15:27:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:607d4de0-e7a5-4283-a8ce-a35ad82d64f2ZCHi, Are you seeing the lower Output Power when measuring the TI LaunchPad or only with your custom board? It looks like by default the +20 dBm, 2.4 GHz configuration settings are only available for BLE Mode. To confirm the HW side of things, please can you confirm the Output Power when selecting BLE Mode? Regards, Zackhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1673032/cc1354p10-request-for-ti-review-cc1354p106t0rgz-868-mhz-rf-schematic/6451018Fri, 14 Aug 2026 11:05:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:89064019-ac63-489c-9a9e-c72d0113df21ZCHi, Please submit all Sub-1 GHz design reviews using our portal, Sub-1 GHz Design Review Submission: https://www.ti.com/tool/SIMPLELINK-SUB1GHZ-DESIGN-REVIEWS This helps us track design reviews better and is more confidential for customers. Regards, Zackhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1673032/cc1354p10-request-for-ti-review-cc1354p106t0rgz-868-mhz-rf-schematicThu, 13 Aug 2026 11:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:29ab0411-e31a-4f6a-956b-8aec4701d608PurnaPart Number: CC1354P10 Dear TI Team, Greetings of the day! We have completed the RF schematic for the CC1354P106T0RGZ , with both 2.4 GHz and Sub-1 GHz RF interfaces connected . For the Sub-1 GHz section, we are targeting 868 MHz operation with 20 dBm output power . Currently, our 868 MHz RF design is implemented with an RF switch . We have attached the schematic for your review. Could you please review the complete RF section, particularly the 868 MHz matching network, RF switch interface, component values, and 20 dBm power-level implementation , and provide your comments or recommendations? Once we receive your feedback on the current design, we would also like to explore a switch-less 868 MHz implementation and seek your recommendation on the appropriate RF configuration. Your review and feedback will help us finalize the RF design and proceed with hardware development. Thank you for yo ur support. RF-CC1354P106T0RGZ.pdfCC1354P10SIMPLELINK-SUB1GHZ-DESIGN-REVIEWSWireless Infrastructurehttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1663439/cc1312r-power_idlefunc/6448376Wed, 12 Aug 2026 13:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2d1a5740-5219-48ee-8410-218c42a72946SiriI have not the opprtunity to let this run for 10s of hours to wait for it to possible fail and try to figure out what is going on. From you description everything works well when you are just using our different drivers, and the problems starts when you start using the aon_rtc, which we do not provide a driver for (only driverlib). Driverlig is not meant to be used by the application, but is a layer that is being used by the drivers, and then the application should use the drivers. I asked my friend claude if there might be any issues with your code with respect to using the aon_rtc, and here is what came back: &quot; Based on my analysis, I&#39;ve found several critical issues that could cause excessive current consumption after hours: Critical Issues: Interrupt handler registered multiple times (line 380) — Every time AonRtcSetInterval() is called, IntRegister() and IntEnable() are called again, but there&#39;s no corresponding IntUnregister() or IntDisable() before re-registering. After several hours of sleep/wake cycles, this could cause handler conflicts or stuck interrupts. Interrupt handler contains a busy loop with GPIO toggling (lines 263-275) — The AonRTC_InterruptHandler() has debug code that: - Toggles LED 10 times with delays (CPUdelay) - Disables/re-enables interrupts manually - This runs every time the RTC fires — blocks interrupts and wastes energy Missing interrupt cleanup in SleepSystem() — The SleepSystem() function closes peripherals but never disables the AON_RTC interrupt before sleeping. If the interrupt fires during sleep setup, it could prevent proper power-down or cause the oscillator to stay active. No protection against handler re-entry — The handler modifies g_aonRtcEventFlag without checking if it&#39;s already been called, and there&#39;s no debouncing logic &quot; Sirihttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1668458/cc1354p10-configuring-2-4-ghz-with-high-pa/6445479Mon, 10 Aug 2026 14:51:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:37fdcb02-4ccd-4b58-8e9c-3484e879f0aaAlex LinHi Zack, Thank you for your response! We were able to get the PA to transmit on our custom board with the proprietary protocol, however the output of our board, measured by a signal analyzer, is showing only +7 dBm, instead of the expected +20 dBm. We are using the 2450PC15A0044001E balun with the RF switch. We also removed the ESD diode from the antenna outline trace, per the guidance on the LP-EM-CC1354P10-6 schematic. Do you have any thoughts on what might be causing the ~13 dBm of loss that we&#39;re seeing? To answer your other questions: 1) We are using the latest version of SmartRF Studio 7 (2.32) 2) We are selecting Prop RF -- does this configuration only work with BLE Mode? 3) A photo of our test setup:https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1671568/cc1354p10-multi-channel-adcbuf-continuous-sampling-on-cc1354p10/6445416Mon, 10 Aug 2026 14:12:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8d57e71c-4f84-4481-9442-bcceab2ba935Arthur R☑️Hi Pedro, I will answer your questions. But first, I wonder if my solution outlined here: &quot; After looking more closely at the driver code, it seems like ADCBuf does not support multi-channel sampling, and wont allow you to use multiple-channels as such, as mentioned here, in non-supported functionality: https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_7_10_01_24/docs/drivers/doxygen/html/_a_d_c_buf_c_c26_x2_8h.html What you may want to use instead is the ADC.h, and especially its ADC_convertChain method: https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_7_10_01_24/docs/drivers/doxygen/html/_a_d_c_8h.html#a8150c6d87037c8d056ec74c61345d523 Unlike ADCBuf, You will not be able to take multiple samples in one function call, but you can at least take one per channel, relatively in-sync. &quot; could have been more efficient, memory wise. Indeed, with the convertChain, you could create a list that contains the same handle in a succession, and then switch to another one etc... Regards, Arthurhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1671784/cc1310-smartrf-studio-access/6445134Mon, 10 Aug 2026 09:28:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0985bcc4-c050-4374-af01-a3676eeb746cRGWHi, It is not required for anyone in the E2E community to approve this. Just fill in the details when selecting to download SmartRF studio and it should be an automatic approval. Regards, Richardhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1669950/cc1312r-how-to-optimize-sizes-of-data-tx-queue-on-15-4-stack-collector/6445030Mon, 10 Aug 2026 07:44:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c4a53397-af9a-4b97-a398-19526439dc2eDaniel Guarecuco AguiarHi Zhiyong, Is this happening to a very specific sensor and/or location or is it aleatory? This is a wire communication, has the device crashed? [quote userid=&quot;192864&quot; url=&quot;~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1669950/cc1312r-how-to-optimize-sizes-of-data-tx-queue-on-15-4-stack-collector/6444033&quot;]fails to deliver application layer heartbeat packets to external MCU.[/quote] Best regards, Danielhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1671784/cc1310-smartrf-studio-accessMon, 10 Aug 2026 06:35:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2df36fab-6b07-482e-8eca-7397eeaff3c8Daniel ChungDeleted postCC1310https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1665231/lp-xds110et-request-for-altium-design-files-lp-xds110et/6444791Mon, 10 Aug 2026 02:54:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:09d62c39-1002-405a-8151-1143bdb2dc33sankaran sHI ZACK, thank you for the LP -XDS110ET also please send that Altium file of LP-EM-CC2745R10-Q1 The current package only contains the Allegro, i requesting that Altium file of that board (e.g., .PrjPcb , .PcbDoc , .SchDoc )https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1663439/cc1312r-power_idlefunc/6444721Mon, 10 Aug 2026 00:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b362c452-591c-4ea6-a230-6cfe99b91c76shingo sezakiI am writing to report that the same phenomenon (1mA current draw) occurred on the evaluation board. I am attaching the waveforms and source code. Here are the details of the tests performed and their results: test1: Wake-up from standby using only the button → Remained in standby for 69 hours; no issues with current consumption. test2: test1 conditions + added Timer and RF transmission processing during active mode → Remained in standby for 69 hours; no issues with current consumption. test3: test2 conditions + added SPI and UART processing during active mode → Remained in standby for 69 hours; no issues with current consumption. test4: test3 conditions + added processing to wake up every 5 minutes using AON_RTC → Over the 69-hour period, the device cycled between 9 hours of standby and 3 hours of 0.8mA consumption (issue with current consumption observed). Based on these results, it appears that the use of AON_RTC triggered the 1mA current issue. I am providing the source code; could you please review the test setup on the evaluation board and the source code itself, and share your insights? e2e.ti.com/.../sleepTest4.ziphttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1663439/cc1312r-power_idlefunc/6444715Mon, 10 Aug 2026 00:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:feeec381-dbcd-4ff3-9278-8f7f3e90cc8fshingo sezaki...https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1671568/cc1354p10-multi-channel-adcbuf-continuous-sampling-on-cc1354p10Fri, 07 Aug 2026 16:20:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:12dab763-ef28-4562-9e20-0d24af95c597Pedro PauloPart Number: CC1354P10 Other Parts Discussed in Thread: SYSCONFIG Part : CC1354P10 SDK : SimpleLink CC13xx/CC26xx SDK 8.33.00.16 RTOS : FreeRTOS Board : LP-EM-CC1354P10-6 Tool : CCS Theia I&#39;m extending the stock `adcbufcontinuous` SDK example to support 4 independent ADC channels with per-channel processing threads . The extended version is working and tested on bench (see the attached CCS graph scre enshot for a 100Hz sinusoidal signal feed to all channels) , but I&#39;d like to validate the architecture with TI before building production firmware on top of it. I&#39;ll explain exactly what was changed from the original example, then ask two questions. What was changed from the original `adcBufContinuousSampling.c` The original TI example (attached as `adcBufContinuousSampling_original.c`) does the following: - 1 ADC channel (`CONFIG_ADCBUF_0_CHANNEL_0`) - `ADCBuf_RECURRENCE_MODE_CONTINUOUS` — the driver continuously fills ping-pong buffers via DMA and fires the callback indefinitely - Driver-managed ping-pong: both `sampleBuffer` and `sampleBufferTwo` are set, the driver alternates between them automatically - Conversion in the callback (HWI context): `ADCBuf_adjustRawValues` + `ADCBuf_convertAdjustedToMicroVolts` are called directly inside `adcBufCallback` - 1 POSIX mqueue carrying fully converted `uint32_t` microVolt buffers (message size = `sizeof(uint32_t) * 50` = 200 bytes per message) - 1 receiver in `mainThread` blocking on `mq_receive`, computing an average and printing to UART - Sampling frequency : 1000 Hz, buffer size: 50 samples My extended version (attached as `adcBufContinuousSampling.c`) changes six things : Change 1: 4 channels instead of 1 /* Original */ #define ADCSAMPLESIZE (50) /* single-channel buffers */ uint16_t sampleBufferOne[ADCSAMPLESIZE]; uint16_t sampleBufferTwo[ADCSAMPLESIZE]; /* Extended */ #define ADC_CHANNEL_COUNT (4) #define ADC_BUF_SIZE (1024) /* per-channel buffers — indexed [channel][sample] */ uint16_t adcSampleBufferOne[ADC_CHANNEL_COUNT][ADC_BUF_SIZE]; uint16_t adcSampleBufferTwo[ADC_CHANNEL_COUNT][ADC_BUF_SIZE]; uint32_t adcMicroVoltBuffer[ADC_CHANNEL_COUNT][ADC_BUF_SIZE]; All buffers become 2D arrays. Each channel gets its own 1024-sample double buffer. The SysConfig file was updated to define 4 ADCBuf channels on ADC0 with DMA_CH7. Change 2: `RECURRENCE_MODE_CONTINUOUS` → `RECURRENCE_MODE_ONE_SHOT ` /* Original */ adcBufParams.recurrenceMode = ADCBuf_RECURRENCE_MODE_CONTINUOUS; /* Extended */ adcBufParams.recurrenceMode = ADCBuf_RECURRENCE_MODE_ONE_SHOT; The original&#39;s `CONTINUOUS` mode locks onto a single channel forever. Since the hardware has one shared timer, there is no way to tell `CONTINUOUS` mode to cycle through multiple channels automatically. The solution: use `ONE_SHOT` so each conversion fills exactly one buffer for one channel, then the callback manually re-arms the next channel (see Change 4). Change 3: Driver ping-pong disabled → software-managed ping-pong /* Original */ continuousConversion.sampleBuffer = sampleBufferOne; continuousConversion.sampleBufferTwo = sampleBufferTwo; /* driver alternates */ /* Extended */ conversionSequence[i].sampleBuffer = adcSampleBufferOne[i]; conversionSequence[i].sampleBufferTwo = NULL; /* driver does NOT alternate */ Setting `sampleBufferTwo = NULL` tells the driver to only use `sampleBuffer`. The software callback manually swaps between `adcSampleBufferOne[ch]` and `adcSampleBufferTwo[ch]` after each completion (see Change 4). Change 4: Callback becomes a software round-robin state machine The original callback does conversion in-place and sends the result. The extended callback does three things: void adcBufCallback(ADCBuf_Handle handle, ADCBuf_Conversion *conversion, void *completedADCBuffer, uint32_t completedChannel, int_fast16_t status) { /* 1. Identify which logical channel just completed */ uintptr_t chIndex = (uintptr_t)conversion-&gt;arg; uint16_t *rawBufPtr = (uint16_t *)completedADCBuffer; /* 2. Send the raw pointer to the per-channel processing thread (minimal HWI work) */ mq_send(queueSend[chIndex], (const char *)&amp;rawBufPtr, sizeof(uint16_t *), 0); /* 3. Software ping-pong: swap the buffer for next time this channel runs */ conversionSequence[chIndex].sampleBuffer = (completedADCBuffer == adcSampleBufferOne[chIndex]) ? adcSampleBufferTwo[chIndex] : adcSampleBufferOne[chIndex]; /* 4. Advance to the next channel and re-arm */ uintptr_t nextCh = (chIndex + 1) % ADC_CHANNEL_COUNT; ADCBuf_convert(handle, &amp;conversionSequence[nextCh], 1); } Key architectural point: the `conversion-&gt;arg` field carries the logical channel index (set during setup as `(void *)i`). The callback uses this to route the completed buffer to the correct mqueue and to know which channel&#39;s ping-pong buffer to swap. After swapping, it advances modulo `ADC_CHANNEL_COUNT` and re-arms the ADC for the next channel. This creates a rotating sequence: ch0 → ch1 → ch2 → ch3 → ch0 → ch1 → ... running indefinitely. Change 5: Conversion moved out of HWI → per-channel processing threads The original does `ADCBuf_adjustRawValues` + `ADCBuf_convertAdjustedToMicroVolts` inside the HWI callback. The extended version moves all conversion work to dedicated POSIX threads: void *processingThreadFxn(void *arg0) { uintptr_t chIndex = (uintptr_t)arg0; uint16_t *receivedRawBuffer; while (1) { mq_receive(queueReceive[chIndex], (char *)&amp;receivedRawBuffer, sizeof(uint16_t *), NULL); ADCBuf_adjustRawValues(adcBufGlobal, receivedRawBuffer, ADC_BUF_SIZE, adcChannelMap[chIndex]); ADCBuf_convertAdjustedToMicroVolts(adcBufGlobal, adcChannelMap[chIndex], receivedRawBuffer, adcMicroVoltBuffer[chIndex], ADC_BUF_SIZE); buffersCompletedCounter[chIndex]++; } } 4 threads are created (one per channel), each blocking on its own mqueue. The HWI callback only sends a 4-byte pointer — minimal ISR overhead. Change 6: Per-channel mqueues carrying raw pointers instead of full buffers /* Original: one queue, each message is the full converted buffer (200 bytes) */ #define QUEUED_ADC_MESSAGE_SIZE (sizeof(uint32_t) * ADCSAMPLESIZE) /* 200 B */ mqd_t queueReceive, queueSend; /* Extended: N queues, each message is a pointer (4 bytes) */ #define QUEUED_ADC_MESSAGE_SIZE (sizeof(uint16_t *)) /* 4 B */ mqd_t queueReceive[ADC_CHANNEL_COUNT], queueSend[ADC_CHANNEL_COUNT]; Instead of copying the entire sample buffer into the queue (which the original does — 200 bytes per message!), the extended version sends only the pointer to the raw DMA buffer. This is safe because the software ping-pong swap (Change 4) guarantees the buffer won&#39;t be overwritten before the processing thread consumes it. Summary of changes Question A: Is this architecture okay? The extended implementation works correctly on bench at 50 kHz with 4 channels. However, I want to validate a few concerns: 1. Calling `ADCBuf_convert()` from inside the ADCBuf callback (HWI context) : Is this safe and supported? The driver documentation doesn&#39;t explicitly state whether `ADCBuf_convert` is re-entrant or callable from HWI context. It works in practice, but I want to confirm this is not relying on undefined behavior. 2. `ONE_SHOT` + `RETURN_MODE_CALLBACK` combination : The `ADCBuf.h` header comments (around line 414-416 in SDK 8.33) suggest that this combination may not be supported on all implementations. Can you confirm this is valid for the CC1354P10 ADCBuf driver specifically? 3. Thread count : The design spawns 4 threads (one per channel) plus mainThread. Each has a 1024-byte stack. Is there a practical upper limit on thread count for a CC1354P10 running the BLE stack concurrently? (In the production firmware, this ADC acquisition will coexist with BLE peripheral advertising and GATT notifications.) Is there a more sane/elegant way to implement this without spanning 4 different threads? 4. `mq_send` from HWI with `O_NONBLOCK` : If the queue is full (depth 4), `mq_send` silently fails and the buffer is lost. Is there a better pattern for ISR→thread handoff on this platform, or is this the standard approach? Question B: Per-channel arbitrary sampling frequency with DMA? The architecture above has a fundamental limitation: all 4 channels share the same sampling frequency because they share a single hardware GPTimer through the ADCBuf driver. The effective per-channel rate is `200kSa / ADC_CHANNEL_COUNT` due to the round-robin, but the base timer rate is uniform for all. I s there any way to configure ADCBuf to support different sampling frequencies per channel? For example, I need: - Channels 0-3 (vibration + audio): 40–80 kSa/s each - Channels 4-5 (temperature + humidity): 1 Sa/s each If ADCBuf fundamentally relies on a single timer, then I need a separate approach for the low-rate channels. I currently have a working and tested implementation that uses independent `Timer` + `ADC` (not ADCBuf) drivers — one timer per channel, each at its own frequency, with the timer callback doing a CPU-driven `ADC_convert`: /* Independent sampling frequencies defined in Hertz */ #define SAMPLING_FREQUENCY_CH0 (10 * 1000) #define SAMPLING_FREQUENCY_CH1 (9 * 1000) #define SAMPLING_FREQUENCY_CH2 (8 * 1000) #define SAMPLING_FREQUENCY_CH3 (7 * 1000) ADC_Handle adc[4]; Timer_Handle timer[4]; void timerCallback(Timer_Handle myHandle, int_fast16_t status) { uint16_t raw_temp = 0; uint8_t ch = 0; /* Resolve which timer fired */ for (uint8_t i = 0; i #include #include #include #include /* Driver Header files */ #include #include /* Driver configuration */ #include &quot;ti_drivers_config.h&quot; /* Number of different ADC channels used (pins maped by syscfg) */ #define ADC_CHANNEL_COUNT (4) /* Sampling frequency in Hz for all channels */ #define ADC_SAMPLE_FREQ (50 * 1000) /* ADC buffer size */ #define ADC_BUF_SIZE (1024) /* Maximum number of queue ADC conversions. * The ADC hardware FIFO can hold a maximum of 4 conversions. */ #define MAX_QUEUED_ADC_CONVERSIONS (4) /* Size (4 bytes) strictly required to hold a memory pointer in std. 32-bit archs */ #define QUEUED_ADC_MESSAGE_SIZE (sizeof(uint16_t *)) /* Stack size for each thread */ #define THREADSTACKSIZE (1024) /* Global buffers storing the ADC conversion results */ uint16_t adcSampleBufferOne[ADC_CHANNEL_COUNT][ADC_BUF_SIZE]; uint16_t adcSampleBufferTwo[ADC_CHANNEL_COUNT][ADC_BUF_SIZE]; uint32_t adcMicroVoltBuffer[ADC_CHANNEL_COUNT][ADC_BUF_SIZE]; uint8_t buffersCompletedCounter[ADC_CHANNEL_COUNT] = {0}; static mqd_t queueReceive[ADC_CHANNEL_COUNT]; static mqd_t queueSend[ADC_CHANNEL_COUNT]; static const uint32_t adcChannelMap[ADC_CHANNEL_COUNT] = { CONFIG_ADCBUF_0_CHANNEL_0, CONFIG_ADCBUF_0_CHANNEL_1, CONFIG_ADCBUF_0_CHANNEL_2, CONFIG_ADCBUF_0_CHANNEL_3 }; static Display_Handle display; static ADCBuf_Handle adcBufGlobal; static ADCBuf_Conversion conversionSequence[ADC_CHANNEL_COUNT]; /* * ======== adcBufCallback ======== */ void adcBufCallback(ADCBuf_Handle handle, ADCBuf_Conversion *conversion, void *completedADCBuffer, uint32_t completedChannel, int_fast16_t status) { /* Extract logical channel index passed via conversion-&gt;arg */ uintptr_t chIndex = (uintptr_t)conversion-&gt;arg; uint16_t *rawBufPtr = (uint16_t *)completedADCBuffer; /* Transmit the pointer of the RAW buffer to the processing thread (minimal Hwi overhead) */ mq_send(queueSend[chIndex], (const char *)&amp;rawBufPtr, QUEUED_ADC_MESSAGE_SIZE, 0); /* Software-driven ping-pong buffer swap for the current channel */ conversionSequence[chIndex].sampleBuffer = (completedADCBuffer == adcSampleBufferOne[chIndex]) ? adcSampleBufferTwo[chIndex] : adcSampleBufferOne[chIndex]; /* Advance the multiplexer state machine modulo ADC_CHANNEL_COUNT */ uintptr_t nextCh = (chIndex + 1) % ADC_CHANNEL_COUNT; /* Re-arm the ADC hardware for the subsequent channel */ ADCBuf_convert(handle, &amp;conversionSequence[nextCh], 1); } /* * ======== processingThreadFxn ======== */ void *processingThreadFxn(void *arg0) { uintptr_t chIndex = (uintptr_t)arg0; uint16_t *receivedRawBuffer; while (1) { if (mq_receive(queueReceive[chIndex], (char *)&amp;receivedRawBuffer, QUEUED_ADC_MESSAGE_SIZE, NULL) == -1) { Display_printf(display, 0, 0, &quot;Fatal Queue Error\n&quot;); while (1) {} } ADCBuf_adjustRawValues(adcBufGlobal, receivedRawBuffer, ADC_BUF_SIZE, adcChannelMap[chIndex]); ADCBuf_convertAdjustedToMicroVolts(adcBufGlobal, adcChannelMap[chIndex], receivedRawBuffer, adcMicroVoltBuffer[chIndex], ADC_BUF_SIZE); buffersCompletedCounter[chIndex]++; } return (NULL); } /* * ======== mainThread ======== */ void *mainThread(void *arg0) { pthread_t threads[ADC_CHANNEL_COUNT]; pthread_attr_t attrs; struct sched_param priParam; struct mq_attr mqAttr; int retc; uintptr_t i; ADCBuf_Params adcBufParams; ADCBuf_init(); Display_init(); display = Display_open(Display_Type_UART, NULL); if (display == NULL) { while (1) {} } checkDataSize(); Display_printf(display, 0, 0, &quot;Starting Multi-Threaded ADCBufContinuous Example\n&quot;); mqAttr.mq_flags = 0; mqAttr.mq_maxmsg = MAX_QUEUED_ADC_CONVERSIONS; mqAttr.mq_msgsize = QUEUED_ADC_MESSAGE_SIZE; mqAttr.mq_curmsgs = 0; for (i = 0; i &lt; ADC_CHANNEL_COUNT; i++) { char mqName[16]; snprintf(mqName, sizeof(mqName), &quot;/ADCBuf%u&quot;, (unsigned int)i); queueReceive[i] = mq_open(mqName, O_RDWR | O_CREAT, 0664, &amp;mqAttr); queueSend[i] = mq_open(mqName, O_RDWR | O_CREAT | O_NONBLOCK, 0664, &amp;mqAttr); if ((queueReceive[i] == (mqd_t)-1) || (queueSend[i] == (mqd_t)-1)) { while (1) { // Display_printf(display, 0, 0, &quot;Couldn&#39;t send or receive to a queue\n&quot;); } } } pthread_attr_init(&amp;attrs); retc = pthread_attr_setdetachstate(&amp;attrs, PTHREAD_CREATE_DETACHED); if (retc != 0) { while (1) {} } retc |= pthread_attr_setstacksize(&amp;attrs, THREADSTACKSIZE); if (retc != 0) { while (1) {} } priParam.sched_priority = 1; pthread_attr_setschedparam(&amp;attrs, &amp;priParam); for (i = 0; i &lt; ADC_CHANNEL_COUNT; i++) { retc = pthread_create(&amp;threads[i], &amp;attrs, processingThreadFxn, (void *)i); if (retc != 0) { while (1) {} } } ADCBuf_Params_init(&amp;adcBufParams); adcBufParams.callbackFxn = adcBufCallback; /* ONE_SHOT mode is mandatory for software-driven multi-channel sequencing */ adcBufParams.recurrenceMode = ADCBuf_RECURRENCE_MODE_ONE_SHOT; adcBufParams.returnMode = ADCBuf_RETURN_MODE_CALLBACK; adcBufParams.samplingFrequency = ADC_SAMPLE_FREQ; adcBufGlobal = ADCBuf_open(CONFIG_ADCBUF_0, &amp;adcBufParams); if (adcBufGlobal == NULL) { while (1) {} } /* Configure discrete parameters for the state machine sequence */ for (i = 0; i &lt; ADC_CHANNEL_COUNT; i++) { conversionSequence[i].arg = (void *)i; conversionSequence[i].adcChannel = adcChannelMap[i]; conversionSequence[i].sampleBuffer = adcSampleBufferOne[i]; conversionSequence[i].sampleBufferTwo = NULL; conversionSequence[i].samplesRequestedCount = ADC_BUF_SIZE; } /* Ignite the sequence by manually triggering the initial channel */ if (ADCBuf_convert(adcBufGlobal, &amp;conversionSequence[0], 1) != ADCBuf_STATUS_SUCCESS) { while (1) {} } return (NULL); }CC1354P10SYSCONFIGhttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1669950/cc1312r-how-to-optimize-sizes-of-data-tx-queue-on-15-4-stack-collector/6444033Fri, 07 Aug 2026 14:30:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8663c338-b0fa-4fe0-9dcb-44bd90f2e74dZhiyong Li (FT)Hi Daniel, A sort of related question: once in a few weeks, one of the sensor node would drop off network, either becomes orphaned, or fails to deliver application layer heartbeat packets to external MCU. This has been my observation over the years, and I also have stumbled upon posts stating similar findings on this forum. Should we just accept this as result of frequency hopping? For the time being, we just let external MCU to force sensor nodes to rejoin network if this happens. I would like hear from you guys if there is a way to completely prevent this from happening within sensor nodes. Best, Zhiyonghttps://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1670713/rf430f5155d-q1-programming-software-needed/6443991Fri, 07 Aug 2026 13:53:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:213cf6f4-8c1e-4080-a562-6f48e691696eUlrich DenkHello Hanbing, I will contact you direct per email. Best regards, Uli