The CC26x2 and CC13x2 share the same register definitions, and both are
treated equally in the TI's technical reference manual. [1]
- To avoid confusions in the future I renamed it to `cc26x2_cc13x2`.
- Documentation was updated.
- The `cc1312-launchpad` board that uses the `cc13x2` MCU was updated.
- The `cc1352-launchpad` board that uses the `cc13x2` MCU was updated.
[1]: https://www.ti.com/lit/ug/swcu185d/swcu185d.pdf
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
This implements the randomization of canary values on each build as
mentioned in the comment above the STACK_CHK_GUARD macro. The canary
value is generated by the buildsystem and passed to the ssp module using
a `-D` compiler flag. The ssp object file, using this canary value, is
marked as PHONY to make sure it is rebuild on each make invocation,
thereby ensuring that each build uses a new random canary value.
Implementing this properly would require generating a cryptographically
secure random value on each boot of the RIOT operating system. This is
not deemed possible on some constrained devices, e.g. due to lack of
hardware random number generators. Besides, RIOT only seems to support a
PRNG (random module) currently. While this may be implemented in the
future for some devices the changes implemented in this commit may still
be used as a fallback then.
A hardcoded canary value is used when building software on the CI to not
break the CI test cache [1].
[1]: https://github.com/RIOT-OS/RIOT/pull/13119#issuecomment-574132932
This tool generates a random hexadecimal value of a given maximum size.
This is useful for generating random canary values during compile-time
for the ssp module which currently uses a constant value.
This is used now to set the `DEBUGSSERVER` as the `gdb_agent_console`
file was removed from UniFlash.
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
This is mostly based on the cc1352-launchpad boards, is essentially the same
buttons and leds pins, what changes is the CCXML files used to flash with
`make flash` and the UART pins.
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
Fixes i-nucleo-lrwan1 board name in the BOARD_WITHOUT_LORAMAC_RX which disables the RX function of pkg/semtech_loramac and saves 1302 bytes RAM and about 2 kByte of code.
For the ATmega platform the ADC lines are not defined according to the GPIOs. Instead, they are defined from 0 to ADC_NUMOF-1, which in turn represents the bit in the corresponding ADC registers. The mapping from the line number to the corresponding ADC register/bit combination is done implicitly by the periph/adc implementation.
The reassembly buffer only needs (and stores) the headers *before* the
fragment header (called per-fragment headers in RFC 8200, section 4.5).
Currently, when a subsequent IPv6 fragment is received before the first
fragment the fragment header is however not removed. With this fix it
does.