094d9ac909
ticker_insert_event() can crash on KLXX (and probably other platforms) if an event is inserted with a timestamp before the current real time. The problem is easy to trigger: you just need to set up a Ticker object, and then disable interrupts for slightly longer than the Ticker object's interval. It's generally bad practice to disable interrupts for too long, but there are some cases where it's unavoidable, and anyway it would be better for the core library function not to crash. The case where I had an unavoidably long interrupts-off interval was writing flash with the FTFA. The FTFA hardware prohibits flash reads while an FTFA command is in progress, so interrupts must be disabled for the whole duration of each command to ensure that there are no instruction fetches from flash-resident ISRs in the course of the execution. An FTFA "erase sector" command takes a fairly long time (milliseconds), and I have a fairly high frequency Ticker (1ms). The problem and the fix are pretty straightforward. ticker_insert_event() searches the linked list to figure out where to insert the new event, looking for a spot earlier than any event currently queued. If the event is in the past, it'll usually end up at the head of the list. When the routine sees that the new event belongs at the head of the list, it calls data->interface->set_interrupt() to schedule the interrupt for the event, since it's the new soonest event. The KLXX version of us_ticker_set_interrupt() then looks to see if the event is in the past, which we've stipulated that it is, so rather than actually setting the interrupt, it simply calls the handler directly. The first thing the Ticker interrupt handler does is re-schedule itself, so we re-enter ticker_insert_event() at this point. This is where the problem comes in: we didn't finish updating the linked list before we called set_interrupt() and thus before we recursed back into ticker_insert_event(). We set the head of the list to the new event but we didn't set the new event's 'next' pointer. The fix is simply to finish updating the list before we call set_interrupt(), which we can do by moving the obj->next initialization ahead of the head pointer update. |
||
|---|---|---|
| .github | ||
| TESTS | ||
| cmsis | ||
| drivers | ||
| events | ||
| features | ||
| hal | ||
| platform | ||
| rtos | ||
| targets | ||
| tools | ||
| .gitattributes | ||
| .gitignore | ||
| .pylintrc | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| DOXYGEN_FRONTPAGE.md | ||
| Jenkinsfile | ||
| LICENSE | ||
| README.md | ||
| mbed.h | ||
| requirements.txt | ||
README.md
ARM mbed OS
mbed OS is an open-source embedded operating system designed specifically for the "things" in the Internet of Things (IoT). It includes all the features you need to develop a connected product based on an ARM Cortex-M microcontroller.
mbed OS accelerates the process of creating a connected product by providing a platform operating system that includes robust security foundations, standards based communication capabilities, built-in cloud management services, and drivers for sensors, I/O devices and connectivity. mbed OS is built as a modular, configurable software stack so that you can readily customize it to the device you're developing for, and reduce memory requirements by excluding unnecessary software components.
Current release
The current release, along with a selection of previous versions are detailed here: Release Notes
Getting Started for Developers
Please note that you will require mbed CLI to build mbed OS. For more details, please read the getting started guide for developers using mbed OS in applications:
Getting Started for Contributors
We have a getting started guide for contributors working on mbed OS:
- Have a look in the docs directory