A debug interface for AVR-based embedded systems development on GNU/Linux.
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.
avr8 target has been removed - you must now specify the exact target name in your project configuration file.enabled Insight config parameter has been removed. See the activateOnStartup parameter.releasePostDebugSession debug tool config parameter has been removed. If you want Bloom to give up control of the debug tool, trigger a shutdown.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.debugTool configuration key (in bloom.yaml) has been renamed to tool.debugServer configuration key (in bloom.yaml) has been renamed to server.monitor insight GDB command. This behaviour can be changed via the new activateOnStartup insight config parameter.shutdownOnClose insight config parameter.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 the following targets is included in this release:
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
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).
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).
preserveEeprom function to make use of the target's EESAVE fuse bit, which is faster than the backup-erase-restore approach.EXCLUDE_INSIGHT parameter. See the root README.md for more.debugLoggingEnabled parameter to debugLogging. The old name is still accepted, for now.0x00810000 offset must be applied to EEPROM addresses.monitor eeprom fill command, to fill EEPROM with a given value.Support for the following targets is included in this release:
See https://bloom.oscillate.io/docs/supported-targets for target config values.
preserveEeprom AVR8 target config boolean parameter, to control the backup-then-restore function employed for JTAG and UPDI targets. Setting this to false will improve upload times for those who don't care about losing EEPROM data when uploading program changes.manageOcdenFuseBit AVR8 target config boolean parameter. See https://bloom.oscillate.io/docs/configuration
YAML parsing exceptions were not being properly handled Exceptions thrown by the yaml-cpp library, when processing the user's project configuration file (bloom.yaml), were not being handled properly. This was resulting in syntax errors in bloom.yaml causing Bloom's process to unexpectedly abort.
Intermittent 'illegal target state' error on AVR8 targets, after a target reset After resetting an AVR8 target, the EDBG debug tool would sometimes report an 'illegal target state' error in response to any command that was sent immediately after receiving the break event (triggered by the reset). It seems as if the target is not fully reset (or stopped?), even after the point of receiving the break event. This was fixed by ensuring that the target is given some time after a reset, before sending any other commands.
Incorrect value annotation font style in hex viewer Due to a bug in the AnnotationItem class, annotation item labels were not being rendered correctly. This issue was intermittent.
init command will now produce a YAML configuration file (bloom.yaml).updateDwenFuseBit AVR8 config param to manageDwenFuseBit. The old param is still supported but will be removed in a later release.monitor commandmonitor svd - Generates SVD and outputs to a file in the project directory.monitor svd --out - Generates SVD and sends the output to GDB, to display as command output. GDB front-ends (IDEs) can utilise this without requiring any user action.monitor target-info machine command has been removed.avr8 target name will disable Bloom's ability to perform this check.Bloom can now write to the target's program memory. GDB's load command can be used to program the target. Bloom users no longer need to rely on other software to apply code changes during their debug sessions.
GDB generating invalid backtraces for debugWire sessions Bloom was incorrectly applying an offset to all paged flash memory reads. This meant that it was reading the wrong areas in memory. This was resulting in GDB generating invalid backtraces. This bug only affected debugWIre sessions. See https://github.com/navnavnav/Bloom/issues/40
GDB attempting to access flash memory at invalid addresses
Bloom was not providing GDB with a target memory map, so GDB would attempt to access flash memory at invalid addresses. Bloom now supports the qXfer:memory-map:read:: GDB command packet - meaning we now provide GDB with a memory map upon request.
This release includes significant changes to Bloom's internals. Although best efforts have gone into testing the release, users may face some issues as a result of the changes. In the event that you come across any issues, please report them as soon as possible.
For configuration values, see https://bloom.oscillate.io/docs/configuration#debug-tool-target-config
monitor GDB command)monitor help - Displays help text, describing the supported monitor commands.monitor version - Displays Bloom's version number.monitor version machine - Outputs Bloom's version number in JSON format.monitor target-info machine - Outputs information on the connected target, in JSON format.monitor reset - Resets the target and holds it in a stopped state. See https://github.com/navnavnav/Bloom/issues/24 for more.--version-machine CLI command - Outputs Bloom's version number in JSON format.