Skip to content
Snippets Groups Projects
Select Git revision
  • schneider/ir
  • master default protected
  • rahix/user-space-ctx
  • schneider/iaq-python
  • schneider/ble-mini-demo
  • schneider/ble-ecg-stream-visu
  • schneider/mp-exception-print
  • schneider/sleep-display
  • schneider/deepsleep4
  • schneider/deepsleep2
  • schneider/deepsleep
  • schneider/ble-central
  • rahix/bluetooth-app-favorite
  • schneider/v1.17-changelog
  • schneider/ancs
  • schneider/png
  • schneider/freertos-list-debug
  • schneider/212-reset-hardware-when-entering-repl
  • schneider/bonding-fail-if-full
  • schneider/ble-fixes-2020-3
  • v1.18
  • v1.17
  • v1.16
  • v1.15
  • v1.14
  • v1.13
  • v1.12
  • v1.11
  • v1.10
  • v1.9
  • v1.8
  • v1.7
  • v1.6
  • v1.5
  • v1.4
  • v1.3
  • v1.2
  • v1.1
  • v1.0
  • release-1
40 results

lifecycle.c

Blame
    • rahix's avatar
      7fb48178
      feat(lifecycle): Allow core 1 to disable interrupts during API calls · 7fb48178
      rahix authored
      When interrupts are disabled during API calls on core 1, we can only
      trigger a core 1 reset when there is no API call ongoing.  This means
      that the lifecycle machinery needs to allow any running API calls to
      complete before it has a chance to see its reset interrupt delivered.
      
      This is complicated because we cannot synchronize on core 1 triggering
      an API call - the best we can do is stop the dispatcher, check whether
      our reset interrupt was delivered, and if not, give it another chance to
      process an API call.
      
      Additionally, "give it another chance to process an API call" means that
      the IDLE task must run, because this is currently a prerequisite to
      scheduling the dispatcher (see [1]).  The only way to facilitate this is
      with a sleep that is long enough that it will eventually let core 0 go
      idle.  It seems that an 8 tick delay does the job quite fine.
      
      Thus, implement a busy loop which provides the above requirements and
      with that makes Epicardium prepared for payloads which perform API calls
      with interrupts disabled.
      
      [1]: https://firmware.card10.badge.events.ccc.de/epicardium/overview.html#internals
      7fb48178
      History
      feat(lifecycle): Allow core 1 to disable interrupts during API calls
      rahix authored
      When interrupts are disabled during API calls on core 1, we can only
      trigger a core 1 reset when there is no API call ongoing.  This means
      that the lifecycle machinery needs to allow any running API calls to
      complete before it has a chance to see its reset interrupt delivered.
      
      This is complicated because we cannot synchronize on core 1 triggering
      an API call - the best we can do is stop the dispatcher, check whether
      our reset interrupt was delivered, and if not, give it another chance to
      process an API call.
      
      Additionally, "give it another chance to process an API call" means that
      the IDLE task must run, because this is currently a prerequisite to
      scheduling the dispatcher (see [1]).  The only way to facilitate this is
      with a sleep that is long enough that it will eventually let core 0 go
      idle.  It seems that an 8 tick delay does the job quite fine.
      
      Thus, implement a busy loop which provides the above requirements and
      with that makes Epicardium prepared for payloads which perform API calls
      with interrupts disabled.
      
      [1]: https://firmware.card10.badge.events.ccc.de/epicardium/overview.html#internals