The interval load value was only set to 0xffff regardless of the counter
mode used which mad the 32bit timer apparently stop after 0xffff (it
would never reach values >0xffff).
When a GPTM is configured to one of the 32-bit modes, TAILR appears as a
32-bit register (the upper 16-bits correspond to the contents of the
GPTM Timer B Interval Load (TBILR) register). In a 16-bit mode, the
upper 16 bits of this register read as 0s and have no effect on the
state of TBILR.
Thsi commit set the correct value for TAILR depending on the configured
timer mode.
Previously the setting the alarm would overwrite the overflow callback
and vice versa.
Since we can only set one alarm in hardware, always set the alarm to the
closest event of the two.
This moves the following modules to a architecture-specific Makefile.dep
file:
- cortexm_common
- cortexm_common_periph
- newlib
- newlib_nano
- periph
If only one it is set in state (one GPIO pin caused an interrupt),
don't loop over all 8 bits.
Use clz to get the position of the first interrupt bit and clear it,
looping only as many times as there are actual interrupts.
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
}
We have to read the DR for every byte that we write.
Just reading DR while SPI is busy in a loop can lead to bytes being
left in the fifo, corrupting subsequent reads.
