bloombloombloom / bloom Goto Github PK

View Code? Open in Web Editor NEW

64.0 64.0 3.0 80.47 MB

A debug interface for AVR-based embedded systems development on GNU/Linux.

Home Page: https://bloom.oscillate.io/

License: Other

CMake 2.19% Shell 0.41% PHP 3.79% C++ 93.61%

atmel atmel-avr avr clion cmsis-dap embedded embedded-systems gdb gdb-rsp-server linux microchip microcontroller

bloom's People

Contributors

Stargazers

Watchers

Forkers

ech1965 kaml123 jpf91

bloom's Issues

Provide machine readable target register information to GDB frontends (IDEs)

Some IDEs (like CLion) allow users to provide an SVD file, from which the IDE will extract target information. To make things easier, it would be nice if Bloom could provide these IDEs with the information they require.

Work began on this in version 0.9.0, where GDB monitor commands were added to allow IDEs to extract information from Bloom. In response to these commands, Bloom will output the requested information in JSON format. The commands can be issued at any point during a debug session with Bloom.

The version machine command:

(gdb) monitor version machine
{
    "components": {
        "major": 0,
        "minor": 9,
        "patch": 0
    },
    "version": "0.9.0"
}

The target-info machine command:

(gdb) monitor target-info machine
{
    "target": {
        "id": "0x1e950f",
        "memoryDescriptors": [
            {
                "addressRange": {
                    "endAddress": 32767,
                    "startAddress": 0
                },
                "name": "Flash",
                "size": 32768
            },
            {
                "addressRange": {
                    "endAddress": 2303,
                    "startAddress": 256
                },
                "name": "RAM",
                "size": 2048
            },
            {
                "addressRange": {
                    "endAddress": 1023,
                    "startAddress": 0
                },
                "name": "EEPROM",
                "size": 1024
            }
        ],
        "name": "ATmega328P"
    }
}

I now want to extend these commands to include information on target registers. I'm not sure if this will be a separate command like register-info machine, or just included in the response to the target-info machine command. The register information will include names, descriptions, plain addresses, sizes, addresses with relevant offsets applied for access via avr-gdb, readable and writable flags, value endianness, etc.

This would be a nice way to provide IDEs with the information they need to provide a better experience for Bloom users. I will also document each command on the Bloom website, at some point, for IDE developers to use as a reference.

Not sure when I'll get onto this. It will likely be looked at after support for programming is completed.

JTAGICE3 supported?

Hi,

I am not trying to connect to an ATxmega128D3 target, using JTAGICE3 from Atmel.
Is this a supported debugger? I could find the vid:pid definition in the 99-bloom.rules file, but no references to it in the code.

Thanks,
Maxime

Flash page size for target (512 bytes) exceeds maximum memory access size for EdbgAvr8Interface (256 bytes)

While trying to connect to an ATXMEGA128A1U target, I am getting the following error:

Flash page size for target (512 bytes) exceeds maximum memory access size for EdbgAvr8Interface (256 bytes)

This is my bloom.json:

{
  "environments": {
    "default": {
      "debugTool": {
        "name": "xplained-pro",
        "releasePostDebugSession": true
      },

      "target": {
        "name": "atxmega128a1u",
        "physicalInterface": "jtag"
      },

      "debugServer": {
        "name": "avr-gdb-rsp",
        "ipAddress": "127.0.0.1",
        "port": "1442"
      }
    }
  },

  "insight": {
    "enabled": true
  }
}

I tried both pdi and jtag as physicalInterface configs, but the error remains the same.

Distribute Bloom in RPM package

Bloom is currently distributed via a Debian package. Users of non-debian based distributions are unable to install the prebuilt Bloom package. They are forced to build Bloom from source, which isn't ideal.

It would be nice if we could maintain an RPM package along with a Debian one.

I probably won't begin work on this until there is evidence of demand. Please add a reaction or leave a comment on this issue, if this is something you want.

Implement device driver for Microchip Xplained Pro development boards

The Microchip Xplained Pro development board comes with an embedded debugger, accessible over USB. The debugger appears to be EDBG-based, so we should be able to use the EdbgAvr8Interface for interfacing with AVR8 targets.

See https://www.microchip.com/development-tools/xplained-boards for more on the Xplained Pro boards.

KDE Plasma is not respecting Bloom's minimum window size

This isn't a bug with Bloom. The purpose of this ticket is to just keep track of the issue.

There appears to be an issue with KDE Plasma. Minimum window sizes are not being respected, and this is causing some of Bloom's widgets to overlap (due to fixed minimum sizes of other widgets):

Someone has already reported the bug: https://bugs.kde.org/show_bug.cgi?id=454827

The overlapping only occurs when the window's size is reduced by too much. Can easily be avoided by keeping the window size above that threshold.

Implement the ISP interface for a better experience with debugWire

Currently, Bloom can only interface with AVR8 targets using the AVR8 Generic EDBG protocol.

For targets with a debugWire module, a fuse known as "DWEN" (debugWire enable) must be set in order to activate the module and perform debugging operations on the target. This fuse cannot be set via the AVR8 Generic protocol.

Because Bloom is unable to set this fuse, responsibility to set the fuse and (ensure that it remains set) lies with the user. This means the user has to set the fuse each time after programming the target via ISP (if they wish to perform debugging operations).

AVRDUDE used to help with this by temporarily disabling the debugWire module, before employing the ISP protocol to interface with the target. This meant that the user could simply reactivate the debugWire module by cycling the power to the target. But this function in AVRDUDE appears to no longer work (see #16 for more on that).

In an ideal world, Bloom should be able to control the state of the debugWire module without relying on the use of other software. This would result in a seamless user experience with debugWire targets. It can be done via the implementation of the ISP protocol. With this implementation, Bloom will be able to connect to the target via SPI and set/clear the DWEN fuse automatically.

Not sure when I'll be able to start work on this. Will update the ticket as and when necessary.

Bloom does not operate properly with CLion 2022.1 (due to lack of memory address validation)

When debugging in CLion 2022.1, GDB & CLion end up in an endless loop when attempting to generate a backtrace, once target execution comes to a stop. CLion repeatedly requests stack frames from GDB, but GDB fails to identify the outermost frame, so it ends up walking down the stack, reading two bytes at a time, attempting to identify the outermost frame. And because GDB isn't aware of the target's RAM size, it doesn't know when to stop walking down the stack (keep in mind that the stack on AVR targets starts at the top of the RAM, so walking down the stack means walking up the RAM).

This issue results in CLion's debugger becoming very slow or unresponsive (as it waits for GDB), and no longer usable.

Observing avr-gdb's input, when run under CLion 2022.1, we have the following:

-gdb-set print elements 256
-gdb-set print repeats 0
-gdb-set print object on
-gdb-set print asm-demangle on
-gdb-set python print-stack full
-gdb-set backtrace past-main on
-gdb-set backtrace past-entry on
-gdb-show mi-async
-gdb-set mi-async on

So CLion is configuring GDB to include frames before the entry point of the application (via the -gdb-set backtrace past-entry on command). This is why GDB isn't stopping at the frame preceding main() (which it used to do, with CLion 2021.1 - because that version of CLion only enabled backtrace past-main, and not backtrace past-entry.).

This isn't an issue with CLion. In fact, it has exposed an issue with Bloom. Bloom is not properly validating memory addresses sent by GDB, in memory access command packets. This means we're currently allowing GDB to request any memory address it likes, even if that address is outside of the target's memory boundary. Also, the debug tools don't seem to care about this either; If you attempt to read memory at an address outside of the target's memory boundary, the debug tool just returns 0xFF for each byte. I believe this is why GDB is failing to identify the outermost frame (or at least partially why).

We need to ensure that Bloom does not permit GDB to access any memory at an invalid address. This should prevent GDB from attempting to find frames where none exist.

Add option to automatically shutdown Bloom at the end of a debug session

Bloom was designed to stay running through numerous debug sessions, but there are some instances where users may wish to have Bloom shutdown automatically, once their debug session has finished.

I'm looking to have this function configurable via a config parameter.

Bloom issuing incorrect flash reads on debugWire targets

I have noticed a bug where Bloom is incorrectly paging flash memory reads. This bug is resulting in GDB generating invalid backtraces. The bug only affects debugWire sessions.

Should have a fix ready soon.

libGL error: MESA-LOADER...

First, see my note in Discussions as to success!
Second, I did have this error occur, however, it didn't seem to affect the loading of programs. I haven't fully tested 0.10 and Insight, so I might be able to report more by the end of the week.

Here is the console where the error occurred:

2022-06-29 11:30:18 PDT [TC] [34]: [INFO] Reading target signature via ISP
2022-06-29 11:30:18 PDT [TC] [35]: [INFO] Target signature confirmed: 0x1e950f
2022-06-29 11:30:18 PDT [TC] [36]: [INFO] Current SPIEN fuse bit value confirmed
2022-06-29 11:30:18 PDT [TC] [37]: [INFO] Cleared lock bits confirmed
2022-06-29 11:30:18 PDT [TC] [38]: [WARNING] Programming DWEN fuse bit
2022-06-29 11:30:19 PDT [TC] [39]: [INFO] DWEN fuse bit successfully updated
2022-06-29 11:30:19 PDT [TC] [40]: [INFO] Retrying debugWire physical interface activation
2022-06-29 11:30:19 PDT [TC] [41]: [INFO] Target activated
2022-06-29 11:30:19 PDT [TC] [42]: [INFO] AVR8 target promoted to megaAVR target
2022-06-29 11:30:20 PDT [TC] [58]: [INFO] Target ID: 0x1e950f
2022-06-29 11:30:20 PDT [TC] [59]: [INFO] Target name: ATmega328P
2022-06-29 11:30:20 PDT [DS] [62]: [INFO] Starting DebugServer
2022-06-29 11:30:20 PDT [DS] [63]: [INFO] Selected DebugServer: AVR GDB Remote Serial Protocol Debug Server
2022-06-29 11:30:20 PDT [DS] [64]: [INFO] GDB RSP address: 127.0.0.1
2022-06-29 11:30:20 PDT [DS] [65]: [INFO] GDB RSP port: 1442
2022-06-29 11:30:20 PDT [DS] [69]: [INFO] DebugServer ready
2022-06-29 11:30:20 PDT [DS] [70]: [INFO] Waiting for GDB RSP connection
2022-06-29 11:30:20 PDT [MT] [71]: [INFO] Starting Insight
libGL error: MESA-LOADER: failed to open crocus: /opt/bloom/bin/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /usr/lib/dri/crocus_dri.so) (search paths /usr/lib/dri, suffix _dri)
libGL error: failed to load driver: crocus
libGL error: MESA-LOADER: failed to open crocus: /opt/bloom/bin/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /usr/lib/dri/crocus_dri.so) (search paths /usr/lib/dri, suffix _dri)
libGL error: failed to load driver: crocus
libGL error: MESA-LOADER: failed to open swrast: /opt/bloom/bin/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /usr/lib/dri/swrast_dri.so) (search paths /usr/lib/dri, suffix _dri)
libGL error: failed to load driver: swrast
2022-06-29 11:30:20 PDT [MT] [75]: [INFO] Insight ready
2022-06-29 11:31:03 PDT [DS] [79]: [INFO] Accepted GDP RSP connection from 127.0.0.1
2022-06-29 11:31:12 PDT [TC] [160]: [WARNING] Programming mode enabled
2022-06-29 11:31:16 PDT [TC] [185]: [INFO] Programming mode disabled
2022-06-29 11:34:20 PDT [TC] [290]: [WARNING] Programming mode enabled
2022-06-29 11:34:23 PDT [TC] [315]: [INFO] Programming mode disabled

The last four lines were successful connections with the target.

Your thoughts?

Thanks,
Lief

AVR8 Activate physical interface command failed - Failure reason: Illegal target ID

I'm trying to test Bloom with an MPLAB Snap debugger attached to an attiny24A. Debugwire fuse is already set on controller, controller powered separately by USB. Connections:
Snap - attiny24A
pin 2 - V+
pin 3 - gnd
pin 6 - /reset or dW

Bloom output (bloom.json at end of report):
$ bloom
2021-12-23 17:10:22 SAST [MT] [1]: [INFO] Selected environment: default
2021-12-23 17:10:22 SAST [TC] [3]: [INFO] Starting TargetController
2021-12-23 17:10:22 SAST [TC] [6]: [INFO] Connecting to debug tool
2021-12-23 17:10:22 SAST [TC] [8]: [INFO] Debug tool connected
2021-12-23 17:10:22 SAST [TC] [9]: [INFO] Debug tool name: MPLAB Snap
2021-12-23 17:10:22 SAST [TC] [10]: [INFO] Debug tool serial:
2021-12-23 17:10:22 SAST [TC] [13]: [WARNING] AVR8 debugWire interface selected - the DWEN fuse will need to be enabled
2021-12-23 17:10:22 SAST [TC] [14]: [INFO] Activating target
2021-12-23 17:10:23 SAST [TC] [30]: [ERROR] The TargetController encountered a fatal error. See below for errors:
2021-12-23 17:10:23 SAST [TC] [31]: [ERROR] AVR8 Activate physical interface command failed - Failure reason: Illegal target ID
2021-12-23 17:10:23 SAST [TC] [32]: [INFO] Shutting down TargetController
2021-12-23 17:10:23 SAST [TC] [33]: [INFO] Deactivating target
2021-12-23 17:10:23 SAST [TC] [34]: [INFO] Closing debug tool
2021-12-23 17:10:23 SAST [MT] [36]: [ERROR] TargetController failed to startup.
2021-12-23 17:10:23 SAST [MT] [37]: [INFO] Shutting down Bloom
2021-12-23 17:10:23 SAST [SH] [42]: [INFO] Shutting down SignalHandler

I confirmed the device ID read via a different debugwire server (https://github.com/ccrause/debugwire-gdb-bridge):
Device ID: $910B - This ID is the same as the JTAG ID in ATTINY2424A.xml.

Any pointers on how to correctly use Bloom + Snap + debugwire?

bloom.json:
{
"environments": {
"default": {
"debugTool": {
"name": "snap",
"releasePostDebugSession": true
},

  "target": {
    "name": "attiny24A",
    "physicalInterface": "debug-wire"
  },

  "debugServer": {
    "name": "avr-gdb-rsp",
    "ipAddress": "127.0.0.1",
    "port": "1234"
  }
}

"insight": {
"enabled": true
}
}

Missing "#include <optional>" in ProjectConfig.hpp?

I was compiling Bloom from source on Arch Linux with GCC 12.2.0 and GNU libc 2.36. GCC gave errors saying ProjectConfig.hpp used std::optional without including <optional>:

[  4%] Building CXX object CMakeFiles/Bloom.dir/src/Logger/Logger.cpp.o
In file included from /home/shuyuan/Build/Bloom/src/Logger/Logger.hpp:8,
                 from /home/shuyuan/Build/Bloom/src/Logger/Logger.cpp:1:
/home/shuyuan/Build/Bloom/./src/ProjectConfig.hpp:61:14: error: ‘optional’ in namespace ‘std’ does not name a template type
   61 |         std::optional<std::string> variantName;
      |              ^~~~~~~~
/home/shuyuan/Build/Bloom/./src/ProjectConfig.hpp:7:1: note: ‘std::optional’ is defined in header ‘<optional>’; did you forget to ‘#include <optional>’?
    6 | #include <yaml-cpp/yaml.h>
  +++ |+#include <optional>
    7 | 
/home/shuyuan/Build/Bloom/./src/ProjectConfig.hpp:195:14: error: ‘optional’ in namespace ‘std’ does not name a template type
  195 |         std::optional<DebugServerConfig> debugServerConfig;
      |              ^~~~~~~~
/home/shuyuan/Build/Bloom/./src/ProjectConfig.hpp:195:9: note: ‘std::optional’ is defined in header ‘<optional>’; did you forget to ‘#include <optional>’?
  195 |         std::optional<DebugServerConfig> debugServerConfig;
      |         ^~~
/home/shuyuan/Build/Bloom/./src/ProjectConfig.hpp:200:14: error: ‘optional’ in namespace ‘std’ does not name a template type
  200 |         std::optional<InsightConfig> insightConfig;
      |              ^~~~~~~~
/home/shuyuan/Build/Bloom/./src/ProjectConfig.hpp:200:9: note: ‘std::optional’ is defined in header ‘<optional>’; did you forget to ‘#include <optional>’?
  200 |         std::optional<InsightConfig> insightConfig;
      |         ^~~
/home/shuyuan/Build/Bloom/./src/ProjectConfig.hpp:225:14: error: ‘optional’ in namespace ‘std’ does not name a template type
  225 |         std::optional<DebugServerConfig> debugServerConfig;
      |              ^~~~~~~~
/home/shuyuan/Build/Bloom/./src/ProjectConfig.hpp:225:9: note: ‘std::optional’ is defined in header ‘<optional>’; did you forget to ‘#include <optional>’?
  225 |         std::optional<DebugServerConfig> debugServerConfig;
      |         ^~~
/home/shuyuan/Build/Bloom/./src/ProjectConfig.hpp:231:14: error: ‘optional’ in namespace ‘std’ does not name a template type
  231 |         std::optional<InsightConfig> insightConfig;
      |              ^~~~~~~~
/home/shuyuan/Build/Bloom/./src/ProjectConfig.hpp:231:9: note: ‘std::optional’ is defined in header ‘<optional>’; did you forget to ‘#include <optional>’?
  231 |         std::optional<InsightConfig> insightConfig;
      |         ^~~

Clang 14.0.6 gave similar errors. I grep'd the src directory for optional and at a glance it seems that most other files that use it have included the header, but ProjectConfig.hpp hasn't.

Implement device driver for Xplained Mini & Nano evaluation boards

The Xplained Mini & Nano evaluation boards have an on-board debugger which appears to be EDBG-based.

Will be testing with:

Add support for the MPLAB PICkit 4 debug tool

The MPLAB PICkit 4 debug tool appears to work in a similar way to the MPLAB Snap; It appears to be a hybrid device that can present itself as an EDBG device, via a firmware update.

Adding support for this debug tool may be trivial, but this likely won't be looked at until the first beta release is ready,

Support installation via snapd

Currently, Bloom is distributed via a Debian (.deb) package. It is not hosted on any package managers.

I am considering adding support for installing Bloom via snapd - I have already registered the name bloom-debugger on Snapcraft (bloom was taken).

I probably won't begin work on this until there is evidence of demand. Please add a reaction or leave a comment on this issue, if this is something you want.

Change project configuration file format to YAML

Currently, project configuration files are expected to be in JSON format, with the filename being bloom.json.

JSON is nice, but I've recently come to accept that YAML would be a better format for the purpose of user-maintained configuration files.

So I'm going to be changing bloom.json to bloom.yaml, which should look something like this:

Default project configuration in JSON (`bloom.json`):

{
  "environments": {
    "default": {
      "debugTool": {
        "name": "atmel-ice",
        "releasePostDebugSession": true
      },

      "target": {
        "name": "avr8",
        "physicalInterface": "debug-wire"
      },

      "debugServer": {
        "name": "avr-gdb-rsp",
        "ipAddress": "127.0.0.1",
        "port": "1442"
      }
    }
  },

  "insight": {
    "enabled": true
  }
}

Default project configuration in YAML (`bloom.yaml`):

environments:
  default:
    debugTool:
      name: "atmel-ice"
      releasePostDebugSession: true

    target:
      name: "avr8"
      physicalInterface: "debug-wire"

    debugServer:
      name: "avr-gdb-rsp"
      ipAddress: "127.0.0.1"
      port: 1442

insight:
  enabled: true

I don't want this to be a breaking change, and I'd like to make the transition for current Bloom users as easy and seamless as possible. This is why I plan to have Bloom continue to check if a bloom.json file is present, in the absence of a bloom.yaml file, and if it is, automatically create a bloom.yaml file from the contents of the bloom.json file.

I'm hoping to include this in v0.11.0, but can't be certain about that ATM.

Distribute Bloom via Pacman package, for Arch Linux users

I've noticed a number of Bloom users on Arch Linux. In order to install Bloom, some of them convert the Debian package into another format. It would be nice if we could provide an Arch Linux compatible package for them.

Implement device driver for Curiosity Nano evaluation boards

The Curiosity Nano boards have an on-board debugger which appears to be EDBG-based. I've purchased some of these and hope to begin working on the driver later this week.

Boards I'll be testing with:

Added Documentation

This certainly isn't an issue...

I wanted to let you know I posted an update to using avr-gdb and Bloom on my site. I write both curriculum and for my site, they tend to blur into one.

Its not finished as I still need to update how to program DWEN w/o a Dragon, test out the short-term fix and advise as to how to use the short-term fix to upload code. Its a start...

https://wellys.com/posts/avr_c_gdbbloom/

Do with as you wish.
Lief

Bloom should manage the OCDEN fuse bit

Currently, users are required to program the OCDEN fuse bit on their JTAG targets, before they can begin a debug session with Bloom.

It would be nice if Bloom could manage the OCDEN fuse bit as it does with the DWEN fuse bit. The JTAG interface can be used to read and write to the fuse byte, but it requires the EDBG session to be in programming mode. Bloom doesn't currently support this, but I don't think it's a lot of work to implement.

I'm not sure when I'll get onto this. Will post any updates on this ticket.

Gdbserver registers response shorter than gdb expects

Testing Bloom with gdb 10.2 resulted in gdb complaining the response to the 'g' request is truncated. Inspection shows that the response is one byte shorter than the expected length of 32+1+2+4 = 39 bytes (or 78 hex digits). Please find the gdb session below.

$ ~/gdb/avr-gcc-11.1.0-x64-linux/bin/avr-gdb
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=avr".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
https://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) set debug remote 1
(gdb) fil testbreak.X.debug.elf
Reading symbols from testbreak.X.debug.elf...
(gdb) tar rem :1234
Remote debugging using :1234
Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
Packet received: qSupported:swbreak+;PacketSize=1024;
Packet qSupported (supported-packets) is supported
Sending packet: $vMustReplyEmpty#3a...Ack
Packet received: \000
Sending packet: $Hg0#df...Ack
Packet received: \000
Sending packet: $qTStatus#49...Ack
Packet received: \000
Packet qTStatus (trace-status) is NOT supported
Sending packet: $?#3f...Ack
Packet received: T05
Sending packet: $qfThreadInfo#bb...Ack
Packet received: \000
Sending packet: $qL1200000000000000000#50...Ack
Packet received: \000
Sending packet: $Hc-1#09...Ack
Packet received: \000
Sending packet: $qC#b4...Ack
Packet received: \000
Sending packet: $qAttached#8f...Ack
Packet received: \001
Packet qAttached (query-attached) is supported
Sending packet: $qOffsets#4b...Ack
Packet received: \000
Sending packet: $g#67...Ack
Packet received: ff00ffffbffffffd7fdffffdbeffbfffffffffffffbfefff20000301df08370000df00000000
Truncated register 34 in remote 'g' packet
(gdb) info registers
The program has no registers now.

Memory snapshots via Insight

Comparing memories at different points during a debug session would be a useful ability to have.

Ideally, we should be able to take a snapshot of the memory. The snapshot should be stored as a file, in Bloom's internal project directory (path/to/project/.bloom), and persisted through debug sessions.
We should also be able to compare a snapshot with another snapshot, or the current memory.
Snapshot diffs should include annotations. Ideally, we should reuse the HexViewerWidget.
Snapshots should be managed via the memory inspection pane, for the particular memory.
I see little need to enable this for program memory. RAM and EEPROM only for now.

More to follow

Support resetting the target via GDB's `monitor [COMMAND]` command

GDB users can send special (custom) commands to the server via the monitor command. Some GDB servers used for embedded debugging support the custom reset command, which triggers a target reset. Users can invoke this by running monitor reset in GDB.

It would be nice if Bloom supported the following custom commands:

reset - To reset the target and let it run.
reset halt - To reset the target and hold it in a stopped state.

I plan to include this work as part of the refactor of the GDB server implementation.

Tidy CMake configuration

The CMake configuration is a bit of a mess. Initially, the decision to only have a single CMakeLists.txt was made during a time when there weren't many source files in the codebase. The codebase has grown since then, so it now seems sensible to introduce a new CMakeLists.txt in each first-level subdirectory (from within the src directory).

There are also others bits of the current CMake config that could be improved.

I will try to get on this after (or maybe as part of) the TargetController interface refactoring.

Insight window set to awkward minimum size, upon activating the memory inspection pane, for targets with large pin counts

When the selected target package variant has a large pin count (~100 pins), and the user opens the memory inspection pane, the Insight window is given a minimum height which can exceed the available geometry. This makes the task of closing the memory inspection pane to be very awkward, as you can't click on the tool buttons due to the window exceeding the available geometry.

The minimum window size should never exceed the available geometry.

Generate SVD on demand (via GDB monitor command)

Users should be able to generate the System View Description (SVD) XML of the target currently being debugged, via a GDB monitor command.

I propose the following new GDB monitor commands:

monitor svd - Generates the SVD XML of the current AVR target and stores it in a file within the user's current project directory.
monitor svd --out - Generates the SVD XML of the current AVR target and sends it back to GDB, to print as output of the command. GDB front-ends can utilise this to obtain SVD XML without requiring any user intervention.

Not sure when I'll get onto this. Will post any updates on this ticket.

Redditor trying to debug an AVR bootloader. Bloom having packet issues.

I'm trying to develop this firmware as a bootloader, but it's executing off into the weeds and I'm trying to catch it in the act.

$ ddd --debugger "avr-gdb -ex 'file cmake-build-debug-avr/firmware.elf' -ex 'target remote :gdbremote'"

GNU DDD 3.3.12 (x86_64-unknown-linux-gnu), by Dorothea LReading symbols from cmake-build-debug-avr/firmware.elf...
Remote debugging using :gdbremote
0x00000000 in __vectors ()

I add a breakpoint at the top of main to skip past all the startup noise.

(gdb) break /home/garrett/build/git/firmware/src/firmware.cpp:46
Breakpoint 1 at 0x6ca: file /home/garrett/build/git/firmware/src/firmware.cpp, line 46.
(gdb) cont
Continuing.

Breakpoint 1, main () at /home/garrett/build/git/firmware/src/firmware.cpp:48

Now, I set a breakpoint down in the body of main(). If I set the breakpoint before the problem instruction, it'll continue straight to that breakpoint. If I set it after the problem instruction, that instruction will execute off into the weeds and cause a reset, which will ultimately be caught at the breakpoint at the top of main() again.

(gdb) break *0x0000072c
Breakpoint 2 at 0x72c: file /home/garrett/build/git/firmware/src/firmware.cpp, line 79.
(gdb) cont
Continuing.

Breakpoint 2, 0x0000072c in main () at /home/garrett/build/git/firmware/src/firmware.cpp:79

Okay. It's gotta be deeper. Let's move the breakpoint one instruction later.

(gdb) delete 2
(gdb) break *0x0000072e
Breakpoint 3 at 0x72e: file /home/garrett/build/git/firmware/src/firmware.cpp, line 79.
(gdb) cont
Continuing.

Breakpoint 1, main () at /home/garrett/build/git/firmware/src/firmware.cpp:48

Okay. I think I found my culprit, but let's reset the breakpoint higher and continue to see what happens.

(gdb) delete 3
(gdb) break *0x0000072c
Breakpoint 4 at 0x72c: file /home/garrett/build/git/firmware/src/firmware.cpp, line 79.
(gdb) cont
Continuing.
Continuing.
Continuing.
Continuing.
Continuing.
Ignoring packet error, continuing...

Breakpoint 1, main () at /home/garrett/build/git/firmware/src/firmware.cpp:48

Okay. That's not good. What's with the repeated "Continuing." messages? And there's the packet error. Let's see if it eventually recovers and gets back to the top of main().

(gdb) cont
Continuing.
Ignoring packet error, continuing...

Breakpoint 1, main () at /home/garrett/build/git/firmware/src/firmware.cpp:48

It does, but not before more packet errors.

(gdb) Quit
(gdb)

Now, what's bloom's terminal output while all of this is going on?

[garrett@workstation firmware]$ bloom 
WARNING: CPU random generator seem to be failing, disabling hardware random number generation
WARNING: RDRND generated: 0xffffffff 0xffffffff 0xffffffff 0xffffffff

The AMD Ryzen 9 3900X has a buggy hardware RNG

2022-04-18 14:35:04 EDT [MT] [1]: [DEBUG] Debug log printing has been enabled.
2022-04-18 14:35:04 EDT [MT] [2]: [DEBUG] Bloom version: 0.8.3
2022-04-18 14:35:04 EDT [MT] [3]: [INFO] Selected environment: "default"
2022-04-18 14:35:04 EDT [MT] [4]: [DEBUG] Number of environments extracted from config: 1
2022-04-18 14:35:04 EDT [SH] [5]: [DEBUG] Starting SignalHandler
2022-04-18 14:35:04 EDT [SH] [6]: [DEBUG] SignalHandler ready
2022-04-18 14:35:04 EDT [TC] [7]: [INFO] Starting TargetController
2022-04-18 14:35:04 EDT [TC] [8]: [INFO] Connecting to debug tool
2022-04-18 14:35:04 EDT [TC] [9]: [DEBUG] HID device path: 0003:0008:00
2022-04-18 14:35:04 EDT [TC] [10]: [INFO] Debug tool connected
2022-04-18 14:35:04 EDT [TC] [11]: [INFO] Debug tool name: Atmel-ICE
2022-04-18 14:35:04 EDT [TC] [12]: [INFO] Debug tool serial: J41800123456
2022-04-18 14:35:04 EDT [TC] [13]: [DEBUG] Loading AVR8 target description file: /opt/bloom/bin/../resources/TargetDescriptionFiles/AVR/AVR8/MEGA/AT90CAN128.xml
2022-04-18 14:35:04 EDT [TC] [14]: [INFO] Activating target
2022-04-18 14:35:04 EDT [TC] [15]: [DEBUG] Setting DEVICE_FLASH_PAGE_SIZE AVR8 parameter
2022-04-18 14:35:04 EDT [TC] [16]: [DEBUG] Setting DEVICE_FLASH_SIZE AVR8 parameter
2022-04-18 14:35:04 EDT [TC] [17]: [DEBUG] Setting DEVICE_FLASH_BASE AVR8 parameter
2022-04-18 14:35:04 EDT [TC] [18]: [DEBUG] Setting DEVICE_SRAM_START AVR8 parameter
2022-04-18 14:35:04 EDT [TC] [19]: [DEBUG] Setting DEVICE_EEPROM_SIZE AVR8 parameter
2022-04-18 14:35:04 EDT [TC] [20]: [DEBUG] Setting DEVICE_EEPROM_PAGE_SIZE AVR8 parameter
2022-04-18 14:35:04 EDT [TC] [21]: [DEBUG] Setting DEVICE_OCD_REVISION AVR8 parameter
2022-04-18 14:35:04 EDT [TC] [22]: [DEBUG] Setting DEVICE_OCD_DATA_REGISTER AVR8 parameter
2022-04-18 14:35:04 EDT [TC] [23]: [DEBUG] Setting DEVICE_SPMCR_REGISTER AVR8 parameter
2022-04-18 14:35:04 EDT [TC] [24]: [DEBUG] Setting DEVICE_BOOT_START_ADDR AVR8 parameter
2022-04-18 14:35:04 EDT [TC] [25]: [DEBUG] Setting DEVICE_OSCCAL_ADDR AVR8 parameter
2022-04-18 14:35:04 EDT [TC] [26]: [DEBUG] Setting DEVICE_EEARL_ADDR AVR8 parameter
2022-04-18 14:35:04 EDT [TC] [27]: [DEBUG] Setting DEVICE_EEARH_ADDR AVR8 parameter
2022-04-18 14:35:04 EDT [TC] [28]: [DEBUG] Setting DEVICE_EECR_ADDR AVR8 parameter
2022-04-18 14:35:05 EDT [TC] [29]: [DEBUG] Setting DEVICE_EEDR_ADDR AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [30]: [ERROR] Execution on AVR8 target could not be halted post attach - Failed to receive break event for AVR8 target
2022-04-18 14:35:06 EDT [TC] [31]: [INFO] Target activated
2022-04-18 14:35:06 EDT [TC] [32]: [INFO] AVR8 target promoted to megaAVR target
2022-04-18 14:35:06 EDT [TC] [33]: [DEBUG] Setting DEVICE_FLASH_PAGE_SIZE AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [34]: [DEBUG] Setting DEVICE_FLASH_SIZE AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [35]: [DEBUG] Setting DEVICE_FLASH_BASE AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [36]: [DEBUG] Setting DEVICE_SRAM_START AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [37]: [DEBUG] Setting DEVICE_EEPROM_SIZE AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [38]: [DEBUG] Setting DEVICE_EEPROM_PAGE_SIZE AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [39]: [DEBUG] Setting DEVICE_OCD_REVISION AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [40]: [DEBUG] Setting DEVICE_OCD_DATA_REGISTER AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [41]: [DEBUG] Setting DEVICE_SPMCR_REGISTER AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [42]: [DEBUG] Setting DEVICE_BOOT_START_ADDR AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [43]: [DEBUG] Setting DEVICE_OSCCAL_ADDR AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [44]: [DEBUG] Setting DEVICE_EEARL_ADDR AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [45]: [DEBUG] Setting DEVICE_EEARH_ADDR AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [46]: [DEBUG] Setting DEVICE_EECR_ADDR AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [47]: [DEBUG] Setting DEVICE_EEDR_ADDR AVR8 parameter
2022-04-18 14:35:06 EDT [TC] [48]: [INFO] Target ID: 0x1e9781
2022-04-18 14:35:06 EDT [TC] [49]: [INFO] Target name: AT90CAN128
2022-04-18 14:35:06 EDT [TC] [50]: [DEBUG] Event "TargetControllerThreadStateChanged" (2) registered for listener ApplicationEventListener
2022-04-18 14:35:06 EDT [TC] [51]: [DEBUG] TargetController ready and waiting for events.
2022-04-18 14:35:06 EDT [MT] [52]: [INFO] Selected DebugServer: AVR GDB Remote Serial Protocol Debug Server
2022-04-18 14:35:06 EDT [DS] [53]: [INFO] Starting DebugServer
2022-04-18 14:35:06 EDT [DS] [54]: [DEBUG] Event "ExtractTargetDescriptor" (3) registered for listener TargetControllerEventListener
2022-04-18 14:35:06 EDT [TC] [55]: [DEBUG] Target state changed - RUNNING
2022-04-18 14:35:06 EDT [TC] [56]: [DEBUG] Dispatching event ExtractTargetDescriptor (3).
2022-04-18 14:35:06 EDT [TC] [57]: [DEBUG] Event "TargetDescriptorExtracted" (5) registered for listener DebugServerEventListener
2022-04-18 14:35:06 EDT [DS] [58]: [INFO] GDB RSP address: 127.0.0.1
2022-04-18 14:35:06 EDT [DS] [59]: [INFO] GDB RSP port: 2159
2022-04-18 14:35:06 EDT [DS] [60]: [DEBUG] Event "DebugServerThreadStateChanged" (6) registered for listener ApplicationEventListener
2022-04-18 14:35:06 EDT [DS] [61]: [INFO] DebugServer ready
2022-04-18 14:35:06 EDT [DS] [62]: [INFO] Waiting for GDB RSP connection
2022-04-18 14:35:06 EDT [DS] [63]: [DEBUG] GDB RSP interrupted
2022-04-18 14:35:06 EDT [DS] [64]: [INFO] Waiting for GDB RSP connection
Warning: Ignoring WAYLAND_DISPLAY on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
2022-04-18 14:35:06 EDT [MT] [65]: [INFO] Starting Insight
2022-04-18 14:35:06 EDT [MT] [66]: [DEBUG] Event "ExtractTargetDescriptor" (7) registered for listener TargetControllerEventListener
2022-04-18 14:35:06 EDT [TC] [67]: [DEBUG] Dispatching event ExtractTargetDescriptor (7).
2022-04-18 14:35:06 EDT [TC] [68]: [DEBUG] Event "TargetDescriptorExtracted" (8) registered for listener ApplicationEventListener
2022-04-18 14:35:06 EDT [MT] [69]: [DEBUG] Number of target variants supported by Insight: 2
2022-04-18 14:35:07 EDT [MT] [70]: [INFO] Insight ready
2022-04-18 14:35:07 EDT [IW] [71]: [DEBUG] Starting InsightWorker thread
2022-04-18 14:35:07 EDT [IW] [72]: [DEBUG] Event "InsightThreadStateChanged" (9) registered for listener TargetControllerEventListener
2022-04-18 14:35:07 EDT [TC] [73]: [DEBUG] Dispatching event InsightThreadStateChanged (9).
2022-04-18 14:35:07 EDT [TC] [74]: [DEBUG] Target state changed - RUNNING
2022-04-18 14:35:07 EDT [TC] [75]: [DEBUG] Event "TargetExecutionResumed" (10) registered for listener InsightWorkerEventListener
2022-04-18 14:35:07 EDT [IW] [76]: [DEBUG] Dispatching event TargetExecutionResumed (10).
2022-04-18 14:35:14 EDT [DS] [77]: [INFO] Accepted GDP RSP connection from 127.0.0.1
2022-04-18 14:35:14 EDT [DS] [78]: [DEBUG] Event "DebugSessionStarted" (11) registered for listener TargetControllerEventListener
2022-04-18 14:35:14 EDT [DS] [79]: [DEBUG] Event "ReportTargetControllerState" (12) registered for listener TargetControllerEventListener
2022-04-18 14:35:14 EDT [TC] [80]: [DEBUG] Dispatching event DebugSessionStarted (11).
2022-04-18 14:35:14 EDT [TC] [81]: [DEBUG] Target state changed - STOPPED
2022-04-18 14:35:14 EDT [TC] [82]: [DEBUG] Event "TargetExecutionStopped" (13) registered for listener DebugServerEventListener
2022-04-18 14:35:14 EDT [TC] [83]: [DEBUG] Event "TargetExecutionStopped" (13) registered for listener InsightWorkerEventListener
2022-04-18 14:35:14 EDT [TC] [84]: [DEBUG] Dispatching event ReportTargetControllerState (12).
2022-04-18 14:35:14 EDT [TC] [85]: [DEBUG] Event "TargetControllerStateReported" (14) registered for listener DebugServerEventListener
2022-04-18 14:35:14 EDT [TC] [86]: [DEBUG] Event "TargetControllerStateReported" (14) registered for listener InsightWorkerEventListener
2022-04-18 14:35:14 EDT [DS] [87]: [DEBUG] GDB client data received (158 bytes): +$qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;memory-tagging+#ec
2022-04-18 14:35:14 EDT [DS] [88]: [DEBUG] Writing packet: +
2022-04-18 14:35:14 EDT [DS] [89]: [DEBUG] Handling QuerySupport packet
2022-04-18 14:35:14 EDT [DS] [90]: [DEBUG] Writing packet: $qSupported:swbreak+;PacketSize=1024;#f8
2022-04-18 14:35:14 EDT [DS] [91]: [DEBUG] Dispatching event TargetExecutionStopped (13).

Okay. I have to trim some fat in order to get in under the 64kB message maximum.

2022-04-18 14:35:46 EDT [TC] [327]: [DEBUG] Event "TargetExecutionResumed" (65) registered for listener DebugServerEventListener
2022-04-18 14:35:46 EDT [TC] [328]: [DEBUG] Event "TargetExecutionResumed" (65) registered for listener InsightWorkerEventListener
2022-04-18 14:35:46 EDT [IW] [329]: [DEBUG] Dispatching event TargetExecutionResumed (65).
2022-04-18 14:35:46 EDT [TC] [330]: [DEBUG] Target state changed - STOPPED
2022-04-18 14:35:46 EDT [TC] [331]: [DEBUG] Event "TargetExecutionStopped" (66) registered for listener DebugServerEventListener
2022-04-18 14:35:46 EDT [TC] [332]: [DEBUG] Event "TargetExecutionStopped" (66) registered for listener InsightWorkerEventListener
2022-04-18 14:35:46 EDT [DS] [333]: [DEBUG] GDB RSP interrupted
2022-04-18 14:35:46 EDT [DS] [334]: [DEBUG] Dispatching event TargetExecutionStopped (66).
2022-04-18 14:35:46 EDT [DS] [335]: [DEBUG] Writing packet: $T05#b9
2022-04-18 14:35:46 EDT [DS] [336]: [DEBUG] GDB client data received (5 bytes): $g#67
2022-04-18 14:35:46 EDT [DS] [337]: [DEBUG] Writing packet: +
2022-04-18 14:35:46 EDT [DS] [338]: [DEBUG] Handling ReadRegisters packet
2022-04-18 14:35:46 EDT [DS] [339]: [DEBUG] Event "RetrieveRegistersFromTarget" (67) registered for listener TargetControllerEventListener
2022-04-18 14:35:46 EDT [TC] [340]: [DEBUG] Dispatching event RetrieveRegistersFromTarget (67).
2022-04-18 14:35:46 EDT [IW] [341]: [DEBUG] Dispatching event TargetExecutionStopped (66).
2022-04-18 14:35:46 EDT [TC] [342]: [DEBUG] Event "RegistersRetrievedFromTarget" (68) registered for listener DebugServerEventListener
2022-04-18 14:35:46 EDT [DS] [343]: [DEBUG] Writing packet: $bd000400002000324000c510000000000000ff00f8fbffff01006f025600700202fd10cc060000#64
2022-04-18 14:35:46 EDT [DS] [344]: [DEBUG] GDB RSP interrupted
2022-04-18 14:35:46 EDT [DS] [345]: [DEBUG] GDB client data received (12 bytes): $Z0,6ca,2#0e
2022-04-18 14:35:46 EDT [DS] [346]: [DEBUG] Writing packet: +
2022-04-18 14:35:46 EDT [DS] [347]: [DEBUG] Handling SetBreakpoint packet
2022-04-18 14:35:46 EDT [DS] [348]: [DEBUG] Event "SetBreakpointOnTarget" (69) registered for listener TargetControllerEventListener
2022-04-18 14:35:46 EDT [TC] [349]: [DEBUG] Dispatching event SetBreakpointOnTarget (69).
2022-04-18 14:35:46 EDT [TC] [350]: [DEBUG] Event "BreakpointSetOnTarget" (70) registered for listener DebugServerEventListener
2022-04-18 14:35:46 EDT [DS] [351]: [DEBUG] Writing packet: $OK#9a
2022-04-18 14:35:46 EDT [DS] [352]: [DEBUG] GDB RSP interrupted
2022-04-18 14:35:46 EDT [DS] [353]: [DEBUG] GDB client data received (7 bytes): $Hc0#db
2022-04-18 14:35:46 EDT [DS] [354]: [DEBUG] Writing packet: +
2022-04-18 14:35:46 EDT [DS] [355]: [DEBUG] Unknown GDB RSP packet: Hc0 - returning empty response
2022-04-18 14:35:46 EDT [DS] [356]: [DEBUG] Writing packet: $#00
2022-04-18 14:35:46 EDT [DS] [357]: [DEBUG] GDB client data received (5 bytes): $c#63
2022-04-18 14:35:46 EDT [DS] [358]: [DEBUG] Writing packet: +
2022-04-18 14:35:46 EDT [DS] [359]: [DEBUG] Handling ContinueExecution packet
2022-04-18 14:35:46 EDT [DS] [360]: [DEBUG] Event "ResumeTargetExecutionEvent" (71) registered for listener TargetControllerEventListener
2022-04-18 14:35:46 EDT [TC] [361]: [DEBUG] Dispatching event ResumeTargetExecutionEvent (71).
2022-04-18 14:35:47 EDT [IW] [362]: [DEBUG] Event "RetrieveTargetPinStates" (72) registered for listener TargetControllerEventListener
2022-04-18 14:35:47 EDT [TC] [363]: [DEBUG] Event "TargetExecutionResumed" (73) registered for listener DebugServerEventListener
2022-04-18 14:35:47 EDT [TC] [364]: [DEBUG] Event "TargetExecutionResumed" (73) registered for listener InsightWorkerEventListener
2022-04-18 14:35:47 EDT [TC] [365]: [DEBUG] Dispatching event RetrieveTargetPinStates (72).
2022-04-18 14:35:47 EDT [TC] [366]: [ERROR] Failed to retrieve target pin states - Invalid target state - target must be stopped before pin states can be retrieved
2022-04-18 14:35:47 EDT [TC] [367]: [DEBUG] Event "TargetControllerErrorOccurred" (74) registered for listener InsightWorkerEventListener
2022-04-18 14:35:47 EDT [IW] [368]: [ERROR] InsightWorker task failed - Invalid target state - target must be stopped before pin states can be retrieved
2022-04-18 14:35:47 EDT [IW] [369]: [DEBUG] Event "RetrieveRegistersFromTarget" (75) registered for listener TargetControllerEventListener
2022-04-18 14:35:47 EDT [TC] [370]: [DEBUG] Dispatching event RetrieveRegistersFromTarget (75).
2022-04-18 14:35:47 EDT [TC] [371]: [ERROR] Failed to read registers from target - AVR8 Read memory command failed - Failure reason: Illegal run / stopped state
2022-04-18 14:35:47 EDT [TC] [372]: [DEBUG] Event "TargetControllerErrorOccurred" (76) registered for listener InsightWorkerEventListener
2022-04-18 14:35:47 EDT [IW] [373]: [ERROR] InsightWorker task failed - AVR8 Read memory command failed - Failure reason: Illegal run / stopped state
2022-04-18 14:35:47 EDT [IW] [374]: [DEBUG] Event "RetrieveMemoryFromTarget" (77) registered for listener TargetControllerEventListener
2022-04-18 14:35:48 EDT [TC] [375]: [DEBUG] Dispatching event RetrieveMemoryFromTarget (77).

…

2022-04-18 14:36:54 EDT [IW] [621]: [DEBUG] Dispatching event TargetExecutionStopped (136).
2022-04-18 14:36:55 EDT [IW] [622]: [DEBUG] Event "RetrieveTargetPinStates" (145) registered for listener TargetControllerEventListener
2022-04-18 14:36:55 EDT [TC] [623]: [DEBUG] Event "TargetExecutionResumed" (146) registered for listener DebugServerEventListener
2022-04-18 14:36:55 EDT [TC] [624]: [DEBUG] Event "TargetExecutionResumed" (146) registered for listener InsightWorkerEventListener
2022-04-18 14:36:55 EDT [DS] [625]: [DEBUG] GDB client data received (1 bytes): 
2022-04-18 14:36:55 EDT [DS] [626]: [DEBUG] Writing packet: +
2022-04-18 14:36:55 EDT [DS] [627]: [DEBUG] Handling InterruptExecution packet
2022-04-18 14:36:55 EDT [DS] [628]: [DEBUG] Event "StopTargetExecution" (147) registered for listener TargetControllerEventListener
2022-04-18 14:36:55 EDT [TC] [629]: [DEBUG] Dispatching event RetrieveTargetPinStates (145).
2022-04-18 14:36:55 EDT [TC] [630]: [ERROR] Failed to retrieve target pin states - Invalid target state - target must be stopped before pin states can be retrieved
2022-04-18 14:36:55 EDT [TC] [631]: [DEBUG] Event "TargetControllerErrorOccurred" (148) registered for listener DebugServerEventListener
2022-04-18 14:36:55 EDT [TC] [632]: [DEBUG] Event "TargetControllerErrorOccurred" (148) registered for listener InsightWorkerEventListener
2022-04-18 14:36:55 EDT [TC] [633]: [DEBUG] Dispatching event StopTargetExecution (147).
2022-04-18 14:36:55 EDT [IW] [634]: [ERROR] InsightWorker task failed - Invalid target state - target must be stopped before pin states can be retrieved
2022-04-18 14:36:55 EDT [IW] [635]: [DEBUG] Event "RetrieveRegistersFromTarget" (149) registered for listener TargetControllerEventListener
2022-04-18 14:36:55 EDT [TC] [636]: [DEBUG] Event "TargetExecutionStopped" (150) registered for listener DebugServerEventListener
2022-04-18 14:36:55 EDT [TC] [637]: [DEBUG] Event "TargetExecutionStopped" (150) registered for listener InsightWorkerEventListener
2022-04-18 14:36:55 EDT [TC] [638]: [DEBUG] Dispatching event RetrieveRegistersFromTarget (149).
2022-04-18 14:36:55 EDT [DS] [639]: [DEBUG] Writing packet: $T02#b6
2022-04-18 14:36:55 EDT [DS] [640]: [DEBUG] GDB RSP interrupted
2022-04-18 14:36:55 EDT [DS] [641]: [DEBUG] GDB client data received (5 bytes): $g#67
2022-04-18 14:36:55 EDT [DS] [642]: [DEBUG] Writing packet: +

…

2022-04-18 14:37:13 EDT [DS] [731]: [DEBUG] GDB RSP interrupted
2022-04-18 14:37:13 EDT [DS] [732]: [DEBUG] GDB client data received (25 bytes): $qL1200000000000000000#50
2022-04-18 14:37:13 EDT [DS] [733]: [DEBUG] Writing packet: +
2022-04-18 14:37:13 EDT [DS] [734]: [DEBUG] Unknown GDB RSP packet: qL1200000000000000000 - returning empty response
2022-04-18 14:37:13 EDT [DS] [735]: [DEBUG] Writing packet: $#00
2022-04-18 14:37:13 EDT [DS] [736]: [DEBUG] GDB client data received (12 bytes): $z0,72c,2#00
2022-04-18 14:37:13 EDT [DS] [737]: [DEBUG] Writing packet: +
2022-04-18 14:37:13 EDT [DS] [738]: [DEBUG] Removing breakpoint at address 1836
2022-04-18 14:37:13 EDT [DS] [739]: [DEBUG] Event "RemoveBreakpointOnTarget" (179) registered for listener TargetControllerEventListener
2022-04-18 14:37:13 EDT [TC] [740]: [DEBUG] Dispatching event RemoveBreakpointOnTarget (179).
2022-04-18 14:37:13 EDT [TC] [741]: [DEBUG] Event "BreakpointRemovedOnTarget" (180) registered for listener DebugServerEventListener
2022-04-18 14:37:13 EDT [DS] [742]: [DEBUG] Writing packet: $OK#9a
2022-04-18 14:37:13 EDT [DS] [743]: [DEBUG] GDB RSP interrupted
2022-04-18 14:37:13 EDT [DS] [744]: [DEBUG] GDB client data received (11 bytes): $m1106,1#92
2022-04-18 14:37:13 EDT [DS] [745]: [DEBUG] Writing packet: +
2022-04-18 14:37:13 EDT [DS] [746]: [DEBUG] Handling ReadMemory packet
2022-04-18 14:37:13 EDT [DS] [747]: [DEBUG] Event "RetrieveMemoryFromTarget" (181) registered for listener TargetControllerEventListener
2022-04-18 14:37:13 EDT [TC] [748]: [DEBUG] Dispatching event RetrieveMemoryFromTarget (181).
2022-04-18 14:37:13 EDT [TC] [749]: [ERROR] Failed to read memory from target - AVR8 Read memory command failed - Failure reason: Too many or too few bytes
2022-04-18 14:37:13 EDT [TC] [750]: [DEBUG] Event "TargetControllerErrorOccurred" (183) registered for listener DebugServerEventListener
2022-04-18 14:37:13 EDT [DS] [751]: [ERROR] Failed to read memory from target - AVR8 Read memory command failed - Failure reason: Too many or too few bytes
2022-04-18 14:37:13 EDT [DS] [752]: [DEBUG] Writing packet: $E01#a6
2022-04-18 14:37:13 EDT [DS] [753]: [DEBUG] GDB RSP interrupted
2022-04-18 14:37:13 EDT [DS] [754]: [DEBUG] GDB client data received (12 bytes): $Z0,6ca,2#0e
2022-04-18 14:37:13 EDT [DS] [755]: [DEBUG] Writing packet: +
2022-04-18 14:37:13 EDT [DS] [756]: [DEBUG] Handling SetBreakpoint packet
2022-04-18 14:37:13 EDT [DS] [757]: [DEBUG] Event "SetBreakpointOnTarget" (184) registered for listener TargetControllerEventListener
2022-04-18 14:37:13 EDT [TC] [758]: [DEBUG] Dispatching event SetBreakpointOnTarget (184).
2022-04-18 14:37:13 EDT [TC] [759]: [DEBUG] Event "BreakpointSetOnTarget" (185) registered for listener DebugServerEventListener
2022-04-18 14:37:13 EDT [DS] [760]: [DEBUG] Writing packet: $OK#9a
2022-04-18 14:37:13 EDT [DS] [761]: [DEBUG] GDB client data received (12 bytes): $Z0,72c,2#e0
2022-04-18 14:37:13 EDT [DS] [762]: [DEBUG] Writing packet: +
2022-04-18 14:37:13 EDT [DS] [763]: [DEBUG] Handling SetBreakpoint packet
2022-04-18 14:37:13 EDT [DS] [764]: [DEBUG] Event "SetBreakpointOnTarget" (186) registered for listener TargetControllerEventListener
2022-04-18 14:37:13 EDT [TC] [765]: [DEBUG] Dispatching event SetBreakpointOnTarget (186).
2022-04-18 14:37:13 EDT [TC] [766]: [DEBUG] Event "BreakpointSetOnTarget" (187) registered for listener DebugServerEventListener
2022-04-18 14:37:13 EDT [DS] [767]: [DEBUG] Writing packet: $OK#9a
2022-04-18 14:37:13 EDT [DS] [768]: [DEBUG] GDB RSP interrupted
2022-04-18 14:37:13 EDT [DS] [769]: [DEBUG] GDB client data received (7 bytes): $Hc0#db
2022-04-18 14:37:13 EDT [DS] [770]: [DEBUG] Writing packet: +
2022-04-18 14:37:13 EDT [DS] [771]: [DEBUG] Unknown GDB RSP packet: Hc0 - returning empty response
2022-04-18 14:37:13 EDT [DS] [772]: [DEBUG] Writing packet: $#00
2022-04-18 14:37:13 EDT [DS] [773]: [DEBUG] GDB client data received (5 bytes): $c#63
2022-04-18 14:37:13 EDT [DS] [774]: [DEBUG] Writing packet: +
2022-04-18 14:37:13 EDT [DS] [775]: [DEBUG] Handling ContinueExecution packet
2022-04-18 14:37:13 EDT [DS] [776]: [DEBUG] Event "ResumeTargetExecutionEvent" (188) registered for listener TargetControllerEventListener
2022-04-18 14:37:13 EDT [TC] [777]: [DEBUG] Dispatching event ResumeTargetExecutionEvent (188).
2022-04-18 14:37:13 EDT [IW] [778]: [DEBUG] Dispatching event TargetExecutionStopped (175).
2022-04-18 14:37:14 EDT [IW] [779]: [DEBUG] Event "RetrieveTargetPinStates" (189) registered for listener TargetControllerEventListener
2022-04-18 14:37:14 EDT [TC] [780]: [DEBUG] Event "TargetExecutionResumed" (190) registered for listener DebugServerEventListener
2022-04-18 14:37:14 EDT [TC] [781]: [DEBUG] Event "TargetExecutionResumed" (190) registered for listener InsightWorkerEventListener
2022-04-18 14:37:14 EDT [DS] [782]: [DEBUG] GDB client data received (1 bytes): 
2022-04-18 14:37:14 EDT [DS] [783]: [DEBUG] Writing packet: +
2022-04-18 14:37:14 EDT [DS] [784]: [DEBUG] Handling InterruptExecution packet
2022-04-18 14:37:14 EDT [DS] [785]: [DEBUG] Event "StopTargetExecution" (191) registered for listener TargetControllerEventListener
2022-04-18 14:37:14 EDT [TC] [786]: [DEBUG] Dispatching event RetrieveTargetPinStates (189).
2022-04-18 14:37:14 EDT [TC] [787]: [ERROR] Failed to retrieve target pin states - Invalid target state - target must be stopped before pin states can be retrieved
2022-04-18 14:37:14 EDT [TC] [788]: [DEBUG] Event "TargetControllerErrorOccurred" (192) registered for listener DebugServerEventListener
2022-04-18 14:37:14 EDT [TC] [789]: [DEBUG] Event "TargetControllerErrorOccurred" (192) registered for listener InsightWorkerEventListener
2022-04-18 14:37:14 EDT [TC] [790]: [DEBUG] Dispatching event StopTargetExecution (191).
2022-04-18 14:37:14 EDT [IW] [791]: [ERROR] InsightWorker task failed - Invalid target state - target must be stopped before pin states can be retrieved
2022-04-18 14:37:14 EDT [IW] [792]: [DEBUG] Event "RetrieveRegistersFromTarget" (193) registered for listener TargetControllerEventListener
2022-04-18 14:37:14 EDT [TC] [793]: [DEBUG] Event "TargetExecutionStopped" (194) registered for listener DebugServerEventListener
2022-04-18 14:37:14 EDT [TC] [794]: [DEBUG] Event "TargetExecutionStopped" (194) registered for listener InsightWorkerEventListener
2022-04-18 14:37:14 EDT [TC] [795]: [DEBUG] Dispatching event RetrieveRegistersFromTarget (193).
2022-04-18 14:37:14 EDT [DS] [796]: [DEBUG] Writing packet: $T02#b6
2022-04-18 14:37:14 EDT [DS] [797]: [DEBUG] GDB RSP interrupted

…

2022-04-18 14:37:32 EDT [DS] [891]: [DEBUG] GDB RSP interrupted
2022-04-18 14:37:32 EDT [DS] [892]: [DEBUG] GDB client data received (7 bytes): $Hc0#db
2022-04-18 14:37:32 EDT [DS] [893]: [DEBUG] Writing packet: +
2022-04-18 14:37:32 EDT [DS] [894]: [DEBUG] Unknown GDB RSP packet: Hc0 - returning empty response
2022-04-18 14:37:32 EDT [DS] [895]: [DEBUG] Writing packet: $#00
2022-04-18 14:37:32 EDT [DS] [896]: [DEBUG] GDB client data received (5 bytes): $c#63
2022-04-18 14:37:32 EDT [DS] [897]: [DEBUG] Writing packet: +
2022-04-18 14:37:32 EDT [DS] [898]: [DEBUG] Handling ContinueExecution packet
2022-04-18 14:37:32 EDT [DS] [899]: [DEBUG] Event "ResumeTargetExecutionEvent" (223) registered for listener TargetControllerEventListener
2022-04-18 14:37:32 EDT [TC] [900]: [DEBUG] Dispatching event ResumeTargetExecutionEvent (223).
2022-04-18 14:37:32 EDT [IW] [901]: [DEBUG] Event "RetrieveTargetPinStates" (224) registered for listener TargetControllerEventListener
2022-04-18 14:37:33 EDT [TC] [902]: [DEBUG] Event "TargetExecutionResumed" (225) registered for listener DebugServerEventListener
2022-04-18 14:37:33 EDT [TC] [903]: [DEBUG] Event "TargetExecutionResumed" (225) registered for listener InsightWorkerEventListener
2022-04-18 14:37:33 EDT [TC] [904]: [DEBUG] Dispatching event RetrieveTargetPinStates (224).
2022-04-18 14:37:33 EDT [TC] [905]: [ERROR] Failed to retrieve target pin states - Invalid target state - target must be stopped before pin states can be retrieved
2022-04-18 14:37:33 EDT [TC] [906]: [DEBUG] Event "TargetControllerErrorOccurred" (226) registered for listener InsightWorkerEventListener
2022-04-18 14:37:33 EDT [IW] [907]: [ERROR] InsightWorker task failed - Invalid target state - target must be stopped before pin states can be retrieved
2022-04-18 14:37:33 EDT [IW] [908]: [DEBUG] Event "RetrieveRegistersFromTarget" (227) registered for listener TargetControllerEventListener
2022-04-18 14:37:33 EDT [TC] [909]: [DEBUG] Dispatching event RetrieveRegistersFromTarget (227).
2022-04-18 14:37:33 EDT [TC] [910]: [DEBUG] Event "RegistersRetrievedFromTarget" (228) registered for listener InsightWorkerEventListener
2022-04-18 14:37:33 EDT [IW] [911]: [DEBUG] Event "RetrieveMemoryFromTarget" (229) registered for listener TargetControllerEventListener
2022-04-18 14:37:33 EDT [TC] [912]: [DEBUG] Target state changed - STOPPED
2022-04-18 14:37:33 EDT [TC] [913]: [DEBUG] Event "TargetExecutionStopped" (230) registered for listener DebugServerEventListener
2022-04-18 14:37:33 EDT [TC] [914]: [DEBUG] Event "TargetExecutionStopped" (230) registered for listener InsightWorkerEventListener
2022-04-18 14:37:33 EDT [TC] [915]: [DEBUG] Dispatching event RetrieveMemoryFromTarget (229).
2022-04-18 14:37:33 EDT [DS] [916]: [DEBUG] GDB RSP interrupted

…

2022-04-18 14:37:54 EDT [DS] [1047]: [DEBUG] GDB RSP interrupted
2022-04-18 14:37:54 EDT [DS] [1048]: [DEBUG] GDB client data received (5 bytes): $c#63
2022-04-18 14:37:54 EDT [DS] [1049]: [DEBUG] Writing packet: +
2022-04-18 14:37:54 EDT [DS] [1050]: [DEBUG] Handling ContinueExecution packet
2022-04-18 14:37:54 EDT [DS] [1051]: [DEBUG] Event "ResumeTargetExecutionEvent" (265) registered for listener TargetControllerEventListener
2022-04-18 14:37:54 EDT [TC] [1052]: [DEBUG] Dispatching event ResumeTargetExecutionEvent (265).
2022-04-18 14:37:54 EDT [IW] [1053]: [DEBUG] Event "RetrieveTargetPinStates" (266) registered for listener TargetControllerEventListener
2022-04-18 14:37:55 EDT [TC] [1054]: [DEBUG] Event "TargetExecutionResumed" (267) registered for listener DebugServerEventListener
2022-04-18 14:37:55 EDT [TC] [1055]: [DEBUG] Event "TargetExecutionResumed" (267) registered for listener InsightWorkerEventListener
2022-04-18 14:37:55 EDT [TC] [1056]: [DEBUG] Dispatching event RetrieveTargetPinStates (266).
2022-04-18 14:37:55 EDT [TC] [1057]: [ERROR] Failed to retrieve target pin states - Invalid target state - target must be stopped before pin states can be retrieved
2022-04-18 14:37:55 EDT [TC] [1058]: [DEBUG] Event "TargetControllerErrorOccurred" (268) registered for listener InsightWorkerEventListener
2022-04-18 14:37:55 EDT [IW] [1059]: [ERROR] InsightWorker task failed - Invalid target state - target must be stopped before pin states can be retrieved
2022-04-18 14:37:55 EDT [IW] [1060]: [DEBUG] Event "RetrieveRegistersFromTarget" (269) registered for listener TargetControllerEventListener
2022-04-18 14:37:55 EDT [TC] [1061]: [DEBUG] Dispatching event RetrieveRegistersFromTarget (269).
2022-04-18 14:37:55 EDT [TC] [1062]: [DEBUG] Event "RegistersRetrievedFromTarget" (270) registered for listener InsightWorkerEventListener
2022-04-18 14:37:55 EDT [IW] [1063]: [DEBUG] Event "RetrieveMemoryFromTarget" (271) registered for listener TargetControllerEventListener
2022-04-18 14:37:55 EDT [TC] [1064]: [DEBUG] Target state changed - STOPPED
2022-04-18 14:37:56 EDT [TC] [1065]: [DEBUG] Event "TargetExecutionStopped" (272) registered for listener DebugServerEventListener
2022-04-18 14:37:56 EDT [TC] [1066]: [DEBUG] Event "TargetExecutionStopped" (272) registered for listener InsightWorkerEventListener
2022-04-18 14:37:56 EDT [TC] [1067]: [DEBUG] Dispatching event RetrieveMemoryFromTarget (271).
2022-04-18 14:37:56 EDT [DS] [1068]: [DEBUG] GDB RSP interrupted

Line 77 is where I launched ddd.

Things started going wrong around line 365 and 370. And again at line 629, 748, 786, 904, and 1056. The vast majority are off RetrieveTargetPinStates events, while 748 is RetrieveMemoryFromTarget and 370 is RetrieveRegistersFromTarget.

Here's my bloom.json in this project:

{
  "debugLoggingEnabled": true,

  "environments": {
    "default": {
      "debugTool": {
        "name": "atmel-ice",
        "releasePostDebugSession": true
      },

      "target": {
        "name": "at90can128",
        "physicalInterface": "jtag"
      },

      "debugServer": {
        "name": "avr-gdb-rsp",
        "ipAddress": "127.0.0.1",
        "port": "2159"
      }
    }
  },

  "insight": {
    "enabled": true
  }
}

I use port 2159, because it's actually listed in my /etc/services file, labelled gdbremote, so that's why I use that in my ddd invocation. Would be really convenient if bloom did local port name resolution rather than demanding numerical port numbers.

Enable support for JTAG and UPDI physical interfaces

Bloom already supports the JTAG and UPDI physical interfaces, with all three of the supported debug tools, but these interfaces were disabled for the first beta release (v0.0.1) due to a lack of testing during the development phase. Only PDI and debugWire interfaces are supported in the first beta release.

I'm hoping to complete sufficient testing of the JTAG and UPDI interfaces for the subsequent release of Bloom.

See EdbgAvr8Interface::physicalInterfacesByName.

Also, I suspect there may be some development work required for the UPDI interface, as I don't think we're passing all of the required device-context parameters to the EDBG debug tool, for UPDI connected targets.

"JTAGM failed to initialise" - Atmel-ICE, UPDI, ATmega4809

Hi!

Super excited about the possibility of Bloom - support for '4809 is universally terrible, so anything that improves that will be awesome - but running into some initial problems, maybe you can help.

Using an Atmel-ICE, with a Microchip atmega4809Xplained evaluation board; debug interface is UPDI. Running bloom gives me the following error:

2021-10-30 15:46:59 UTC [MT] [1]: [INFO] Selected environment: default
2021-10-30 15:46:59 UTC [TC] [5]: [INFO] Starting TargetController
2021-10-30 15:46:59 UTC [TC] [6]: [INFO] Connecting to debug tool
2021-10-30 15:46:59 UTC [TC] [8]: [INFO] Debug tool connected
2021-10-30 15:46:59 UTC [TC] [9]: [INFO] Debug tool name: Atmel-ICE
2021-10-30 15:46:59 UTC [TC] [10]: [INFO] Debug tool serial: J42700029646
2021-10-30 15:46:59 UTC [TC] [14]: [INFO] Activating target
2021-10-30 15:46:59 UTC [TC] [15]: [ERROR] The TargetController encountered a fatal error. See below for errors:
2021-10-30 15:46:59 UTC [TC] [16]: [ERROR] Failed to set parameter on device! - Failure reason: JTAGM failed to initialise
2021-10-30 15:46:59 UTC [TC] [17]: [INFO] Shutting down TargetController
2021-10-30 15:46:59 UTC [TC] [18]: [INFO] Deactivating target
2021-10-30 15:46:59 UTC [TC] [19]: [INFO] Closing debug tool
2021-10-30 15:46:59 UTC [MT] [21]: [ERROR] TargetController failed to startup.
2021-10-30 15:46:59 UTC [MT] [22]: [INFO] Shutting down Bloom
2021-10-30 15:46:59 UTC [SH] [27]: [INFO] Shutting down SignalHandler

Version is Bloom v0.4.1. My config file looks like:

{
  "environments": {
    "default": {
      "debugTool": {
        "name": "atmel-ice",
        "releasePostDebugSession": true
      },

      "target": {
        "name": "atmega4809",
        "physicalInterface": "updi"
      },

      "debugServer": {
        "name": "avr-gdb-rsp",
        "ipAddress": "0.0.0.0",
        "port": "1442"
      }
    }
  },

  "insight": {
    "enabled": true
  }
}

I can confirm the hardware & debugging all works with the dreaded Microchip Studio on a Windows host, so not a hardware issue.

Any thoughts, or anything I can do to help debug?

Cheers,
Tim

Support for programming

Currently, Bloom only serves debugging operations. And whilst writing to target memories such as RAM and EEPROM is supported, Bloom cannot write to program (flash) memory. Bloom currently rejects any "write memory" commands from the connected GDB client, if the command addresses flash memory:

https://github.com/navnavnav/Bloom/blob/ead657b4af00bc3eec2cf57452a6cc34a1f4eb0b/src/DebugServer/Gdb/AvrGdb/CommandPackets/WriteMemory.cpp#L81-L85

Support for programming was briefly discussed in a previous issue, but I've been giving it some more thought and I'm now reconsidering.

My initial thoughts on how this would work (key points):

Programming for debugging, not production
- There will be no "program only" function.
- Users should only use Bloom for programming when they intend to continue debugging/testing their modified code.
- The objective is to allow users to apply changes to their code and test those changes using Bloom, without having to resort to using production programming software such as MPLAB IPE.
- Bloom is not to serve as an alternative to production programming software such as MPLAB IPE or AVRDUDE.
Starting small
- To begin with, programming will only be available via the GDB session. Users will use the GDB load command to have GDB write to the program memory.
- GDB will do most of the work - Bloom will just perform the write memory operations.
In time, it would be nice if we could do the following:
- Have users specify the path of their ELF binary in the project config file, and have Bloom keep an eye on it for changes.
- On changes to the ELF file, have Bloom automatically update the target's program memory (maybe at the start/end of a debug session).
- Generate a diff of the new code and only update the addresses in program memory that have changed, leading to potentially faster uploads. Though we can only write to flash in pages, so that's worth keeping in mind.

Those are just my initial thoughts on this. They will likely change as I progress.

I will not be starting work on this until there is clear evidence of demand. Please add a 👍🏽 reaction or leave a comment on this issue, expressing your interest. Work will begin when 10 or more Bloom users express an interest in this.

Detach memory inspection panes from main Insight window

It would be nice if we could detach a particular memory inspection pane from the Insight window, so that it becomes a new window and is no longer constrained to the size of the Insight window.

Uploading code when debugWIRE is enabled

I've just started working with Bloom and I am very impressed! The insight dashboard is lovely and it is very helpful to set the registers so easily!

I'm using Bloom and a Snap to replace avarice and an Atmel Dragon. I write curriculum for college students and I'm using the ATmega328p as the standard processor. Having a more modern tool like Bloom is great! I don't use CLion, I use avr-gdb --tui to keep things simple.

That said, the Dragon is able to program the 328 via avrdude when debugWIRE is enabled. I haven't been able to perform the same task using a Bloom/Snap/avrdude combination.

I can upload code via MPLAB IPE as it will turn off debugWIRE, however, then I need to use avrdude and the Dragon to turn debugWIRE back on.

Any thoughts?

Thanks,
Lief

Allow building without including Insight

When only using Bloom as a GDB server this is not needed. Hiding insight behind a feature flag would shrink the binary and reduce dependencies making it easier to port it to other architectures and distributions.

Memory manipulation

Users should be able to manipulate target memories via the memory inspection pane and the snapshot viewer.

'Fill' function

Via the memory inspection pane, users should be able to select any number of bytes, and fill them with any given value. This function should be available via the context menu of the selected bytes.

'Restore' function

With a memory snapshot, users should be able to restore an entire snapshot to the target's memory. They should also be able to restore individual bytes, by selecting them and choosing the 'Restore' action in the context menu.

More to follow.

Export memory data via the memory inspection panes

Currently, users can view target memory via the memory inspection panes, but they have no way of exporting or even copying the data for processing in other applications.

Ideally, Bloom should allow users to export the data in some way, in some format.

View and manipulate target registers from the Insight window

With all of the data we possess in target description files, we should be able to obtain a description of every register on the target.
With this data, we can present the user with a means to view & manipulate register values from the Insight window.

The registers should appear in a panel to the left of the Insight window. From there, it should list the registers by their name and their value (in hexadecimal format). Double clicking on the register should open a new window, from which the user should be able to input a new value for the register.

Those are just my first thoughts. More to follow.

Support JTAGICE3 debug tool

Thanks to the kind people at Microchip, I now have a JTAGICE3 debug tool to test with.

Development for this had already begun and the changes are in the debug-tool/jtagice3 branch. For the most part, this ticket will cover testing of the new debug tool driver.

I'm hoping to have this included in the next release (0.9.0). Will post any updates on my progress on this ticket.

Explore potential fix for CLion prematurely killing Bloom's process

There is a known issue with CLion managing Bloom's process; At the end of a debug session, CLion issues a SIGKILL to Bloom's process, forcing it to shutdown immediately, with no opportunity to safely release the connected hardware (debug tool and target). This issue sometimes results in subsequent startup failures, as the hardware is left in an unknown state.

This issue was reported to CLion's developers some time ago: https://youtrack.jetbrains.com/issue/CPP-28843

There may be a way to fix this within Bloom;

Key points (some of which are assumptions):

Before CLion closes the GDB connection and sends the SIGKILL, it issues the detach command via GDB - this results in the d (detach) packet being sent to Bloom's GDB server.
CLion appears to wait for Bloom to respond to the detach packet, before issuing the SIGKILL.
The issue only occurs when CLion manages Bloom's process. We can detect this by walking the process tree and looking for certain substrings (like clion.sh) within the name of each parent process. (<- not sure if there's a better way of doing this)

With the above points in mind, we could force the TargetController to suspend upon receiving the detach command packet from the GDB client. Suspending the TargetController will mean disconnecting from the debug tool and target. Once the TargetController has been suspended, we will send an OK response back to the GDB client, allowing it to disconnect. This means that, by the time CLion sends the SIGKILL to Bloom, we will have already released the hardware.

I'm not sure if this will work. The purpose of this ticket is to confirm it and explore its feasibility. Even if it does work, it's a nasty hack which I hope we'll be able to remove at some point later on, once the issue in CLion is addressed.

If it does work, I'd like to get it into v0.11.0, which is due for release soon.

Support for the MPLAB ICE 4

I hope to purchase one of these at some point (but not sure when). It would be nice if Bloom could support it.

I will keep this ticket updated with any developments.

Persist memory regions across execution cycles

Currently, when using memory regions in the memory inspection panes, the regions are persisted across debug sessions. So stopping and starting a new session doesn't mean losing the defined memory regions. But this doesn't apply for execution cycles. When a user closes Bloom, they lose any defined regions, and have to recreate them upon starting Bloom again. This can be a source of frustration.

Outside of the Bloom configuration file (bloom.json), Bloom doesn't really have any place to save settings that are specific to both the project and the user. I don't think region definitions should be saved in bloom.json, as they are also specific to the user, not just the project.

I think it would be best to introduce a hidden settings directory, to live in the project root. Something like .bloom. In here, we will store all project-user specific settings. The directory should be excluded from the user's VCS. This will be made clear in the Bloom docs.

Tidy low-level USB driver code

The low-level libusb/hidapi USB driver code was written some time ago and is in need of a tidy. It's manually managing resources and doing other horrible things. Some of it is unused or redundant and can be binned.

Bloom and CLion Embedded GDB Server issues

In the planned use case for Bloom in our production ("education") environment, we would like to focus on the CLion internal Debugging functionality. We got it working after 1-2 hours of trying with the following steps and most of the stuff works, but we end up with some read memory errors.

As this is something I think that would nicely fit into the wiki later, I will document everything right away.

Setting up `Embedded GDB Server` in CLion

NOTE Normally CLion requires a gdbserver application here. However, as our Bloom command is actually our GDB Server we simply start bloom right here, which also has the nice effect of simply running automatically if we start debugging.

Starting a Debug session

Now a quick explanation, why you would choose Embedded GDB Server over Remote Debug. If you choose Remote Debug, CLion disables some embedded device features, like Peripherals. If we have these features, we can simply load an SVD File (yes an ARM targeted format, but the community has some tricks up its sleeve).

Loading an SVD File

We are happily greeted with the option to choose an SVD file here. However, in the AVR universe we only have .atdf files which contain this sort of information. But with the help of Rahix/avr-device we can simply convert these files and also patch some issues that may occur.

If done right, we can choose the newly generated svd file and start choosing our desired peripherals to debug.


	For now we simply choose the CPU peripheral to keep things simple. Choosing all peripherals would still work.

The current Bloom limit

Having the SVD loaded, we start causing some Bloom internal issues with the Read memory command.

As there aren't enough debug informations on hand as I installed with simply over the package manager, I will need to compile it and start testing to get deeper into the issue. I will continue to work on it and come back with any new information or even fix.

I'm really happy if I can help with the development or Wiki of this project. However my knowledge of the GDB Protocol is very limited. If you need any svd file that is supported by the mentioned repo, I'll be happy to send you the generated ones. Ask me on Discord via oltdaniel#8514.

Compiling on a Raspberry PI 4

For a project I need to run Bloom on a Raspberry PI. Or to be precise, I need to run the Bloom GDB Server on a Raspberry PI as I'm nut using the Insight Window. This still requires me, to fully install QT6 (which is a challenge in itself) and compile it for ARM64. But in the end it worked like a charm so I want to share it for anybody else who tries to do this and save them a few hours.

Prepare

First of all, we some custom online repositories in order to acquire the necessary dependencies,

Basic tools

# Some build tools
sudo apt install build-essential git wget
# Some other required libraries
sudo apt install libusb-1.0-0-dev libhidapi-dev

QT 6

# Import the SID debian package repository (no clue what it is, but it contains qt6 for arm64 and is official)
echo "deb http://ftp.de.debian.org/debian sid main" | sudo tee /etc/apt/sources.list.d/sid.list
# Now install dozen of qt6 packages
sudo apt update
sudo apt install qt6-base-dev qt6-tools-dev libqt6uitools6 libqt6svg6-dev libvulkan-dev libxkbcommon-x11-dev

NOTE: Somebody more familiar with this can probably even simplify these dependencies for QT6. But in the end this worked for me.

CMAKE

If you have CMake already installed, uninstall it sudo apt remove cmake. We've added a new repo with a newer CMake version. As Bloom requires (at the time of writing this) version 3.22 we need to install it now again. sudo apt install cmake.

QT 5

Wait what? Yes we need some QT5 tool /usr/bin/qt5/rcc if I remember correctly

# Install qt5
sudo apt install qtbase5-dev

PHP 8

# Load the gpp key
sudo wget -qO /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
# Register the package repository
echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list
# Install the PHP dependencies
sudo apt update
sudo apt install php8.0-cli php8.0-xml

Compile

git clone https://github.com/navnavnav/Bloom
cd Bloom
mkdir build/cmake-build-debug
cd build/cmake-build-debug
cmake ../..
cmake --build . --target Bloom

@navnavnav It would be really nice if we could disconnect the Insight and GDB Logic from another in the build process so the QT dependencies aren't always required. I would be willing to contribute as this is something I may need anyway, depending on the choice of my boss in the next weeks.

And thanks for Bloom. Else we couldn't use our current and old hardware to modernize the software and debugging part of the project.

Memory inspection via Bloom Insight

It would be useful to allow developers the ability to inspect that target's memories during a debug session.

Ideally, this would work with the target's EEPROM (where applicable), as well as the internal RAM.

I currently envisage this function to be presented in a similar way to the target registers. More to follow.

Support `target extended-remote` mode

This way of attaching has a few different semantics regarding loading, attaching, behaviour after detaching etc. Some of this can now be supported as load has been implemented. For a more complete list refer to the gdb documentation.

Other things like the behaviour after detaching would be great to match the intended way as the current implementation (keep connected after closing the debug session) would match extended-remote and not remote which is supposed to exit the gdb server. This should also improve integration with IDEs which expect the respective behaviour (e.g. CLion) without having to manually configure it in the bloom.json.

Tolerate USB debug tool theft - implement TargetController suspension

The TargetController currently operates with the requirement of target & debug tool access and control. If, for whatever reason, the TC loses access to the debug tool or the connected target, an exception will likely be thrown during a subsequent IO operation, leading to the TC shutting down, and the rest of Bloom following.

The problem with this is that there are some programs that can "steal" a USB device right out of Bloom's hands. Even if Bloom has claimed an interface on it. These programs use an old version of libusb, which I suspect is the problem. I suspect a soft-reset is being issued, directly or indirectly, resulting in Bloom losing access to the device. What's worse is that there doesn't appear to be a way of being notified when this occurs. So the only point where we'll know this has happened, is when the TC attempts to perform another IO operation on the device, and catches a DeviceCommuncationFailure exception.

This may not seem like much of an issue, as surely there aren't many other programs that the user will want to use, with Bloom running, that will steal the debug tool from us, right? Well, yes, but I'm afraid avrdude is one of the known culprits. It will aggressively take ownership of the debug tool the moment the user runs it, causing the TC to shutdown and Bloom following suit.

Because of the issue described above, the TC needs to be able to tolerate the theft of the connected debug tool. The way I think this should work is: When the TC catches a DeviceCommuncationFailure exception, it should try to figure out if this was caused by a greedy program, or due to some other reason that's out of our control (e.g the user disconnecting the device). If it was some other issue, we can simply do as we currently do now - shutdown. But if it was caused by a greedy program, the TC should go into what I'm calling a "suspended state", where it release the device resources and sends the appropriate event to the DebugServer, to have it terminate any active debug session. In this suspended state, the TC should only listen for a few events. One of which should be the DebugSessionStarted event. When the DebugServer sends this event, we know that the user wants to begin another debug session, so at this point, the TC can leave the suspended state and attempt to reconnect to the debug tool. If successful, the TC should carry on as normal, but if it fails to reconnect to the device, then it should just shutdown.

Nothing is set in stone with the approach, but those are just my first thoughts on this. Another, similar approach would be to stop hogging the debug tool in the first place. So have the TC go into the suspended state the moment the active debug session ends. Something to think about.

Upgrade Qt to 6.2 LTS

Bloom is currently built and shipped with Qt 6.1.2 binaries. Standard support for this version has ended, and I've noticed some potential concurrency issues in this version (which may be false positives, not sure yet). These issues were apparently addressed, to some extent, in some recent changes that were merged into the 6.4 branch. I'm hoping these changes will make there way up to the 6.2 LTS.

Given that Bloom is using an outdated version, I intend to upgrade to 6.2 LTS. Ideally, I would like to do this after those changes have been merged into 6.2.

I will keep an eye on Qt releases and update this ticket when I know more.

Move away from event-based TargetController interface

Currently, the TargetController component serves other components via an event-based mechanism; When another component (such as Insight or the DebugServer) needs to perform any action on the connected target or debug tool, the component will trigger an event and wait for the TargetController to respond.

This is a misuse of events. Events should not be triggered with the expectation of a response.

I would like to refactor the TargetController component and introduce a new inter-component interface that is not event-based. The new interface will be command-response based; The TargetController will receive and process commands and return the appropriate responses. Events can still be used within the TargetController, but just not as the inter-component interface.

Because the TargetController interface is already contained within the TargetControllerConsole class, I won't have to make any significant changes to other components within Bloom (because all of them use the TargetControllerConsole class to interface with the TargetController).

I will start on this once I have finished the refactoring of the GDB debug server (which will be very soon).

Missing support for attiny45

The next controller I had ready for testing was an attiny45, which is not supported. I though I could just copy the attiny45.atdf file, change the extensions and the name of the top node, but that didn't work (target name not recognised).