cpu/$(CPU)/Makefile.features and cpu/$(CPU)/Makefile.dep are
automatically included
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
I did not move CPU_MODEL in that one as it requires other refactoring
first.
- Created new `bluepill-128kib` as 128KiB version of the `bluepill`
- Created new `blackpill-128kib` as 128KiB version of the `blackpill`
- Updated `openocd.cfg` to allow flashing 128KiB of ROM
uart_init should not be called from board_init. stdio_init is responsible for
initializing debug UART device.
Signed-off-by: Francois Berder <18538310+francois-berder@users.noreply.github.com>
cpu/$(CPU)/Makefile.features and cpu/$(CPU)/Makefile.dep are
automatically included
The multiple boards handling has been changed to use 'CPU_MODEL ?='.
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
cpu/$(CPU)/Makefile.features and cpu/$(CPU)/Makefile.dep are
automatically included
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
cpu/$(CPU)/Makefile.features and cpu/$(CPU)/Makefile.dep are
automatically included
CPU_MODEL is currently kept uppercase. Making it lowercase is a future task.
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
cpu/$(CPU)/Makefile.features and cpu/$(CPU)/Makefile.dep are
automatically included
Add the missing space when defining 'CPU_MODEL'.
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
cpu/$(CPU)/Makefile.features and cpu/$(CPU)/Makefile.dep are
automatically included
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
cpu/$(CPU)/Makefile.features and cpu/$(CPU)/Makefile.dep are
automatically included
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
cpu/$(CPU)/Makefile.features and cpu/$(CPU)/Makefile.dep are
automatically included
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
cpu/$(CPU)/Makefile.features and cpu/$(CPU)/Makefile.dep are
automatically included
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
* CPU files should already have 'CPU' defined by the board.
* Do not conditionally define CPU as it is not needed.
This is part of cleanup prior to moving the CPU/CPU_MODEL to
Makefile.features.
Peripheral configured:
- 5 UARTs for stdio via STLink, Arduino connector, PMOD connector,
STMOD+ connector and ESP-01 connector
- 1 I2C available on Arduino connector and STMOD+ connector
- 2 SPIs available on Arduino connector and PMOD connector
When flashing some applications the flasher sometimes gets stuck which
prevents flashing after.
It may be from a specific firmware or operation but do not have one yet.
Connect with reset asserted fix flashing from this state.
When flashing some applications the flasher sometimes gets stuck which
prevents flashing after.
It may be from a specific firmware or operation but do not have one yet.
Connect with reset asserted fix flashing from this state.
It was found after the `stm32f3discovery` get stuck in a non-flashable mode
after some firmwares.
- Moved compiler & linker flags from boards/common/msba2 to cpu/arm7_common
- Moved dependency to newlib nano to cpu/arm7_common
- Moved config to link in cpu/startup.o to cpu/arm7_common
Enable the handling of flashing `softdevice.hex` when flashing the firmware
for openocd.
However, for flashing, only the `hexfile` and `binfile` can currently be used.
The `elffile` is generated with local pages aligned to `0x10000` which makes
the program starting at `0x1f000` be flashed from `0x10000` with padding bytes
even if the `.text` section is indeed at `0x1f000`:
readelf --sections bin/nrf52dk/gnrc_networking.elf
...
[ 1] .text PROGBITS 0001f000 00f000 00f698 00 AX 0 0 16
...
readelf --segments bin/nrf52dk/gnrc_networking.elf
...
LOAD 0x000000 0x00010000 0x00010000 0x1e6a0 0x1e6a0 R E 0x10000
...
The padding bytes would go through `verify_image` in `openocd` so be expected
to not be overwritten but are by `softdevice.hex`
Using --nmagic at link time removes the local page alignement but would
need dedicated testing.
- The Jiminy-Mega256RFR2 is seemingly unmaintained, as no one has responded
on requests to test changes on it. This lack of support has been blocking
various PRs in the last few months
- No one seems to use it
- Boards that are added to RIOT should match at least one of the following
- It is actively maintained
- It has a significant user base
- It is an off-the-shelf product, so it might be easily obtained for testing
==> The Jiminy is matching none of the above
Use the new OPENOCD_RESET_USE_CONNECT_ASSERT_SRST to configure
'reset_config connect_assert_srst' when flashing and resetting only.
This removes the need for a special debug configuration and should allow
connecting to a running target again.
When in an invalid state, the board could not flash anymore.
Like for example after flashing `tests/driver_adt7310` this makes it
flash again.
I used `reset_config srst_only` as the other kinetis boards are also
configured that way.
- Nucleo-f091rc can become unflashable when hardfaults occure.
To make sure flashing succeeds `connect_assert_srst` is called
before connecting to flash threw openocd.
