Ask questions and find answers on connectivity ICs, focusing on protocols and I2C challenges on STM32 Nucleo boards and BlueNRG products.
Most recent activity
## Setup- Module: ST67W611M1 on X-NUCLEO-67W61M1- Host MCU: STM32C562RE (NUCLEO-C562RE), Zephyr 4.4.0 st67w611m1 driver (SPI netif path equivalent to W6X_Netif_output / ST67W6X_CLI_LWIP)- Module firmware: st67w611m_mission_t02_v2.0.106.bin (X-CUBE-ST67W61 v1.3.0)- Target network: enterprise SSID managed by FortiAP (WPA2)## ProblemUnder mission T02 the station associates successfully, but DHCP nevercompletes on our enterprise AP. Host-generated DHCP DISCOVER frames sentthrough the SPI network-STA path ARE visible on the LAN (captured by a PCon the same SSID) and are byte-comparable to DISCOVERs from workingclients — yet no OFFER is ever returned.Control tests:- T01 firmware, SAME module, SAME MAC, SAME SSID: internal DHCP client gets a lease within seconds (172.16.1.26).- T02 firmware on a phone hotspot: SAME host firmware completes DORA and binds 172.30.234.14.- Other clients (ESP32, Windows, Android) on the enterprise SSID: work.So the host stack and the T02 raw frame path are prov
Hi, I'm designing the STUSB4500QTR into a board that can run from USB-C, PoE or a DC jack. VDD is on VBUS as usual, and I'd like to run VSYS (pin 22) from our 3.3 V supply instead of grounding it, so the part can't hold the shared I2C bus low when the board is powered from PoE or the jack and USB-C isn't plugged in. DS12499 Rev 8 seems to say two different things:- Section 6.1.1 (p. 23): "there is an interest in using VDD pin only to supply the STUSB4500. First of all, this is mandatory to enable VBUS input voltage monitoring."- Table 22 (p. 29): the VTHUSB (VBUS disconnection threshold) and VTH0V (vSafe0V threshold) rows give the condition "VSYS = 3.0 to 5.5 V". The table header says "Unless otherwise specified: VDD = 5 V, TA = 25 °C", so I can't tell whether those rows were measured with VSYS only, or with VDD and VSYS both present. My questions:1. With VDD on VBUS and VSYS at 3.3 V both present, does the STUSB4500 still monitor VBUS (VBUS_VS_DISCH, detach detection, and discharge at
Could you please clarify whether the ST67W611M1 supports IEEE 802.11k/v/r and Wi-Fi roaming?If it does, could you please point me to the documentation that describes this support? I could not find any information about it in the datasheet, user manual, or ST Wiki.
Hello,We use two ST67W611M1 modules with STM32H563 hosts (bare-metal, SPI host interface at 10 MHz; reproduced at 20 and 40 MHz as well). Both modules run the NCP/AT build reporting AT version:1.0.0.1 (Mar 20 2026 09:32:19), sdk 2.0.106. One module is a SoftAP with a TCP server, the other is a station that opens one TCP client link to it.We have a reproducible failure on the station module that we would like you to look at, because its timing is too regular to be load-related.Symptom. Exactly 60 s after AT+CIPSTART succeeds (about 62 s after +CW:CONNECTED), the station module stops serving the SPI host: the next AT+CIPSEND=0,<n> never gets its > prompt, the RDY (data-ready) line stays low, and every subsequent AT command goes unanswered. There are no SPI framing errors on our side (header sync and length checks are clean up to the last frame). The Wi-Fi association and the DHCP lease survive — the AP module's AT+CWLIF still lists the station — so it is the SPI/AT service insid
i have a problem that has bugged me for a while now. Im using a stm32f4 microcontoler to read data from stpm34 microchip, but i can not establish a spi connection betwen them. With my logic analyzer i can see that i send mosi, the clock works and i believe the enable , chipselect and syn all work as they should. But on miso i get 0xffffffff or 0x808080 or 0xffcffeff... changing randomly. I dont know what is causing the problem. Im designing my own pcb but for now im powering the chip via arduino, and i am using stm32f4 discovery(arduino, becase the discovery has only 3v) gnd connected ofcoirse.Is it soldered wrong? Are the pads on the bottom not connected? Is the code not ok?.... any help will be welcomed and thank you in advance. Code: /* USER CODE BEGIN Header */ /** @file : main.c @brief : Main program body @attention STM32F4 + STPM34 SPI FIXED VERSION */ /* USER CODE END Header */ /* Includes ------------------------------------------------------------------*/ #include "main.h" /
Hello,I need to confirm the top marking for the IC ST232EBDR, on the datasheet there is an information that I think that it might be a little confusing.The datasheet indicates that the marking for ST202EBDR and ST232EBDR are both “ST202EB”. but I believe that the mark for ST232EBDR should be “ST232EB” at least it is that is written on the components that I bought.Can someone confirm this information?
Title: ST67W611M1A6BTR – Are BOOT and UART required when using the factory firmware without modification?Hello,I am designing a custom board using an STM32G474 as the host MCU and an ST67W611M1A6BTR as the Wi-Fi/Bluetooth network coprocessor.I intend to use the standard X-CUBE-ST67W61 software and communicate with the module through the SPI/AT interface. I do not intend to develop or debug custom firmware running inside the QCC743 SoC.After reviewing the ST67W611M1 datasheet, the B2413 reference schematic, AN6316, and the ST hardware setup wiki, I would like to clarify the required programming and debug connections.In the B2413 schematic, module pins 1 to 4 are shown as: Pin 1: JTMS Pin 2: JTCK Pin 3: BOOT_WW6 / JTDO Pin 4: JTDI However, in the ST67W611M1 datasheet, pins 1, 2, and 4 are marked as RESERVED and are required to be left unconnected for the A6B/A6U variants.My questions are as follows: Does every production ST67W611M1A6BTR module contain a usable mission firmware imag
Hi ST team,I am currently evaluating the ST67W611M1 Wi-Fi module in NCP mode and am facing an issue where the module does not appear to boot correctly after firmware programming.Hardware SetupModule: ST67W611M1 Supply Voltage: 3.3V CHIP_EN: Driven High (3.3V) BOOT pin: Connected to GND (Normal Boot Mode) SPI_CS: Held High Firmware: T01 mission firmware (st67w611m_mission_t01_v2.0.106.bin) Programming Method: Standalone firmware download using USB-to-TTL UART Host MCU: STEVAL STWINBX1 Development kit. (STM32U585)IssueAfter powering the module:CHIP_EN goes high correctly. BOOT remains low. Supply is stable at 3.3V. However, SPI_RDY never asserts high. I also do not see any activity on the SPI_RDY pin using an oscilloscope. Because SPI_RDY never goes high, the host cannot proceed with SPI communication.Verification Already PerformedSPI SignalsI have verified:SPI_CLK SPI_MOSI SPI_MISO SPI_CSSPI Configuration: Baud rate: 5 MBits/s and 2.5 MBits/s SPI Mode: 0 SPI Port: SPI2 on STM32U585 Rea
I am doing a academic research project working with PLC for 24 VAC HVAC application, CENELEC Band B. We have previously used TI AFE031 with F28379D with single-carrier FSK modulation targeting ~38k baud, but ran into bandwidth/aliasing and noise immunity bottlenecks near 150 kHz due to analog filter. To solve this issue, we are looking into OFDM. Would it be possible to make EVLKSTCOMET10-1 work for this application? I am a student and have little experience with communications, so apologies for any inconsistencies.
Hi, i am using the TCPP03-M20 for the first time. This device is stand alone. i have the device setup for 5V, which is all that is required. there is no power to the device initially when connected to the USB-C port. CC1c and CC2c pins are at around 1.65V. i do not see any voltage on Vbus. have attached the schematic section for this circuit. .If i apply 3.3v to Vcc_Vconn VBUS is still 0V. Any help appreciated. Mark
Recently, I started using the ST67W6 Wi-Fi module on a custom PCB with an STM32H723VET MCU to implement the HTTP Server application provided by ST.The application requires D-Cache to be enabled in order to operate correctly. However, as soon as I enable the D-Cache, my other peripherals that rely on DMA transfers, such as SDMMC and ADC, stop working correctly or fail completely. When I disable the D-Cache, all of these peripherals work normally again, but the HTTP Server application no longer functions, and I am unable to detect or connect to the Wi-Fi network.From what I have studied, I suspect that the issue is related to cache coherency between the CPU and DMA peripherals. My understanding is that I may need to configure the MPU to place DMA buffers in a non-cacheable memory region, or otherwise separate the memory used by the Wi-Fi module from the memory used by other DMA peripherals.However, I am still learning about MPU configuration, cache management, and memory mapping on STM32
Hi. We are encountering issues whilst the integration of st67w611m1a6u wifi chip to the Stm Nucleo-H753zi board(host) using SPI for communication and UART for debug logs. The Wi-Fi module firmware has been successfully loaded, but the network driver does not initialize on the host. As a result, the module cannot connect to a Wi-Fi network. We would be pleased to receive more clarity on this. The zip file of our project has been attached below and necessary files are also added.Pin connections between st67 wifi chip and nucleo board wifi IC nucleo board VDDIO 3.3v VDD33 3.3v GND GND CHIP_EN PE2 BOOT PE4 SPI_RDY PE3 SPI_CS PA4 SPI_CLK PA5 SPI_MISO PA6 SPI_MOSI PA7 UART_TX PD8 UART_RX PD9
Hello,We are using two ST67W611M1U modules (no on-module antenna; external 2 dBi dipole on MHF4) with an STM32H563ZG host, bare-metal, SPI host interface at 10 MHz (the same behaviour was reproduced at 20 and 40 MHz). AT firmware reports AT version:1.0.0.1 (Sep 4 2025 11:32:47), macsw 1.6.44; we are working from the Web AT Documentation v2.0.106.Topology: one module runs as SoftAP (AT+CWMODE=2, AT+CWSAP="…","…",1,3,4,0, AT+CIPMUX=1, AT+CIPSERVERMAXCONN=3, AT+CIPSERVER=1,5000,"TCP", AT+CIPRECVMODE=1), with two stations attached: a second ST67 module and a Windows PC. Steady-state traffic is about 36 kB/s outbound from the AP to the PC (AT+CIPSEND=<link>,1024, ~40 per second) plus about 10 kB/s inbound from the second module (passive receive, one AT+CIPRECVDATA of ~1 kB per 100 ms).We have collected several hundred boot/join cycles with full host-side logs and would appreciate answers or pointers on the following points.1. Static station IP is never applied to the interface. On the
Dear Supplier please provide drop-in replacement for below part EAU and target cost updated MPN# Mfg Name Description Current Unit Cost Annaul Consumption / EAU TPS71533DCKR TEXAS INSTRUMENTS INC. IC,LIN,CMOS,VR,SMD,SOT323,-40C TO +125C,ROHS,24V IN,3.3V OUT, LDO 0.045326667 6,25,149 TLV803RDBZR TEXAS INSTRUMENTS INC. IC,LIN,BIP,SVSUPR,SMD,SOT23-3 0.037631 1,13,349 TPS71533DCKR TEXAS INSTRUMENTS INC. IC,LIN,CMOS,VR,SMD,SOT323,-40C TO +125C,ROHS,24V IN,3.3V OUT, LDO 0.045326667 6,25,149 SN74ACT14PWR TEXAS INSTRUMENTS INC. IC,DIG,ACMOS,INV,SMD,14TSSOP 0.032573 4,79,488
I am currently evaluating the following ST platform for an IO-Link Device application: MCU Board: NUCLEO-G071RB IO-Link Expansion Board: X-NUCLEO-IOD02A1 IO-Link Transceiver: L6364Q Software Package: X-CUBE-IOD02 Development Environment: STM32CubeIDE The STM32G071RB example project included in X-CUBE-IOD02 builds and runs successfully.However, based on the documentation and the provided ministack library, the current software package appears to be based on IO-Link Interface and System Specification V1.1.2.For a new product development, I would like to use a newer or the latest available IO-Link Device Stack.I would appreciate any information on the following: Is there a newer version of X-CUBE-IOD02 that supports an IO-Link specification later than V1.1.2? Is there an updated version of the following ministack library that supports a newer or latest IO-Link specification? iol_device_ministack_stm32g0_wc32_ot.a If an updated library is available, where can the corresponding li
Hi, In the STULPI01BTBR datasheet I could find the timing spec only for SDR mode. I need to verify the DDR mode on our board and could not find the DDR mode timing spec. Can anyone please help to find the timing spec for ULPI interface DDR Mode. Regards,Shivakumar
Trying to update an existing design to use S2-LP , but I need table of values for 433 and 868Mhz operation. This needs to be one pcb layout that can be populated for either frequency. I have searched through the website but I can’t find a solution. I have found a eval board for FKI433V2 @ 433 Mhz, but no equivalent for 868Mhz. The other 868Mhz boards use a balun, so the layout would be quite different.I’m sure many people have gone down this route in the past.
I have built some prototype boards with the above “brand new” esim purchased from RS-UK. The first 2 out of 10 are coming up with “This ICCID has already been activated” on the 1Global portal.Interestingly the ICCID numbers are only 8 digits off being sequential.I will have 6 more in hand tomorrow but I’m worried these stand a good chance of being the same.Can ST do anything?1Global have already said the ICCID has been activated and then deactivated prior to my purchase and they cannot reactivate it! Which sounds a bit dodgy to me! Malicious BOT registering ICCID’s!!!!RS could probably get me some replacements, but likely from the same batch so could have the same problem!Any idea’s where I go from here? Or if I have possibly done anything wrong?
Hi,A bare-metal solution using the ST87M01-1301 modem (FW: v2.9.0) and a TCP connection to a remote server, with mbedTLS handling the TLS. We are experiencing an issue with one specific server (which is not under our management, making it very difficult to obtain server-side logs). The server does not respond to our TLS Client Hello at all. It does not send a TLS alert or close the connection; it simply leaves the socket open until our application timeout terminates the connection after 2 minutes.Here is what we have verified and tested so far:* The exact same Client Hello payload was copied and tested from a PC, and the server responds correctly with a Server Hello.* The exact same bare-metal implementation works with three other remote servers.* +CGCONTRDP reports an MTU of 1500. We have attempted to lower the "max_ip_frame_size" on the ST87M01 from 1600 down to 512 bytes, but it had no effect.* During PC test, if we transmit an invalid Client Hello, the server immediately terminates
Hi all, for minimum wake time I want to use UDP with DTLS.However, I wonder if it is OK to keep the Socket open for a longer time (not closing it ever)? Even during PSM?Opening the DTLS-Sockets costs 2 seconds (handshake) and energy, for a Raw-Socket it is almost zeroDTLS: Init->Wait->Use[000000]> AT#SOCKETCREATE=5,0,UDP,0,60,60,9,0,0[000116]< #SOCKETCREATE: 0[000118]< OK[000000]> AT#DTLSCONNECT=5,0,xxx.xxx.xxx.xxx,pppp[002011]< #TLS: 3,0x00A8,2048,0[002012]< OK[000000]> AT#IPSENDUDP=5,0,xxx.xxx.xxx.xxx,pppp…Raw[000011]< #SOCKETCREATE: 0[000012]< OK[000000]> AT#IPSENDUDP=5,0,xxx.xxx.xxx.xxx,pppp…Thanks for any helpful infos,Jo
I purchased the STEVAL-IKR002V1D recently to investigate low power 169Mhz operation. I noticed the schematic has TBD for values on components - No BOM and the schematic also does not reflect my board. I have an IC, U3 not even shown in the schematic. Could you please attached the latest schematic with values. Thank you!
Is there a demonstration project (outside of the CLI) for the target-wake-time feature?
Hi,I'm integrating a newly ordered X-NUCLEO-67W61M1 shield with a NUCLEO-H753ZI board, using the X-CUBE-ST67W61 package. I'm hitting an init failure and want to confirm the root cause before I flash anything, since I have some open questions about the flashing process itself.1. Original symptom — SPI header validation failure at bootRunning the ST67W6X CLI/Echo application, I consistently get:EXTI callbackInvalid magic 0x5501Invalid spi header from peer, magic 0x5501, len (0, 0x0), version 0, type 0 flags 0x0, rsvd 0x1sem_if_ready not receivedsem_if_ready not receivedCould not init Modem handler[ERROR] in W6X_Init APIW61 Init failedFailed to initialize ST67W6X Driver, 2This happens on every boot, identically, every time — not intermittent. Expected magic is 0x55AA; I consistently receive 0x5501 (high byte correct, low byte wrong).2. What I've verified so farTo isolate whether this is a wiring issue or a missing-firmware issue, I connected a USB-to-UART (Silicon Labs CP210x) adapter dir
Dear all, I have designed a custom board using the STM32H563ZIT6 as the host MCU and the ST67W611M1 as the NCP. As part of the initial bring-up, I am attempting to flash the ST67W611M1 using the QConn_Flash_Cmd-ubuntu tool in standalone mode. For this, I have connected a USB-to-TTL converter directly to the NCP UART interface. The BOOT and CHIP_EN pins of the ST67 are controlled by the host MCU, which toggles them in the required sequence to place the NCP into UART (flash) mode (see below code). I use the same sequence given in the NCP_Loader Example. if (flash) { LL_GPIO_SetOutputPin(BOOT_GPIO_Port, BOOT_Pin); } else { LL_GPIO_ResetOutputPin(BOOT_GPIO_Port, BOOT_Pin); } /* RESET NCP CHIP */ LL_GPIO_ResetOutputPin(CHIP_EN_GPIO_Port, CHIP_EN_Pin); HAL_Delay(100); LL_GPIO_SetOutputPin(CHIP_EN_GPIO_Port, CHIP_EN_Pin); if (flash) { /* CLEAR BOOT */ HAL_Delay(100); LL_GPIO_ResetOutputPin(BOOT_GPIO_Port, BOOT_Pin); } I verified the BOOT and CHIP_EN signals on an oscillosco
Hi I want to update firmware on my X-NUCLEO-67W61M1 board. I'm talking directly to the board using QconnFlash tool.I have pulled BOOT and ENABLE pins high as described in manual. Looks like communication is established, but later it fails on receiving the ack. Any idea while it fails?Log is here: F:\Projects\ST67W6X_Utilities\Binaries>QConn_Flash\QConn_Flash_Cmd.exe --port COM18 --config NCP_Binaries\mission_t01_flash_prog_cfg.ini --efuse=NCP_Binaries\efusedata.bin[23:06:09.042] - Serial port is COM18[23:06:09.042] - ==================================================[23:06:09.058] - FW get address from partiton file F:\Projects\ST67W6X_Utilities\Binaries\NCP_Binaries\./partition.bin[23:06:09.060] - Address=0x10000[23:06:09.060] - FW get size from partiton file F:\Projects\ST67W6X_Utilities\Binaries\NCP_Binaries\./partition.bin[23:06:09.062] - Size=1785856[23:06:09.069] - Program Start[23:06:09.069] - ========= eflash loader cmd arguments =========[23:06:09.097] - seri
ST Community highlights – April to June 2026
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.