cc2538 implements 4 sleep modes.
In the lightest mode (3) any interrupt source can wake up the CPU.
In mode 2, only RTT, GPIO or USB may wake the CPU.
In mode 1 only RTT and GPIO can wake the CPU.
In mode 0 only GPIO can wake the CPU.
In mode 0 and 1 the lower 16k RAM are lost. This is a problem since those
are usually used by RIOT.
The linkerscripts in cc2538/ldscripts take different approaches towards that.
Some only use the upper 16k and leave the other half to be managed by the
application.
`cc2538sf53.ld` which is used by `openmote-b` uses the entire RAM starting
at the lower half, so it will not be able to wake up from those modes.
A quick fix to test those modes with `tests/periph_pm` would be
--- a/cpu/cc2538/ldscripts/cc2538sf53.ld
+++ b/cpu/cc2538/ldscripts/cc2538sf53.ld
@@ -21,7 +21,7 @@ MEMORY
{
rom (rx) : ORIGIN = 0x00200000, LENGTH = 512K - 44
cca : ORIGIN = 0x0027ffd4, LENGTH = 44
- ram (w!rx) : ORIGIN = 0x20000000, LENGTH = 32K
+ ram (w!rx) : ORIGIN = 0x20004000, LENGTH = 16K
}
If memarray data is not initialized to 0 (for instance during a
re-init). The last element of the array is not properly cleared thus
leading to returning an invalid pointer when everything is allocated.
This removes the configuration parameters for mrf24j40 and enc28j60
drivers, which were present in the boards's Makefile.dep. There is
already documentation regarding how to correctly configure these devices
for the board.
`netopt_state_t` is an enumeration type which is not necessarily 1 byte. If `uint8_t` is used, the cast `*((const netopt_state_t*) val` in `sx127x_netdev::_set`tries to read the real size, which can be more than the given length of 1 byte. Therefore, `netstat_opt_t` has to be used instead of `uint8_t`
The Nucleo-F103RB comes with an internal SWD programmer/debugger. Thus, the JTAG
pins are not going to be used for debugging / programming anyway. The pins are
exposed on the headers, so allowing them to be used as GPIOs make a lot of
sense.
The Bluepill / Blackpill boards only expose the SWD pins on the debug header,
but the JTAG pins (not also used by SWD) are exposed on the GPIO pin headers.
Hence, exposing them as regular GPIOs seems to be a reasonable choice.
- cpu/stm32f1: Removed previous code in gpio_init() to provide PB4 on the
Nucleo-F103RB only
- cpu/stm32_common: Introduced STM32F1_DISABLE_JTAG which, if defined in
board.h, exposes the JTAG only pins as GPIOs. This keeps the SWD pins, so that
SWD debugging remains possible
When an IRQ is lost during cc110x_send(), the driver will remain locked until
another IRQ is triggered. This commit changes the behavior to wait for at most
an reasonable upper bound, which is chosen to not only allow the driver to
recover but also (at least in theory) complete the transmission correctly.
