- Allow specifying an alternative board filter for the bootloader TTY,
as this will present different vendor, model, and serial than RIOT's
USB implementation.
- Allow specifying the serial. This is useful when multiple CDC ACM
devices are present.
This adds mspdebug as package, similar to EDBG, so that the
programmer/debugger is build from source.
This has the advantage that we can indeed provide patches of our own.
The first patch fixes a bug with the CPU detection of `mspdebug` in
combination with the Olimex MSP430-JTAG-TINY-V2. The second adds the
`--expect-id <CPU_NAME>` argument.
The RIOT integration is updated to directly make use of the
`--expect-id` parameter. No more spending time debugging why firmware
the firmware for the `olimex-msp430-h2618` doesn't run when flashed on
the `olimex-msp430h1611` hardware :D
When `stdio_cdc_acm` is used, prefer selecting the USB devices with
vendor `RIOT-os.org` and model `$(BOARD)` and only fall back
to `$(TTY_BOARD_FILTER)` if no such TTY was found.
This makes it possible to add a TTY board filter matching only an
integrated USB to UART bridge, but still do the right thing when
the user explicitly uses `stdio_cdc_acm` instead of the default
`stdio_uart`.
Allow setting `OPENOCD_TRANSPORT` to `default` for when a transport to
not explicitly set the transport. This is useful when the target or
interface script already specify the transport.
19703: cpu/sam0_eth: interrupt based link detection/auto-negotiation r=benpicco a=benpicco
19724: dist/tools/openocd: add OPENOCD_SERVER_ADDRESS variable r=benpicco a=fabian18
19735: nrf5x_common: Clear I2C periph shorts r=benpicco a=bergzand
### Contribution description
The I2C peripheral's shortcuts are used with the read and write register to automatically stop the I2C transaction or to continue with the next stage.
With simple I2C read and write bytes these shorts are not used, but are also not cleared by the function in all cases, causing it to use the shortcut configuration set by a previous function call. This patch ensures that the shorts are always set by the read and write functions
### Testing procedure
Should be possible to spot with a logic analyzer and the I2C periph test. Maybe the HIL test can also detect it :)
### Issues/PRs references
None
Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Co-authored-by: Fabian Hüßler <fabian.huessler@ml-pa.com>
Co-authored-by: Koen Zandberg <koen@bergzand.net>
19556: tools/mspdebug: fix `make debug` and `make debugserver` r=aabadie a=maribu
### Contribution description
The semantics of `make debug` and `make debugserver` have changed in the years since the MSP430 integration. This brings the implementation back into line with the current semantics
- `make debug` now starts both mspdebug and GDB, no need to run `make debugserver` prior to `make debug` anymore
- `make debug` no longer flashes the target to not waste flash erase cycles
- GDB mutliarch support is added
- support for selecting a debug adapter by its serial is added
19662: driver/lc709203f: remove unnecessary use of float r=aabadie a=kfessel
### Contribution description
removes a unnecessary use of float
### Testing procedure
read and test if you got that hardware (I don't)
### Issues/PRs references
#19614
Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Co-authored-by: Karl Fessel <karl.fessel@ovgu.de>
The semantics of `make debug` and `make debugserver` have changed in
the years since the MSP430 integration. This brings the implementation
back into line with the current semantics
- `make debug` now starts both mspdebug and GDB, no need to
run `make debugserver` prior to `make debug` anymore
- `make debug` no longer flashes the target to not waste flash erase
cycles
- GDB mutliarch support is added
- support for selecting a debug adapter by its serial is added
There seems to be a consensus to go for a more ELF centric approach
whenever possible. J-Link seems to work fine with ELF files, so let's
avoid the extra step to create a bin file from the ELF file prior to
flashing.
While testing examples/micropython I notice that the default of miniterm.py is actually miniterm.
To simplify user setups, this checks for miniterm.py first then falls back to miniterm.
Boards with an integrated debugger/programmer that also provides the
serial as UART <--> USB adapter, the TTY serial matches the serial of
the programmer.
This adapts the `serial.inc.mk` to set the `DEBUG_ADAPTER_ID` to the
TTY serial if (and only if) `MOST_RECENT_PORT` *and*
`DEBUG_ADAPTER_ID_IS_TTY_SERIAL` both have a value of `1`. Boards with
an integrated programmer are expected to set
`DEBUG_ADAPTER_ID_IS_TTY_SERIAL` to `1` in their `Makefile.include`.
Typically, OpenOCD is already performing a reset on connect. A
`reset halt` to bring the target to a `halt` state for flashing will
result in the device going through a second reset cycle. This can be
problematic with some device, such as the CC26xx MCUs. For these
devices, an `OPENOCD_CMD_RESET_HALT := -c 'halt'` will avoid the second
reset that is causing the issues.
This adds the configuration to allow choosing the XDS110 used in
cc13xx-launchpad and cc26xx-launchpad boards via the
`OPENOCD_DEBUG_ADAPTER` variable.
19074: cpu/esp8266: build the SDK bootloader from source r=benpicco a=gschorcht
### Contribution description
This PR is a takeover of PR #17043, which is rebased to the current master and includes some corrections that became necessary after rebasing.
**Copied from description of PR #17043:**
We had four versions of pre-built bootloaders for the esp8266 with different settings of logging and color logging. These bootloaders were manually built from the SDK and shipped with RIOT-OS source code. However there are more settings that affect the bootloader build that are relevant to the app or final board that uses this bootloader. In particular, flash size and flash speed is important for the bootloader to be able to load an app from a large partition table at the fastest speed supported by the board layout and flash chip.
Another example is the UART baudrate of the logging output from the bootloader. The boot ROM will normally start at a baud rate of 74880 (depending on the crystal installed), so it might make sense to keep the UART output at the same speed so we can debug boot modes and bootloader with the same terminal.
This patch builds the `bootloader.bin` file from the ESP8266 SDK source code. The code is built as a module (`esp8266_bootloader`) which at the moment doesn't generate any object code for the application and only produces a `bootloader.bin` file set to the `BOOTLOADER_BIN` make variable for the `esptool.inc.mk` to flash.
The code needs to be compiled and linked with custom rules defined in the module's Makefile since the `bootloader.bin` is its own separate application.
The `BOOTLOADER_BIN` variable is changed from a path relative to the `$(RIOTCPU)/$(CPU)/bin/` directory to be full path. This makes it easier for applications or board to provide their own bootloader binary if needed.
As a result of building the bootloader from source we fixed the issue of having a large partition table.
### Testing procedure
Use following command to flash the application with STDIO UART baudrate of 115200 baud.
```
BAUD=74880 USEMODULE=esp_log_startup make -C tests/shell BOARD=esp8266-esp-12x flash
```
Connect with a terminal programm of your choice (unfortunatly `picocom` and `socat` don't support a baudrate close to 74880), for example:
```
python -m serial.tools.miniterm /dev/ttyUSB0 74880
```
On reset, the `esp8266-esp-12x` node shows the ROM bootloader log output
```
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x40100000, len 6152, room 16
tail 8
chksum 0x6f
load 0x3ffe8008, len 24, room 0
tail 8
chksum 0x86
load 0x3ffe8020, len 3408, room 0
tail 0
chksum 0x79
```
as well as the second-stage bootloader built by this PR (`ESP-IDF v3.1-51-g913a06a9ac3`) at 74880 baudrate.
```
I (42) boot: ESP-IDF v3.1-51-g913a06a9ac3 2nd stage bootloader
I (42) boot: compile time 11:25:03
I (42) boot: SPI Speed : 26.7MHz
...
I (151) boot: Loaded app from partition at offset 0x10000
```
The application output is seen as garbage since the `esp8266-esp-12x` uses 115200 as baurate by default.
To see all output at a baudrate of 74880 baud, you can use the following command:
```
CFLAGS='-DSTDIO_UART_BAUDRATE=74880' BAUD=74880 USEMODULE=esp_log_startup make -C tests/shell BOARD=esp8266-esp-12x flash
```
If the application is built without options, the ROOM bootloader output will be 74880 baud and the second stage bootloader and application output will be 115200 baud.
### Issues/PRs references
Fixes issue #16402
Co-authored-by: iosabi <iosabi@protonmail.com>
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
Instead of using a fixed position of the image file in the flash, the variable `FLASHFILE_POS` is used which allows to override the default position of the image in the flash at 0x10000.
We had four versions of pre-built bootloaders for the esp8266 with
different settings of logging and color logging. These bootloaders were
manually built from the SDK and shipped with RIOT-OS source code.
However there are more settings that affect the bootloader build that
are relevant to the app or final board that uses this bootloader. In
particular, flash size and flash speed is important for the bootloader
to be able to load an app from a large partition table at the fastest
speed supported by the board layout and flash chip.
Another example is the UART baudrate of the logging output from the
bootloader. The boot ROM will normally start at a baud rate of 74880
(depending on the crystal installed), so it might make sense to keep
the UART output at the same speed so we can debug boot modes and
bootloader with the same terminal.
This patch builds the bootloader.bin file from the ESP8266 SDK source
code. The code is built as a module (esp8266_bootloader) which at the
moment doesn't generate any object code for the application and only
produces a bootloader.bin file set to the BOOTLOADER_BIN make variable
for the esptool.inc.mk to flash.
The code needs to be compiled and linked with custom rules defined in
the module's Makefile since the bootloader.bin is its own separate
application.
The `BOOTLOADER_BIN` variable is changed from a path relative to the
`$(RIOTCPU)/$(CPU)/bin/` directory to be full path. This makes it easier
for applications or board to provide their own bootloader binary if
needed.
As a result of building the bootloader from source we fixed the issue of
having a large partition table. Fixes#16402.
Allow overriding the shell command used to auto-detect the TTY of a
board with `MOST_RECENT_PORT=1` via the `TTY_SELECT_CMD` variable.
The use case is to also detect Arduino Mega 2560 clones with cheap
USB UART bridges (for which the filter command may yield false
positives) while preferring genuine Arduino Mega 2560 boards (if
found) over the clones (as the filter for genuine boards does not yield
false positives).
In an ideal world everyone would just install `gdb-multiarch` and be
happy. However, some MCUs need magic GDB versions sprinkled with
unicorn-stardust-Espressif-patches...
Since there is little reason to have `$(target)-gdb` installed in
addition to `gdb-multiarch` if `gdb-multiarch` would work fine, let's
assume the user wants to use `$(target)-gdb` when present over
`gdb-multiarch`.
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
If `AVRDUDE_PROGRAMMER` is already set to a programmer that is also
capable of debugging, we can assume that typically the user will want
to use the same hardware for debugging. Thus, let `AVR_DEBUGDEVICE`
default to the matching hardware.
JLink presumably has information about the device's RAM available
internally. Not passing the precise symbol area (which would be
available in the ELF file) because a) that'd make the terminal break
when the flashed firmware does not equal the built one, and b) that
would introduce a dependency from `term` to the ELF file that other
terminals don't have.
When `stdio_cdc_acm` is used, assume `"RIOT-os\.org"` as vendor string
and `$(BOARD)` being used as model string. This is the default
behavior in RIOT since eaace28804
After introducing #18423 there are occasional messages that still happen.
These messages cause a diff output when testing with TEST_KCONFIG=1.
This then causes a failure when comparing make/kconfig modules and packages.
If Quad SPI modes qout or qio are set by variable FLASH_MODE, esptool.py has to be called with parameter `--flash_mode dio` so that the first stage bootloader is always using Dual SPI mode.
When `MOST_RECENT_PORT` is set to `1`, the most recently added USB
serial is selected. This is a crude but surprisingly effective filter.
However, for the CC2560-Launchpad this doesn't work, as it provides
two USB serials. The first USB serial interface is the targeted UART
bridge and the second controls the debugger. Since the second is added
a tiny fraction after the first, this reliably selects the wrong
interface. Allowing the board to filter USB serials first can avoid
this issue.
This is also useful as e.g. an STM Nucleo board can easily be told
apart from an `samr21-xpro` or an nRF52840dk using such filters.
