The STM32L073RZ provides a full speed USB device controller, but the
Nucleo-L073RZ board support did not enable it and no configuration
exercised it.
Add the pieces required to run USB device mode on this board:
- Add the USB device pin definitions to the STM32L0 pin map.
- Provide board level pull-up control using the embedded DP pull-up in
USB_BCDR, and register the CDC/ACM class at boot when it is selected.
- Add a usb-cdc configuration that presents an NSH console on USART2 and
a CDC/ACM serial device on USB.
The 48MHz clock for the controller is supplied by HSI48 trimmed from the
USB start of frame packet, which is the crystal-less USB configuration
already described by this board's board.h.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
Return unsupported-format and mapping errors to board bring-up
instead of panicking, so a serial console can remain usable when
no suitable framebuffer exists.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: OpenAI Codex:gpt-5
x86_64_uservaddr() depends on the address-environment layout and
is only consumed by the kernel address-environment path.
Guard it with CONFIG_ARCH_ADDRENV so MM_PGALLOC can also be
enabled in flat builds.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: OpenAI Codex:gpt-5
The stm32h5 SPI driver had some issues when both
non-DMA and DMA instances were present at the same time.
Modify the driver to allow them to correctly coexist.
Signed-off-by: Liam Howatt <liamhowatt@geotab.com>
The stm32h5 SPI driver is based on stm32h7's.
It does not build when DMA is enabled. Port
stm32h5 DMA to the stm32h5 SPI driver using the
H5-specific DMA API. Use equivalents.
Use correct cache line definition.
Signed-off-by: Liam Howatt <liamhowatt@geotab.com>
Add board spi1 initialization and generic spi
chardev registration for nucleo-h563zi.
Specify the SPI1 clock source and frequency on
this board for the spi driver.
Define the SPI pins for this board. The SPI_A
CN7 header pins were used.
Include stm32_spi.h in stm32h5/stm32.h.
Signed-off-by: Liam Howatt <liamhowatt@geotab.com>
Decode the saved setup request fields after processing the optional OUT data phase. This ensures the fields are initialized when the EP0 handler is entered again to complete an OUT control transfer.
This also fixes Clang builds that treat the resulting maybe-uninitialized diagnostics as errors.
Assisted-by: Codex:GPT-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
Add the correct pin map definitions for MCO1 and MCO2, and add the clock
division option to stm32_mco{1,2}config with a macro. This matches the
STM32H7 implementation.
Signed-off-by: Darryl Ring <darryl@bluerobotics.com>
The STM32F072RB provides a full speed USB device controller, but the
Nucleo-F072RB board support did not enable it and no configuration
exercised it.
Add the pieces required to run USB device mode on this board:
- Select HSI48 as the 48MHz source and use the USB start of frame packet
as the CRS synchronisation event, which is the intended crystal-less
USB configuration for this part.
- Add the USB device pin definitions to the STM32F07x pin map.
- Provide board level pull-up control and register the CDC/ACM class at
boot when it is selected.
- Add a usb-cdc-uart configuration that presents an NSH console on
USART2 and a CDC/ACM serial device on USB.
- Enable the USB device pins in the nsh configuration so the two
configurations stay consistent.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
vrefint_enable() sets SYSCFG_CFGR3_ENBUFVREFINTHSI48 in its local copy
of the register value but never writes that value back to the hardware.
The VREFINT reference for the HSI48 scaler is therefore never enabled.
Only the earlier ENVREFINT update reaches the register, so VREFINT
itself is enabled while the HSI48 reference is not. HSI48 then runs
without its voltage reference and the 48MHz clock is not accurate enough
to be used by the USB device controller.
Write the register after applying the HSI48 reference bit.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
stm32_enable_hsi48() set CRS_CR_AUTOTRIMEN but left CRS_CR_CEN clear.
AUTOTRIMEN only instructs the hardware to apply corrections derived from
the frequency error counter; the counter itself is enabled by CEN. With
CEN clear no error measurement is ever produced and the HSI48 TRIM value
stays at its reset default, so the oscillator is never disciplined to the
synchronisation source.
Set both bits, matching the value the STM32 ROM bootloader programs when
it runs its own crystal-less USB stack (CRS_CR = 0x1a60, i.e.
CEN | AUTOTRIMEN with a trimmed TRIM field).
This file is shared by the M0 STM32 parts (F0, G0, C0, L0); all of them
require CEN for automatic trimming to function.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
The SYSCFG peripheral clock was gated on CONFIG_STM32_SYSCFG, but that
symbol is not defined by the STM32L0 Kconfig (only stm32h7 declares it),
so RCC_APB2ENR_SYSCFGEN was never set on this chip.
With SYSCFG unclocked every write performed by vrefint_enable() is
discarded and SYSCFG_CFGR3 reads back as 0x00000000. VREFINT and, in
particular, the ENBUFVREFINTHSI48 reference for the HSI48 oscillator are
therefore never enabled. HSI48 still reports HSI48RDY, but it runs
without its voltage reference and the 48MHz clock supplied to the USB
device controller is unusable: the controller cannot sample the bus,
never latches a reset condition in USB_ISTR, and never raises its
interrupt. The result is a USB device that is configured correctly in
every visible register yet never enumerates.
VREFINT is configured exclusively through SYSCFG_CFGR3, so enable the
SYSCFG clock whenever CONFIG_STM32_VREFINT is selected.
Observed on NUCLEO-L073RZ (STM32L073RZ):
before: SYSCFG_CFGR3 = 0x00000000, no enumeration
after: SYSCFG_CFGR3 non-zero, device enumerates as CDC/ACM
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
The clock recovery system peripheral clock was enabled only when
CONFIG_STM32_CRS was selected. The CRS is required by any board that
uses HSI48 as the 48MHz clock source, because HSI48 must be trimmed from
an external synchronisation event to stay within the tolerance demanded
by USB full speed operation.
STM32_USE_HSI48 is the condition under which the remaining HSI48 and CRS
setup is compiled in, see stm32_enable_hsi48(), so accept that condition
here as well. Without the peripheral clock the CRS registers are
inaccessible and automatic trimming silently does nothing.
CONFIG_STM32_CRS is retained so that boards selecting the CRS directly
are unaffected.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
The code that claimed to "enable clocking to the USB peripheral" cleared
RCC_APB1ENR_USBEN inside RCC_APB1RSTR. That is both the wrong register
and the wrong bit: USBEN belongs to RCC_APB1ENR, while APB1RSTR holds
RCC_APB1RSTR_USBRST. The peripheral clock is enabled by the RCC setup
performed at boot, so the write had no useful effect and merely cleared
an unrelated reset bit.
Issue a proper reset pulse on RCC_APB1RSTR_USBRST instead, so the
controller starts from a known state.
On STM32L0 the D+/D- lines are connected to the USB transceiver
automatically once the peripheral is enabled and there is no alternate
function to select, so skip the GPIO configuration on that chip. The
board GPIO_USB_DM/GPIO_USB_DP definitions do not exist there.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
The initial interrupt mask enabled only reset, suspend and correct
transfer. Error conditions reported by the controller, USB_ISTR_ERR and
USB_ISTR_PMAOVRN, were neither enabled nor acknowledged.
Because the status bits are never cleared, an error condition latched in
USB_ISTR remains set and is re-evaluated on every subsequent interrupt,
which makes the reported status misleading when debugging transfer
problems.
Add ERRM and PMAOVRN to the initial mask and clear the corresponding
status bits when they are seen.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
The correct transfer loop in stm32_usb_interrupt() dispatched every
completion to stm32_epdone(), including those for endpoint 0.
stm32_epdone() implements the generic bulk/interrupt endpoint completion
path. It does not decode the SETUP stage, does not maintain the EP0
state machine, and does not apply the EP0 specific RX/TX status rules.
Control transfers therefore never completed correctly and the device
could not be enumerated.
Dispatch endpoint 0 to stm32_ep0done(), which is the control endpoint
handler and is already used for the same purpose by the low priority
transfer path in stm32_lptransfer().
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
The packet memory area (PMA) accessors in the M0 USB device driver were
carried over from the STM32F1 implementation, where the PMA is seen by
the CPU as 16-bit values placed on 32-bit boundaries. On the STM32F0,
STM32L0 and other M0 parts the PMA is a linear 16-bit memory, so the
F1 scaling is wrong:
- STM32_USB_BTABLE_RADDR() shifted the computed buffer descriptor offset
left by one, addressing every second descriptor entry.
- The buffer descriptor accessors declared the descriptor entries as
uint32_t and accessed them 32 bits at a time, so each write clobbered
the adjacent entry.
- stm32_copytopma() and stm32_copyfrompma() scaled the PMA offset by two
when computing the packet buffer address.
The result is that endpoint buffer descriptors and packet data are
written to the wrong offsets in packet memory, and no transfer completes
correctly.
Drop the F1 scaling and use 16-bit accesses throughout. Note that the
sibling stm32_usbfs.h defines STM32_USB_BTABLE_RADDR() without the shift
already, so this brings the M0 header in line with it.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
CONFIG_STM32_GPIOIRQ has never had a Kconfig definition, and the guarded
stm32_gpioirqinitialize function has no declaration or implementation.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: OpenAI Codex:gpt-5
CONFIG_STM32_GPIO_IRQ has no Kconfig definition, and the guarded stm32_gpioirq
functions have no declarations or implementations.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: OpenAI Codex:gpt-5
Remove the dependency on the iLLD SFR headers (IfxCpu_bf.h and
IfxCbs_reg.h) and the iLLD intrinsics (__mfcr/__mtcr) from the
hardware debug monitor implementation.
The debug CSFR numbers, trigger-event register (TR0..TR7) addresses,
TREVT bit-field offsets and the CBS_OEC register address are now
defined locally with a TC_ prefix, so the file no longer leaks the
iLLD CPU_* namespace (which is still pulled in transitively through
arch/irq.h). Register accesses use the tricore_mfcr/tricore_mtcr
macros, and the DBGTCR/DBGCFG/DBGACT bit-field unions are replaced
with explicit shifts.
This is a pure de-iLLD refactor with no behavior change, verified on
a TC4x7 EVB: the board boots to NuttShell and breakpoints trigger
identically before and after the change.
Signed-off-by: zhangyuan29 <zhangyuan29@xiaomi.com>
Add initial Apache NuttX support for the Allwinner D1 / T-Head C906
running in supervisor mode under OpenSBI.
Add support for:
- RV64 D1 architecture definitions
- Lichee RV 86 Panel board configuration
- UART0 console at 115200 baud
- D1 PLIC interrupt controller
- native D1 Timer1 scheduler tick
- early inherited-watchdog disable
- FLAT S-mode NSH configuration
The port has been tested on physical Sipeed Lichee RV / 86 Panel
hardware and boots to an interactive NuttShell.
The scheduler tick uses OSC24M Timer1 at 1000 Hz. The Timer1 interval
register is programmed with 23999 to produce exactly 24000 input clocks
per tick on the physical D1.
Assisted-by: OpenAI Codex:gpt-5.6-sol
Signed-off-by: Lance Harvie <lanceharvie@gmail.com>
Add initial NuttX port for the original (white) BeagleBone board, which is
powered by the TI AM335x Sitara Cortex-A8 processor.
This commit includes:
- Board documentation
- Board support package files derived from BeagleBone black
- Architecture-specific page allocator for memory management in kernel build.
- Default configurations for both flat (`nsh`) and kernel (`knsh`) builds
running via U-Boot from a microSD card.
Signed-off-by: Lwazi Dube <lwazeh@gmail.com>
Remove the feature #ifdef guard since the file
is conditionally compiled.
Remove the #ifdefs for other stm32 families that came from the
common stm32_wdg.h.
Add additional extended prescaler values for stm32h5 IWDG.
Change the WWDG_CFR_WDGTB shift value to match
what it should be on stm32h5. (WWDG not supported on stm32h5 yet.)
Signed-off-by: Liam Howatt <liamhowatt@geotab.com>
Copy the common m3m4_v1 implementation. The only
difference is a debug log of the register which
contains the LSI enabled status bit. In the common
implementation the register is RCC_CSR. On stm32h5
it is RCC_BDCR.
The common implementation is _not_ used because it's
only built if CONFIG_STM32_COMMON_LEGACY which
stm32h5 currently is not. IWDG is added similarly to stm32l4.
STM32_HAVE_IP_WDG_M3M4_V1 is selected but a distinct
source file implements it.
Signed-off-by: Liam Howatt <liamhowatt@geotab.com>
Co-authored-by: Nathan Best <nathanbest@geotab.com>
The port had one board directory holding one board, with everything in it
whether it described the SoC or the PCB. A second EIC7700X board follows,
so this adopts the common-plus-board layout NuttX provides, as mpfs uses.
boards/risc-v/eic7700x/common holds what is true of the SoC: the boot path
that mounts the RAM disk and /proc before calling the board's own bring
up, the linker script, the start up scripts and the image builder.
ARCH_CHIP_EIC7700X selects ARCH_BOARD_COMMON, so the symlinks the build
makes always point at code that compiles.
The board directory keeps what is a fact about the PCB: its own board.h
and board_memorymap.h, since the include fallback is all or nothing, a
bring up that owns the order its devices register in, and a board_config.h
declaring what that bring up may call.
The image builder moves to common/tools and derives its output name from
the configuration. It computes the padding between the kernel and the RAM
disk from _ebss rather than assuming 64 KiB, which fails once BSS grows
past it: the disk lands below _ebss and the BSS clear zeroes it before
anything searches for it.
The StarPro64 configuration gains what the port now needs: four harts,
960 MiB of RAM, a larger task stack, a backtrace on assert, the system log
in RAM for dmesg, and ELF applications, for which ARCH_CHIP_EIC7700X now
selects ARCH_HAVE_ELF_EXECUTABLE.
board.h loses its LED definitions. CONFIG_ARCH_LEDS is not set, nothing
implements board_autoled_on(), and the indices they gave named no LED.
The documentation pages gain the tags the template asks for.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
Three faults in how the kernel maps itself.
The page pool covered the RAM disk, which the boot loader appends above
the kernel, so the BSS clear destroyed it before anything searched for it.
The pool now covers only pgram, and the RAM disk is mapped on its own
account.
The kernel data region is mapped with 2 MiB pages rather than 4 KiB ones.
Everything in it carries the same permissions, so the finer granularity
bought nothing while costing one L3 slab per 2 MiB from a pool of two.
The linker script and Kconfig describe the page pool separately and both
descriptions are used, so they now agree. When they disagree, pages
outside the smaller of the two get a virtual address of zero and are
written through, which on this SoC lands on identity mapped low memory
rather than faulting.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
External interrupts were enabled and claimed in the context of whichever
hart the firmware handed over on, which is not fixed. They reset routed
to wherever the boot loader left them, and an interrupt delivered to a
context nobody services cannot be told from a device that never raised
one.
Enable and claim in CPU0's S mode context, which is hart 0's. Steering a
source at another hart would mean choosing which, and NuttX has no way for
a driver to say.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The port ran on whichever hart the firmware handed over on, with a single
idle stack. The firmware does not pick the same hart every boot, so
nothing may assume one.
The hart that arrives first records which it was, indexes its idle stack
by its own ID, and restarts on hart 0; NuttX runs CPU0 there because that
is the only hart riscv_set_inital_sp() gives a whole idle stack to. The
first hart in owns the one time setup, and that guard lives in .data
because it is read before the BSS is cleared.
CONFIG_SMP_NCPUS below four is refused in chip.h: the hart the firmware
picked would have no slot and would stop in __start before it could
restart, which fails on some resets and not others.
Secondary harts are released through the common SBI helper rather than a
private copy of the same call.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The SysTick timer logic of stm32h5, stm32h7, stm32l4, stm32l5, stm32u5
and stm32wl5 tests a family specific SYSTICK_HCLKd8 symbol, while
common/stm32 and stm32wb already test CONFIG_STM32_SYSTICK_HCLKd8. Use
the common name everywhere.
No Kconfig defines the symbol and the timer logic undefines it
unconditionally, so this does not change the generated code.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
The flash header documents CONFIG_STM32WB_FLASH_CONFIG_x and the RCC
tests CONFIG_STM32WB_AES1/AES2, which no Kconfig defines. Use the
common CONFIG_STM32_* names.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
CONFIG_STM32WL5_FLASHEN is not defined by any Kconfig, so the FLASH clock
enable is dead code. Use CONFIG_STM32_FLASH.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
CONFIG_STM32U5_I2C3EN, SDMMC1EN, SDMMC2EN, the STM32U5xxXX family names
and STM32U5A5ZJT are not defined by any Kconfig, so the RCC clock enables
and the STM32U5A5ZJT block in chip.h are dead code. Use the common
CONFIG_STM32_* symbols and CONFIG_ARCH_CHIP_STM32U5A5ZJT.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
CONFIG_STM32L5_FLASHEN, OTFDEC1EN, PKAEN, SDMMC1EN, WWDGEN and GTZCEN
are not defined by any Kconfig, so the RCC clock enables are dead code.
Use the common CONFIG_STM32_* peripheral symbols.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
CONFIG_STM32L4_OTGFS_SOFOUTPUT is not defined by any Kconfig, so the SOF
output pin is never enabled. Use CONFIG_STM32_OTG_SOFOUTPUT.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
CONFIG_STM32H7_LCD_BACKLIGHT is not defined by any Kconfig, so the LTDC
backlight control is dead code. Use CONFIG_STM32_LTDC_BACKLIGHT.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
The headers test CONFIG_STM32H5_* names that no Kconfig defines (the
STM32H5xXXX families, FLASHEN, OTFDEC1EN, DCACHE, STM32H2X/H3X/H7X), so
those branches are dead code. Use the common CONFIG_STM32_* symbols.
Fix what this exposes: derive the SRAM2/SRAM3 bases from the family SRAM
sizes, since the boot ECC init would otherwise write past the end of RAM
on smaller parts, correct the H52x/H53x SPI count to SPI1-4 and drop the
STM32_STM32H5X3XX select, which names no symbol.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
CONFIG_STM32F7_LCD_BACKLIGHT is not defined by any Kconfig, so the LTDC
backlight control is dead code. CONFIG_STM32F7_PLLSAI and
CONFIG_STM32F7_PLLI2S are defined by the board.h files, and the common
SPI test helper names its mode macros CONFIG_STM32F7_SPIx_TEST_MODE.
Use the common CONFIG_STM32_* names everywhere.
Also drop the misspelled CONFIG_STM32F7_STM33F75XX from the DMA chip
check, which already tests CONFIG_STM32_STM32F75XX.
The CAN section of the STM32F7 documentation names the options
CONFIG_STM32F7F7_CANx, which has a duplicated family prefix and never
existed. Use the common names there too.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Wire the shared Ameba PWM driver (arch/arm/src/common/ameba/ameba_pwm.c)
to RTL8721F (amebagreen2). The chip spreads PWM across four four-channel
timers (TIM4..TIM7); this port drives TIM4 as the single time base with
four compare channels, matching the shared driver's model. A new
ameba_pwm_chip.h supplies the RTL8721F specifics taken from the SDK
fwlib headers: TIM4 at the non-secure base 0x41000000, 40 MHz input
clock, IRQ 11 (TIMER4_IRQ), crossbar pad-mux codes 111..114
(PINMUX_FUNCTION_TIM4_PWM0..3) and the distinct function/clock enable
bits (APBPeriph_PWM0 / APBPeriph_PWM0_CLOCK).
The board registers one timer at /dev/pwm0 with channel 1 on PB18 and
channel 2 on PB19 for the pwm example; edit the table to match a board's
wiring. The common driver is not touched.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Wire the shared Ameba PWM driver (arch/arm/src/common/ameba/ameba_pwm.c)
to RTL8720F. The chip spreads PWM across several four-channel timers
(TIM4/TIM5); this port drives TIM4 as the single time base with four
compare channels, matching the shared driver's model. A new
ameba_pwm_chip.h supplies the RTL8720F specifics taken from the SDK
fwlib headers: TIM4 at the non-secure base 0x401c7000, 40 MHz input
clock, IRQ 9 (TIMER4_IRQ), crossbar pad-mux codes 45..48
(PINMUX_FUNCTION_TIM4_PWM0..3) and the distinct function/clock enable
bits (APBPeriph_PWM0 / APBPeriph_PWM0_CLOCK).
The board registers one timer at /dev/pwm0 with channel 1 on PB18 and
channel 2 on PB19 for the pwm example; edit the table to match a board's
wiring. The common driver is not touched.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Add a shared NuttX PWM lower-half for the Realtek Ameba PWM timer in
arch/arm/src/common/ameba, driven through the SDK fwlib. TIM8 provides a
single time base feeding eight compare channels (CCR0..CCR7) that share one
frequency while each carries its own duty, so a single /dev/pwm0 exposes the
multichannel output via CONFIG_PWM_NCHANNELS. The fwlib PWM routines are
split ROM/RAM: the time-base calls resolve from on-chip ROM, while the
capture/compare calls live in fwlib ram_common/ameba_tim.c, which the build
pulls into AMEBA_FWLIB_SRCS when CONFIG_AMEBA_PWM is set.
Per-chip wiring (timer index, channel count, register base, input clock,
IRQ, clock masks and the crossbar pad-mux code table) lives in
arch/arm/src/rtl8721dx/ameba_pwm_chip.h so a port to another Ameba chip only
supplies a same-named header; the pad-mux codes are a per-channel table
(AMEBA_PWM_PINMUX_FIDS) rather than a computed base, so chips with a single
shared code or codes grouped per timer are expressed by the header alone.
The timer registers as /dev/pwm0 from pke8721daf bring-up through the stock
PWM character driver; a dedicated `pwm` defconfig drives examples/pwm for
validation.
Signed-off-by: dechao_gong <dechao_gong@realsil.com.cn>
Assisted-by: Claude <noreply@anthropic.com>
Copy the stm32u5 implementation,
add necessary port configuration for the MUXs.
Signed-off-by: Liam Howatt <liamhowatt@geotab.com>
Co-authored-by: Nathan Best <nathanbest@geotab.com>
Co-authored-by: Randy Rossi <randyrossi@geotab.com>
esp_reconnect_work_cb() dereferences g_sta_reconnect, which is only
declared under ESP_WLAN_HAS_STA, so CONFIG_ESPRESSIF_WIFI_SOFTAP alone
fails to compile. Guard the callback as the Xtensa counterpart does.
Assisted-by: Claude Code:claude-opus-5
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
