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.