Skip to content

Bloom v1.0.0

Latest
Compare
Choose a tag to compare
@navnavnav navnavnav released this 26 Sep 13:31
· 11 commits to master since this release

Major release


This release contains breaking and behavioural changes. If you're upgrading from a previous version of Bloom, you'll need to carefully consider the changes made in this release. Please follow the instructions provided in the migration tutorial.

Breaking changes

  • JSON project configuration files (bloom.json) are no longer supported.
  • The avr8 target has been removed - you must now specify the exact target name in your project configuration file.
  • The enabled Insight config parameter has been removed. See the activateOnStartup parameter.
  • The releasePostDebugSession debug tool config parameter has been removed. If you want Bloom to give up control of the debug tool, trigger a shutdown.
  • The old updateDwenFuseBit AVR8 config parameter was renamed to manageDwenFuseBit in version 0.11.0. The old parameter name was still accepted, but has been removed in this release.
  • The debugTool configuration key (in bloom.yaml) has been renamed to tool.
  • The debugServer configuration key (in bloom.yaml) has been renamed to server.

Behavioural changes

  • By default, the Insight GUI will no longer activate on startup. It can be activated, on-demand, via the new monitor insight GDB command. This behaviour can be changed via the new activateOnStartup insight config parameter.
  • Closing the Insight window will no longer trigger a shutdown. This behaviour can be changed via the new shutdownOnClose insight config parameter.
  • Bloom will no longer go into a suspended state when control of the debug tool is lost. Instead, it will just shutdown abruptly.

New Insight config parameters:

insight:
  activateOnStartup: false # <- If true, the Insight GUI will be activated immediately after startup (which is what it used to do, prior to v1.0.0).
  shutdownOnClose: false # <- If true, Bloom will shutdown when the user closes the main Insight window (which is what it used to do, prior to v1.0.0).

Support for additional AVR-DD targets

  • Support for the following targets is included in this release:

    • AVR16DD14 (untested)
    • AVR16DD20 (untested)
    • AVR16DD28 (untested)
    • AVR16DD32 (untested)
    • AVR32DD14 (untested)
    • AVR32DD20 (untested)
    • AVR32DD28 (untested)
    • AVR32DD32 (untested)

Hardware breakpoints

  • Bloom will now make use of any hardware breakpoints available on the target.

  • Once all hardware breakpoint resources have been exhausted, Bloom will fall back to software breakpoints.

  • This functionality can be disabled via the new hardwareBreakpoints target config param:

    target:
      name: "atmega4809"
      physicalInterface: "updi"
      hardwareBreakpoints: false # <-- Setting this param to false will disable Bloom's use of HW breakpoints.
  • This functionality is enabled by default (hardwareBreakpoints defaults to true).

  • Upon target activation, Bloom will report the number of available hardware breakpoints on the target:

    2023-09-20 20:36:45.768 BST [TC] [52]: [INFO] Target activated
    2023-09-20 20:36:45.768 BST [TC] [53]: [INFO] Target ID: 0x1e9651
    2023-09-20 20:36:45.768 BST [TC] [54]: [INFO] Target name: ATmega4809
    2023-09-20 20:36:45.768 BST [TC] [55]: [INFO] Available hardware breakpoints: 1
    2023-09-20 20:36:45.809 BST [DS] [58]: [INFO] Starting DebugServer
    

Program memory caching

  • Bloom will now cache the target's program memory

  • This functionality can be enabled/disabled via the new programMemoryCache target config param:

    target:
      name: "atmega4809"
      physicalInterface: "updi"
      programMemoryCache: false # <-- Setting this param to false will disable program memory caching.
  • This functionality is enabled by default (programMemoryCache defaults to true).

  • Users should disable this if their application can update program memory (e.g. bootloaders).

Range stepping

  • Bloom is now able to decode and analyse AVR8 opcodes from the target's program memory. This enables the ability to perform range stepping on the target, where GDB will instruct Bloom to step within a PC range and only halt target execution when it goes out of the given range.

  • Bloom will use breakpoints (hardware or software) to intercept any instructions within the given range, that may result in the target leaving the range.

  • In most cases, this results in improved stepping performance. There's at least one known case where this can have a negative effect on stepping performance. See http://bloom.oscillate.io/docs/limitations#stepping-performance for more.

  • This functionality can be enabled/disabled via the new rangeStepping server config param:

    server:
      name: "avr-gdb-rsp"
      ipAddress: "127.0.0.1"
      port: 1442
      rangeStepping: true # <-- Setting this param to true will enable range stepping.
  • This functionality is enabled by default (rangeStepping defaults to true).

Other changes

  • Changed implementation of preserveEeprom function to make use of the target's EESAVE fuse bit, which is faster than the backup-erase-restore approach.
  • The Insight component can be removed at build time, via the EXCLUDE_INSIGHT parameter. See the root README.md for more.
  • Added key press event handlers to some Insight windows.
  • Added change list in snapshot diff window.
  • Fractional second added to logs.
  • Renamed debugLoggingEnabled parameter to debugLogging. The old name is still accepted, for now.

Bug fixes

  • The size of the main Insight window was not being properly restored on startup.
  • Missing includes resulting in failing builds with GCC 13+, reported and fixed by @jpf91
  • Breakpoints set by GDB were not being restored after a programming session. This was only noticeable when GDB was configured to keep breakpoints inserted.