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.
- Nucleo-f091rc can become unflashable when hardfaults occure.
To make sure flashing succeeds `connect_assert_srst` is called
before connecting to flash threw openocd.
The boards are using `pyterm` specific options that do not work on any
other `RIOT_TERMINAL`. It is a shame this is required but at least do
not pass arbitrary arguments to the other RIOT_TERMINAL.
So use the new PYTERMFLAGS for this.
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.
- Removed cc110x driver
- Updated all makefiles
- Kept both board specific configurations and support for it in RIOT's
upper layers, so re-implementations don't need to start from zero
softdevice needs the memory at 0x2000 to be initialized to 0xffffffff
according to #5893 and testing. However, the addresses [0x8bc, 0x3000[ are not
set in softdevice.hex.
So use a modified hex file with all the memory set to 0xff as it is the rom
reset value anyway.
This change updates the `.hex` file instead on relying on erasing the
memory.
When running tests using 'nordic_softdevice_ble', the 'softdevice.hex'
file must also be taken into account for the test hashing and be
uploaded to the separated murdock testing boards.
When listed as dependency from `test-input-hash` the file must have a
target, which he has not. The file is implicitly created when compiling
`ELFFILE` so declare it as order only dependency.
In practice `BASELIBS` could be enough or even `pkg-build-softdevice`
but I do not want to be depend that much on internals there.
