Skip to content
Snippets Groups Projects
Select Git revision
  • esp32-nimble-wiki
  • rahix/hw-lock-new-mutex
  • master default protected
  • dx/somewhat-more-dynamic-config
  • schneider/sdk-0.2.1-7
  • schneider/bsec
  • dx/meh-bdf-to-stm
  • dx/flatten-config-module
  • genofire/ble-follow-py
  • schneider/ble-stability
  • schneider/ble-stability-new-phy
  • add_menu_vibration
  • plaetzchen/ios-workaround
  • blinkisync-as-preload
  • schneider/max30001-pycardium
  • schneider/max30001-epicaridum
  • schneider/max30001
  • schneider/stream-locks
  • schneider/fundamental-test
  • schneider/ble-buffers
  • 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
  • bootloader-v1
  • v0.0
36 results

modules.h

Blame
  • Forked from card10 / firmware
    Source project has a limited visibility.
    • rahix's avatar
      1536da34
      feat(epicardium): Add a panic() function · 1536da34
      rahix authored
      
      In unrecoverable situations we should provide a common way to output the
      cause of the error and then reset the CPU.  The panic() function is
      mean to be exactly that.  It outputs the error-cause, stack-trace, and
      firmware revision, accompanied by a link to the issue-tracker to
      encourage people to report the error.  After a timeout of ~1.5s it
      resets the CPU and reboots.
      
      Future Work:
      
       - Right now, the stack-trace only has a depth of one which is the
         return address from where panic() was called.  In the future it might
         make sense to provide a deeper stack-trace if a robust implementation
         is possible.
       - Integration of @msgctl's faultscreen (!79) so users who don't have
         the serial console open at all times can also see what happened.
      
      Signed-off-by: default avatarRahix <rahix@rahix.de>
      Verified
      1536da34
      History
      feat(epicardium): Add a panic() function
      rahix authored
      
      In unrecoverable situations we should provide a common way to output the
      cause of the error and then reset the CPU.  The panic() function is
      mean to be exactly that.  It outputs the error-cause, stack-trace, and
      firmware revision, accompanied by a link to the issue-tracker to
      encourage people to report the error.  After a timeout of ~1.5s it
      resets the CPU and reboots.
      
      Future Work:
      
       - Right now, the stack-trace only has a depth of one which is the
         return address from where panic() was called.  In the future it might
         make sense to provide a deeper stack-trace if a robust implementation
         is possible.
       - Integration of @msgctl's faultscreen (!79) so users who don't have
         the serial console open at all times can also see what happened.
      
      Signed-off-by: default avatarRahix <rahix@rahix.de>