Skip to content
Snippets Groups Projects
Select Git revision
  • fix-warnings
  • master default protected
  • tvbgone-fixes
  • genofire/ble-follow-py
  • schneider/ble-stability-new-phy-adv
  • schneider/ble-stability
  • msgctl/gfx_rle
  • 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
  • schneider/maxim-sdk-update
  • ch3/splashscreen
  • koalo/bhi160-works-but-dirty
  • 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
35 results

serial.c

Forked from card10 / firmware
Source project has a limited visibility.
  • rahix's avatar
    32681478
    fix(serial): Perform serial prints in a critical section · 32681478
    rahix authored
    
    Sometimes during initialization, one `log_msg()` intercepts another one,
    leading to a whole lot of weird issues in other modules (like I2C).  I
    suspect this to be memory corruption of some kind.  The issues can be
    fixed by performing serial prints in a critical section, thus ensuring
    atomicity of prints.  Note that this does not mean log messages will not
    interleave.
    
    The CDC-ACM and BLE-Serial writes cannot be put into a critical section
    and are thus a point where this code can still fail.  For now, however,
    this fix ensures the race-conditions during startup, where USB and BLE
    are not yet running, don't happen anymore.
    
    Signed-off-by: default avatarRahix <rahix@rahix.de>
    Verified
    32681478
    History
    fix(serial): Perform serial prints in a critical section
    rahix authored
    
    Sometimes during initialization, one `log_msg()` intercepts another one,
    leading to a whole lot of weird issues in other modules (like I2C).  I
    suspect this to be memory corruption of some kind.  The issues can be
    fixed by performing serial prints in a critical section, thus ensuring
    atomicity of prints.  Note that this does not mean log messages will not
    interleave.
    
    The CDC-ACM and BLE-Serial writes cannot be put into a critical section
    and are thus a point where this code can still fail.  For now, however,
    this fix ensures the race-conditions during startup, where USB and BLE
    are not yet running, don't happen anymore.
    
    Signed-off-by: default avatarRahix <rahix@rahix.de>