arch/xtensa/src/esp32s3: define the ESP-IDF console macros for the main build - #19998
Closed
FelipeMdeO wants to merge 1 commit into
Closed
arch/xtensa/src/esp32s3: define the ESP-IDF console macros for the main build#19998FelipeMdeO wants to merge 1 commit into
FelipeMdeO wants to merge 1 commit into
Conversation
…in build esp-hal-3rdparty's sleep_uart.c and bootloader_console.c reference CONFIG_ESP_CONSOLE_UART_NUM, CONFIG_ESP_CONSOLE_ROM_SERIAL_PORT_NUM and CONFIG_ESP_CONSOLE_USB_SERIAL_JTAG directly -- ESP-IDF sdkconfig-style macros that this port never defines for the main firmware build. Bootloader.mk defines the first two, but only for the bootloader build and only when the console is CONFIG_UART0/1_SERIAL_CONSOLE; nothing ever defines CONFIG_ESP_CONSOLE_USB_SERIAL_JTAG. That's fine as long as every board's console is a plain UART, since sleep_uart.c's use is guarded by "#if (CONFIG_ESP_CONSOLE_UART_NUM != -1)" and silently does nothing when the symbol is missing (it's still undefined behavior to compare an undefined macro, but it happens to compile). bootloader_console.c is not so forgiving: none of its four `#ifdef CONFIG_ESP_CONSOLE_*` blocks match when the symbol is simply absent, so bootloader_console_init() is never emitted at all, and linking fails with it undefined as soon as a board actually reaches the console-selection code -- which any board using CONFIG_ESP32S3_USBSERIAL (the native USB Serial/JTAG console, e.g. the Seeed XIAO ESP32-S3) does immediately. Mirror Bootloader.mk's own CONFIG_UART0/1_SERIAL_CONSOLE logic in hal.mk for the main build, and add the missing USB_SERIAL_JTAG case. Boards on a UART console are unaffected either way; boards on the native USB Serial/JTAG console go from "does not link" to building. Assisted-by: Claude <noreply@anthropic.com> Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
xiaoxiang781216
approved these changes
Aug 28, 2026
github-actions
Bot
added
Arch: xtensa
|
Contributor
|
Those should be defined under HAL |
Contributor
Author
|
Sorry Guys, it was a my fault, sorry for this. This PR isn't necessary. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
No driver exists for the LSM6DS3TR-C. lsm6dsl.c is the closest
register-compatible match (same WHO_AM_I, same CTRL1_XL/CTRL2_G layout)
but is the deprecated legacy char-device style; lsm6dso32_uorb.c is the
closest uORB-style match but is for a different chip variant. The new
driver borrows lsm6dso32_uorb.c's structure (dual sensor_lowerhalf_s,
raw I2C_TRANSFER helpers) and lsm6dsl.h's register map -- fixing a bug
in the header it was ported from along the way: LSM6DSL_FIFO_CTRL2_SHIFT
is defined as 255 instead of 0.
Delivery mode is chosen the same way mpu6050 does: kthread polling by
default, or interrupt-driven if the board supplies attach().
On the XIAO ESP32-S3 with Seeed's IMU Breakout Board, INT1/INT2 route to
GPIO3/GPIO4 (confirmed from the breakout board's schematic, not guessed).
Only INT1/GPIO3 is wired up, since one pin is now enough; GPIO4/INT2 is
documented as available but unused.
Also: CTRL1_XL's FS_XL bits were never actually written to match the
driver's own software default (4g) -- registration set the in-memory
value but the chip stayed at its 2g reset default until a caller issued
an explicit SNIOC_SETFULLSCALE. register() now writes it.
Impact
New optional driver (CONFIG_SENSORS_LSM6DS3TRC, default n), no impact
on boards that don't enable it.
Testing
Host: Ubuntu 24.04.4 LTS. xtensa-esp-elf-gcc (crosstool-NG
esp-14.2.0_20241119) 14.2.0. checkpatch.sh (style + -m commit message)
clean.
Compiles clean for the XIAO ESP32-S3 target, rebased onto current
master with no conflicts.
On hardware -- Seeed XIAO ESP32-S3 Sense + IMU Breakout Board
(LSM6DS3TR-C @ 0x6A, I2C0 SDA=GPIO5/SCL=GPIO6, INT1=GPIO3), native USB
Serial/JTAG console:
i2c dev 0 0x7f finds the IMU at 0x6a and the board's OLED at 0x3c,
matching the breakout board schematic.
i2c get -a 0x6a -r 0x0f reads WHO_AM_I = 0x6a.
Polling mode: sensor_accel0/sensor_gyro0 stream continuously for
minutes with no read errors, reproduced across multiple reboots.
Interrupt mode: reproduced across multiple fresh reboots, ~300 samples
of each topic per 6s window (matching the configured 52 Hz ODR), with
shared timestamps down to the microsecond between the two topics
per event -- confirming both come from the same burst read.
(%pB prints as a raw pointer here because the bench defconfig didn't
have CONFIG_LIBC_PRINT_EXTENSION on -- a uorb_listener display
option, unrelated to this driver. The timestamps and the 1:1
gyro/accel pairing are the real signal being verified.)