nanostack-hal: add alternative critical section implementation #6185
Conversation
|
Would something like this be better? |
|
I think that's reasonable. Can't really write an essay in there. |
The nanostack hal's critical section uses a mutex for mutual exclusion, which is nice for many use cases. But when one needs to use the critical section from interrupts, the RTX will have a assertion failure and panic. Add a configurable for mbed_lib, which can be used to enable a alternative version of critical section, which uses the underlying OS primitives, which disables the interrupts. Note: the default behavior is not changed, one needs to override the "nanostack-hal.critical-section-usable-from-interrupt" to have "true". Reason for this change is that there is a need for sending events using nanostack event queue from interrupt context, eg. from a socket callback.
5643dea to
7bfcf69
Compare
|
Fixed the JSON documentation. It is unfortunate that help in JSON string needs to be a one line inside quotes. |
|
/morph build |
Build : SUCCESSBuild number : 1261 Triggering tests/morph test |
Exporter Build : FAILUREBuild number : 926 |
|
/morph export-build |
Exporter Build : SUCCESSBuild number : 937 |
Description
(This PR has the same content as already merged https://github.com/ARMmbed/mbed-os-confidential-m/pull/8 and
#5754, only the target branch differs)
The nanostack hal's critical section uses a mutex for mutual exclusion,
which is nice for many use cases. But when one needs to use the critical
section from interrupts, the RTX will have a assertion failure and panic.
Add a configurable for mbed_lib, which can be used to enable a alternative
version of critical section, which uses the underlying OS primitives, which
disables the interrupts.
Note: the default behavior is not changed, one needs to override the
"nanostack-hal.critical-section-usable-from-interrupt" to have "true".
Reason for this change is that there is a need for sending events using
nanostack event queue from interrupt context, eg. from a socket callback.
Status
READY
Migrations
YES | NO
Related PRs
Todos
Deploy notes
Note: this should not be the first and/or only fix, as it may cause troubles on drivers which can not tolerate delays on interrupt deliveries.
Steps to test or reproduce
K64F with ESP8266, debug profile:
"Mutex 0x200017ec error -6: Not allowed in ISR context"