On some platforms, if low power ticker interrupt is set to very close value (e.g. timestamp < current tick + 3), then interrupt may not fire. This is one use case of lp ticker wrapper, but not all platforms use the wrapper. Some platforms cheat a bit and in this case, simply schedules interrupt a bit later. The problem has been found while working on the low-level lp ticker wrapper for ST boards which run lp ticker using LPTIM. These platforms have such limitation.
Failing test: tests-mbed_drivers-lp_timeout (Test Case: Zero delay)
In the test scenarion, the lp ticker callback is attached with 0.0 s delay in the loop. The new events are put in the front of the lp ticker event list and interrupt reschedule is performed. Usually, the new event is already expired, interrupt fires immediately and next event from the list is then scheduled (e.g. system tick). When the next event (e.g. system tick) is very close to the current time it might be scheduled a bit later (because of lp ticker limitation). Let's assume that system tick has been delayed by 3 ticks and while inserting new zero delay event, absolute system tick time on the event list has already expired. In this case, zero delay event may be added after the expired system tick event and no reschedule is performed (because the head of the list has not changed). Interrupt also didn't fire yet since it has been delayed, so after return from attach_callback(0) we are still waiting for the delayed interrupt and zero delay callback has not been called instantly.
This may also affect other platforms which use such delays (Cypress, NORDIC, etc.).
The proposition is to add extra condition while adding an event to the event list. If the inserted event is already expired, then perform reschedule immediately.
In case the CThunk object is deleted without having called the
entry() function (and thus _entry is NULL), cthunk_free_real()
will fail with an assertion.
Lots of target code, STM in particular, uses the `register` keyword, so
it'll take a little while to clean up. In the interim, some builds are
producing a lot of warnings. Suppress the warning for now, as `register`
remains legal C++14 and C11, despite C++14 deprecating it.
C++17 removes `register`, so code will need to be cleaned before any
further C++ version update.
Add a pulse when using hardware chip select for SPI transmissions.
CS is at low level when a transmission is on-going.
Be careful, this is not compatible with all modes. It will work only
if PHA is 0, ie spi mode is 0 or 2. See stm32xx reference manual,
chapter "NSS pulse mode" for more details.
Fix#10671
Signed-off-by: Vincent Veron <vincent.veron@st.com>
Fix LWIP warning issues found by Coverity scan
lwip_dns.c in function: dns_add_interface_server
CID 1399051 (#1 of 1): Buffer not null terminated (BUFFER_SIZE_WARNING)10. buffer_size_warning: Calling strncpy with a maximum size argument of 6 bytes on destination array new_interface_server->interface_name of size 6 bytes might leave the destination string unterminated.
line 434 strncpy(new_interface_server->interface_name, interface_name, INTERFACE_NAME_MAX_SIZE);
lwip_ip4_frag.c in function: ip_reass_free_complete_datagram
CID 1373164 (#1 of 1): Dereference after null check (FORWARD_NULL)7. var_deref_model: Passing null pointer prev to ip_reass_dequeue_datagram, which dereferences it. [show details]
line 209 ip_reass_dequeue_datagram(ipr, prev);
lwip_ip4_frag.c in function: ip_reass
CID 1373163 (#1-2 of 2): Dereference after null check (FORWARD_NULL)38. var_deref_model: Passing null pointer ipr_prev to ip_reass_dequeue_datagram, which dereferences it. [show details]
line 663 ip_reass_dequeue_datagram(ipr, ipr_prev);
lwip_api_msg.c in function: lwip_netconn_do_connected
CID 1373162 (#1 of 1): Explicit null dereferenced (FORWARD_NULL)10. var_deref_model: Passing null pointer op_completed_sem to sys_sem_signal, which dereferences it. [show details]
line 1336 sys_sem_signal(op_completed_sem);
On some targets like STM family boards with LPTIM enabled an interrupt is triggered on counter rollover.
We need special handling for cases when next_match_timestamp < start_timestamp (interrupt is to be fired after rollover).
In such case after first wake-up we need to reset interrupt and go back to sleep waiting for the valid one.
On some targets like STM family boards with LPTIM enabled there is a required delay (~100 us) before we are able to reprogram LPTIM_COMPARE register back to back.
This is handled by the low level lp ticker wrapper which uses LPTIM_CMPOK interrupt. CMPOK fires when LPTIM_COMPARE register can be safely reprogrammed again.
This means that on these platforms we have additional interrupt (CMPOK) fired always ~100 us after programming lp ticker.
Since this interrupt wake-ups the board from the sleep we need to go to sleep after CMPOK is handled.
Background:
There is an errata in LPTIM specification that explains that CMP Flag
condition is not an exact match (COUNTER = MATCH) but rather a
comparison (COUNTER >= MATCH).
As a consequence the interrupt is firing early than expected when
programing a timestamp after the 0xFFFF wrap-around.
In order to
work-around this issue, we implement the below work-around.
In case timestamp is after the work-around, let's decide to program the
CMP value to 0xFFFF, which is the wrap-around value. There would anyway be
a wake-up at the time of wrap-around to let the OS update the system time.
When the wrap-around interrupt happen, OS will check the current time and
program again the timestamp to the proper value.
toyowata
Lingkai Dong
Martin Kojtal
petroborys
Vincent Coubard
Maciej Bocianski
Antti Kauppila
Przemyslaw Stekiel
Teijo Kinnunen
Qinghao Shi
David Saada
Hennadiy Kytsun
Kevin Bracey
Vincent Veron
Chun-Chieh Li
Chris Trowbridge
George Psimenos