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.
Seems like the Interrupt flag for a Capture/Compare channel gets set when
- the CC-value is reached
- the timer resets before the CC value is reached.
We only want the first event and ignore the second one. Unfortunately I did
not find a way to disable the second event type, so it is filtered in software.
That is we need to
- ignore the CC-interrupts when the COUNT register register is reset
- ignore the CC-interrupts > TOP value/ARR (auto-reload register)
> A bit-band region maps each word in a bit-band alias region to a single bit in the bit-band region.
> The bit-band regions occupy the lowest 1 MB of the SRAM and peripheral memory regions. A
https://www.mouser.com/datasheet/2/405/lm4f120h5qr-124014.pdf
> Bit-banding is supported in order to reduce the execution time for
> read-modify-write (RMW) operations to memory.
> With bit-banding, certain regions in the memory map
> (SRAM and peripheral space) can use address aliases to access
> individual bits in one atomic operation.
https://www.ti.com/lit/ug/swcu117i/swcu117i.pdf
> Bit-banding is supported in order to reduce the execution time for
> read-modify-write (RMW) operations to memory.
> With bit-banding, certain regions in the memory map
> (SRAM and peripheral space) can use address aliases to access
> individual bits in one atomic operation.
https://www.ti.com/lit/ug/swcu185d/swcu185d.pdf
If we disable an external interrupt, GPIO events that would generate an interrupt will still set the interrupt flag.
That means once we enable the interrupt again, a stale interrupt will be triggered.
This is surprising and probably not what the user wants, unfortunately the API documentation is not very clear about what to expect.
There is however no way to drop those intermediate interrupts with the current API.
Ignoring the events that occurred while the GPIO interrupt were disabled is probably the right (and expected) thing to.
Both tests/pthread_tls and tests/prng_sha256prng fail without this, but
other platforms run fine with their defaults. Lets consider the higher
value a better default.
