https://e2e.ti.com/support/wireless-connectivity/Products covered in this section are low power RF ICs and connectivity protocols such as ZigBee, RF4CE, Bluetooth & Bluetooth Low Energy, ANT, WLAN, SimpliciTI, ISO 15693/14443, and NFC.en-USTelligent Community 13https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1670028/cc2745r10-q1-how-to-choose-uart-interrupt-nvic-priority-relative-to-ble-stack-and-rtos-tasks/6444654Sun, 09 Aug 2026 03:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:740661d6-5b98-43c1-bf63-2b303ee72ac7Zhitao WuHi Leo 1. Prio 1/2/4 are used for the radio/systim. 2. We suggest other peripheral use a higher priority interrupt than those mentioned above 3. We would suggest configing by Syscfg and you can have the generated configs in the ti_drivers_config.c filehttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1671394/tusb1211-vendor-specific-register-access-on-usb-phy-from-stm32-ulpi-viewport/6444314Fri, 07 Aug 2026 18:26:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:720b675c-6175-4586-b875-367583e3abd7Brian Zhoufrom above table, to write extended register , TX CMD is 10101111 = AF following address. to read extended register , TX CMD is 11101111= EF following address. "payload" 101111b (= 0x2F) is not address "2F" Regards Brianhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1671394/tusb1211-vendor-specific-register-access-on-usb-phy-from-stm32-ulpi-viewport/6444268Fri, 07 Aug 2026 17:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4c10a10f-99dd-4a98-ba6c-76e94e4d0871Alex FryerHi Brian, Thanks for the quick reply. So I understand, what you're saying is that, to write to a register in the extended register space, I must do the following: 1. Call the write command with 6-bit "payload" 101111b (= 0x2F). 2. Send the 8-bit full address Is this not the same as a standard register write to register 0x2F? And when do I provide the payload I want to write to the extended register (0x80, in my case)? And I have the same question for a read, I gather it is effectively sending the read command to register 0x2F, followed by the address of the extended register (0x80), then where do I read the value of that register? Thanks very much for your help, Alexhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1671573/cc2651r3sipa-conflicting-l16-inductor-specifications-for-cc2651r3sipaFri, 07 Aug 2026 16:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:42a0c585-63eb-4c0f-8e50-5435e60fab8bBenjamin SchraederPart Number: CC2651R3SIPA I'm following the alternate PCB guidelines in this datasheet: SWRS278B https://www.ti.com/lit/ds/symlink/cc2651r3sipa.pdf What L16 inductor should I use for a 0.8mm board? There is conflicting information within the datasheet. Here are the sources: Section 10.2, Page 54, Figure 10-3: "2.7nH for 1.6mm board" "2.2nH for 0.8mm board" Section 10.2, Page 55, Table 10-3: "2.7nH for a 1.6mm board" "2.2nH for 0.8mm board" Section 10.4.4, Page 60, Figure 10-8: "2.2nH for 1.6mm board" "2.7nH for 0.8mm board" Additionally, will a 0.5nH difference on this inductor result in a meaningful difference in range? ThanksCC2651R3SIPAhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1671572/cc2652r7-gap_evt_adv_start-event-not-firedFri, 07 Aug 2026 16:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4f347a3d-4a34-4ed1-821c-3c1b4737314eChristian WehrenfennigPart Number: CC2652R7 I'm working on a project based on the "simple peripheral" example for the simplelink SDK. I would like to have some code executed at the start of a legacy advert and therefore I set my event mask as follows: GapAdv_setEventMask(advHandle, GAP_ADV_EVT_MASK_START); However, the callback I registered when creating the advert set GapAdv_create(callback, &advParams, &advHandle) is never called. I have verified/observed that the device is in fact advertising other events (e.g. GAP_EVT_ADV_END ) are triggered fine, if the corresponding mask-bit is set the problem does not occur with extended (non-legacy) adverts the start-evend does get triggered, if I set the mask-bits for all events ( GAP_ADV_EVT_MASK_ALL ). I have admittedly not gone through all the individual bits to determine if there is a single bit that enables the start-event Due to the behavior observed in this last point, I can work around the issue, but it feels like I'm relying on some either erroneous or undocumented behaviour. Can you clarify whether the behaviour I'm seeing is expected, i.e. there's an error in the docs or I misread them? Or is there something I may have missed? Thank you.CC2652R7Test & Measurementhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1671561/cc2340r5-verification-of-countermeasures-for-coin-cell-voltage-dips-and-brownout-resets-body/6444218Fri, 07 Aug 2026 16:44:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:444e0e49-226d-4a53-9ee6-9574e283b294Alex FagerHello Mike Wu, I will quickly comment on the SW question and I will let my HW apps team member handle the HW question. 2. BATMON: I enabled the BatteryMonitor sysconfig section that I was able to check the voltage. Does your BOD only occur when RF operations occur? [quote userid="402811" url="~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1671561/cc2340r5-verification-of-countermeasures-for-coin-cell-voltage-dips-and-brownout-resets-body"]dynamic TX power[/quote] You can currently "dynamically" change TX power, it just can't be while an active rf command is running see the below: RCL_Command_submit(rclHandle, &rclContTxCmdGenericTxTest); RCL_Command_pend(&rclContTxCmdGenericTxTest); rclContTxCmdGenericTxTest.txPower.dBm = 8; //this will set the output power to 8 dbm RCL_Command_submit(rclHandle, &rclContTxCmdGenericTxTest); RCL_Command_pend(&rclContTxCmdGenericTxTest); Thanks, Alex Fhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1671394/tusb1211-vendor-specific-register-access-on-usb-phy-from-stm32-ulpi-viewport/6444200Fri, 07 Aug 2026 16:26:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:433a8aa3-d00e-4e5b-9007-d9ddc458472bBrian ZhouHi Alex: All registers can be read and write by ULPI commands. ULPI define TX CMD sent by link and RX CMD sent by PHY. This table list TX CMD to send test package , extended register read and write. Registers with *SET and *CLR in TUSB1211 do not physically exist . Please use TUSB1210 since TUSB1211 was expired. Best Brianhttps://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'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'd like to validate the architecture with TI before building production firmware on top of it. I'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'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->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 *)&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, &conversionSequence[nextCh], 1); } Key architectural point: the `conversion->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'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 *)&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'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'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 "ti_drivers_config.h" /* 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->arg */ uintptr_t chIndex = (uintptr_t)conversion->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 *)&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, &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 *)&receivedRawBuffer, QUEUED_ADC_MESSAGE_SIZE, NULL) == -1) { Display_printf(display, 0, 0, "Fatal Queue Error\n"); 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, "Starting Multi-Threaded ADCBufContinuous Example\n"); 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 < ADC_CHANNEL_COUNT; i++) { char mqName[16]; snprintf(mqName, sizeof(mqName), "/ADCBuf%u", (unsigned int)i); queueReceive[i] = mq_open(mqName, O_RDWR | O_CREAT, 0664, &mqAttr); queueSend[i] = mq_open(mqName, O_RDWR | O_CREAT | O_NONBLOCK, 0664, &mqAttr); if ((queueReceive[i] == (mqd_t)-1) || (queueSend[i] == (mqd_t)-1)) { while (1) { // Display_printf(display, 0, 0, "Couldn't send or receive to a queue\n"); } } } pthread_attr_init(&attrs); retc = pthread_attr_setdetachstate(&attrs, PTHREAD_CREATE_DETACHED); if (retc != 0) { while (1) {} } retc |= pthread_attr_setstacksize(&attrs, THREADSTACKSIZE); if (retc != 0) { while (1) {} } priParam.sched_priority = 1; pthread_attr_setschedparam(&attrs, &priParam); for (i = 0; i < ADC_CHANNEL_COUNT; i++) { retc = pthread_create(&threads[i], &attrs, processingThreadFxn, (void *)i); if (retc != 0) { while (1) {} } } ADCBuf_Params_init(&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, &adcBufParams); if (adcBufGlobal == NULL) { while (1) {} } /* Configure discrete parameters for the state machine sequence */ for (i = 0; i < 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, &conversionSequence[0], 1) != ADCBuf_STATUS_SUCCESS) { while (1) {} } return (NULL); }CC1354P10SYSCONFIGhttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1671561/cc2340r5-verification-of-countermeasures-for-coin-cell-voltage-dips-and-brownout-resets-bodyFri, 07 Aug 2026 16:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:fb952a4d-f9b4-4128-ad02-ee0f377881edMike Wu1Part Number: CC2340R5 Other Parts Discussed in Thread: SYSCONFIG Hi Team, I am writing to seek TI's advice on behalf of my customer, who is developing a compact medical device using the CC2340R5 powered by a Coin Cell battery . During low-battery testing, the customer experienced brownout resets (BOD) triggered by voltage drops during: Sleep-to-Active transition (Inrush current peak). RF TX transmission (PA peak current draw under high battery ESR). We have reviewed Section 8.4 of the CC2340 Datasheet and several TI E2E threads regarding high-ESR coin-cell battery behaviors (including Errata PMU_01). Based on TI's guidelines, we plan to propose the following countermeasures to the customer, and we would like to get TI AE's evaluation and confirmation first: [Proposed Countermeasures for TI Validation] Hardware Considerations : Add a 22µF to 47µF (10V rating, low ESR X5R/X7R) ceramic bulk capacitor on VDDS to buffer the microsecond-level inrush current. Is this capacitance sufficient for CC2340R5's startup profile? Software Mitigation : Use the BATMON module to monitor battery voltage and dynamically reduce RF TX power (e.g., from +8 dBm down to 0 dBm / -3 dBm) when battery voltage drops below ~2.3V. [Questions for TI AE] Could you please confirm if our proposed HW/SW countermeasures are sound and complete before we present them to the customer? Are there any official TI App Notes or SDK code examples demonstrating BATMON-based dynamic TX power adjustments on CC2340? Thank you for your assistance! Best regards, Mike WuCC2340R5Medical & healthcareSYSCONFIGhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1660203/cc3220sf-launchxl-fatal-error-during-factory-reset/6444105Fri, 07 Aug 2026 15:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d812da3e-848b-45e6-8a72-a4b6c69819baBLiuHi Swapnil, Sorry for the delay. I had to get a particular tool to parse your logs but I realized it was blocked and I could not access it. It took a bit to deal with that so I'm finally back on track. Thanks.https://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/bluetooth-group/bluetooth/f/bluetooth-forum/1670488/cc2745r10-q1-guidance-required-for-aes-cmac-and-aes-ccm-on-cc2745r10/6444028Fri, 07 Aug 2026 14:26:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d9c13a0b-161d-455a-896f-9a3ade3fee28Blake SandersHello Balaji, Thank you for reaching out. Regarding the alignment issues that you are seeing when using AES-CMAC, would you be able to share the code you use to initialize the driver? There is a possibility that either the input, output, or key do get misaligned throughout the initialization process. Regarding AES-CCM, CryptoKeyPlaintextHSM_initKey() is the correct call to initialize the key since the CC2745R10-Q1 device uses an HSM. A minimal working example can be found at \examples\nortos\LP_EM_CC2745R10_Q1\drivers\aesccm, which also shows the correct SysConfig settings for the project. Please let me know if you would be able to share your initialization code and we would be happy to help diagnose the issue. We can use a channel not on E2E if you would prefer not to share your code here. Thanks, Blake Sandershttps://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, Ulihttps://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1668651/cc2745r10-q1-local-mode2-steps-results-in-sdk-v9-20-01-21/6443942Fri, 07 Aug 2026 13:20:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:690a19ad-6a8e-4109-b295-f7e117b94098Isaac LarsonHello Bruce, The team is working on a deliverable within the SDK to effectively parse and capture the PCT data. For now, we can provide the HCI byte format shown above. You can find more information about this format in Core Specification 6.3, Vol 4, Part E, 7.7.65.44 and 7.7.65.45. This will assist you in parsing the raw byte output. Thanks, Isaachttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1671485/cc3351mod-support-required-for-ble-tx-power-issue-with-default-cc3351mod-fcc-bin/6443919Fri, 07 Aug 2026 12:57:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:bce21f2f-4df3-4e58-890a-54bd6640ef86Dean RamsierWhat SDK release are you using? The latest release (1.0.2.17) has this interesting bug fix description in the release notes: Calibrator tool BLE LX: Under FCC regulatory domain, TX power is low I'm not TI and can't say what that means exactly, but I suggest updating to 1.0.2.17 before doing anything else. There are a lot of other interesting looking fixes noted there as well...https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1668522/cc3235modsf-crypto-aes-256-tag-verification/6443887Fri, 07 Aug 2026 12:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:54395f99-9616-437c-ae17-a45d6f4fc418Jonas KnüpperHi BLiu, thanks for your advice. Closing and reopening the crypto handle before each AES-GCM decryption helped. I should have mentioned that the encrypted file is actually a TI OTA update archive. During the OTA archive processing, the CryptoCC32XX driver is also used for the SHA-256/HMAC calculation of the OTA bundle. Therefore, I need to maintain a continuous HMAC context across the entire OTA processing, while at the same time starting a fresh AES-GCM context for each independently encrypted chunk. Do you have any recommendation on how to achieve this? Is it possible to reset only the GCM context without affecting the HMAC context, or is there another recommended approach?https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1671485/cc3351mod-support-required-for-ble-tx-power-issue-with-default-cc3351mod-fcc-binFri, 07 Aug 2026 12:07:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:be9c79f0-f912-4b3a-8524-6b6f4596259dFenil LadaniPart Number: CC3351MOD Hi, During FCC pre-compliance testing with CC3351MOD used in our design for BLE, we are observing an unexpected TX power drop for the 125 kbps, 500 kbps, and 1 Mbps PHY modes while using the default CC3351MOD cc33xx-conf-fcc.bin file. For these PHY modes, the TX power is configured to 7 dBm in the FCC BIN. However, when we apply the commands (as below) and measure the conducted output power, we observe the TX power to be close to 0 dBm. In contrast, for the 2 Mbps PHY mode, the measured TX power matches the configured value, and no issue is observed. Additionally, for the 125 kbps, 500 kbps, and 1 Mbps PHY modes, the measured TX power appears to be inconsistent. Sometimes we measure 5-7 dBm and some time TX power is approximately 0 dBm. To isolate the issue, we repeated the same test using the cc33xx-conf-unlimited.bin file. With the unlimited BIN, the measured TX power is as expected. The TX power drop is observed only with the default cc33xx-conf-fcc.bin . The commands we are using are shown below. Initial setup: cd /usr/share/cc33xx sh set_power_mode.sh 0 calibrator wlan0 cc33xx_plt ble_plt calibrator wlan0 plt power_mode on calibrator wlan0 cc33xx_plt tune_channel 8 0 3 calibrator wlan0 cc33xx_plt set_manual_calib -tx 1 -rx 1 calibrator wlan0 cc33xx_plt tune_channel 1 0 0 bluetoothctl power on calibrator wlan0 plt power_mode off ifconfig wlan0 down To change the channel, PHY mode, and TX power: hcitool cmd 08 1F hcitool cmd 3f 11 hcitool cmd 08 34 0 FF 0 03 hcitool cmd 08 34 FF 0 Could you please review this issue and confirm whether we are using the correct commands and test procedure? If there are any additional configuration steps or recommended commands required when using the FCC BIN, please let us know. Attached the test results with fcc bin and unlimited bin. 125kbps_CH39_7dbm - fcc bin.pdf 125kbps_CH39_20dbm-unlimited bin.pdf We would appreciate your guidance in resolving this issue. Best regards, FenilConnected peripherals & printersCC3351MODhttps://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1671474/cc3351mod-verification-of-dut-fcc-bin-file-for-final-device-certificationFri, 07 Aug 2026 11:12:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:46aab1b8-7b58-43f0-88f9-d645d3e2a831Fenil LadaniPart Number: CC3351MOD Hi, We have completed the FCC pre-compliance testing (conducted band-edge and radiated spurious emission) for the CC3351MOD used in our design using the default cc33xx-conf-fcc.bin file. During testing, we observed failures in the following areas: 2.4 GHz: Radiated spurious emission 5 GHz: Conducted band-edge Based on the pre-compliance results, we reduced the transmit power for the affected channels and modes until the DUT met the FCC limits. For your reference, we have attached an Excel sheet containing: The default TX power configured in the FCC BIN. (column : fcc bin Power (dBm)) The TX power at which our DUT passed the pre-compliance tests. (column : Passed Power (dBm) during precompliance) The channels and modes where the TX power was reduced are highlighted in yellow. Based on these results, we have updated the default cc33xx-conf-fcc.bin file with the reduced TX power values and generated a modified FCC BIN: Modified FCC BIN: cc33xx-conf-fcc-dut.bin Could you please review and verify the cc33xx-conf-fcc-dut.bin file? We would appreciate your confirmation that this BIN file is suitable for use during the final FCC certification of our device. Attached modified fcc bin file and excel sheet : cc33xx-conf-fcc-dut.zip If you have any recommendations or require additional information, please let us know. Regards, FenilConnected peripherals & printersCC3351MODhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1671394/tusb1211-vendor-specific-register-access-on-usb-phy-from-stm32-ulpi-viewportFri, 07 Aug 2026 07:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:52fdc554-3dcf-4aec-89ab-22a67a85fc85Alex FryerPart Number: TUSB1211 Other Parts Discussed in Thread: TUSB1210 Hi, I'm attempting to access (read/write) registers on the TUSB1211 USB PHY via the ULPI viewport interface on an STM32. I can successfully read ID registers and write to / read from the scratch register using this interface, but appear unable to access the "extended register space" (addresses > 0x3F), particularly the vendor_specific registers, which I want to access to set eye diagram tuning parameters. What is the process for accessing the vendor specific registers? Clearly they can't be accessed directly? What is the purpose of register 0x2F, labelled ACCESS_EXT_REG_SET, but with no accompanying documentation in the datasheet? Thanks, AlexTUSB1211TUSB1210https://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/6443570Fri, 07 Aug 2026 07:18:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:134172d8-4222-4b34-891b-79bbef78b6b1Daniel Guarecuco AguiarHi Zhiyong, Good to hear. Let us know if there is anything else. Best regards, Daniel