NOTICE: Breaking and behavioural changes coming in v1.0.0

[navnavnav]

I'm currently working on v1.0.0.

I'm going to post the draft change notes here, so everyone is aware of the breaking/behavioural changes to come. I will keep this in-sync.

---

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.

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.

• 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.
• Fractional second added to logs.

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.

[navnavnav]

v1.0.0 has now been released. Closing this discussion.