Enable support for JTAG and UPDI physical interfaces

[navnavnav]

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.

[navnavnav]

Quick update on this: I've ordered some new AVR parts for UPDI and JTAG testing. Looking to have dev work complete in the next 1-2 weeks. This will be available for v0.1.0.

[navnavnav]

I have the JTAG interface working. I can control execution on the target, read & write memory and use the Insight window:

But there are some intermittent issues with the EDBG devices returning error code 0x3C, which indicates a timeout. I need to look into this further before I can feel comfortable with JTAG support.

As for UPDI, I'm afraid the parts that I ordered have been held up at the supplier's end. I'm probably going to place another order with another supplier sometime next week, as the current supplier has given me an ETA of July!

Given the delays with UPDI testing, I will likely ship JTAG support in its own release, and UPDI can come after.

[navnavnav]

Bloom now supports JTAG from version 0.1.0. See https://bloom.oscillate.io/releases

[navnavnav]

Starting development for UPDI support today.

[navnavnav]

Have made good progress with UPDI support. Have implemented parameter extraction for the UPDI config variant and got the activating of the physical interface working. Unlike debugWire and PDI sessions, UPDI sessions appear to require some target parameters to be set before target activation (activating the physical interface). This means users will be unable to use the generic "avr8" target configuration value in their project config file, for UPDI targets (as we cannot identify the target before activation). Users will have to supply the exact target name in their config, for UPDI targets.

The current implementation does not include support for high voltage UPDI activation (https://microchipdeveloper.com/mplabx:avr-updi-info). Bloom will disable high voltage activation on the debug tool, for all UPDI sessions, via the OPTIONS parameter defined in the EDBG AVR8 generic protocol (parameter ID/address: 0x06, OPTIONS context ID: 0x03). We may add support for this later, but I don't see that happening anytime soon, TBH. Not unless there is a real demand from users.

Also had some issues with target signature extraction, using the 'Get device ID' EDBG AVR8 command - it doesn't return the target signature for UPDI targets. Not sure if this is expected behaviour, or if I'm doing something wrong. For now, I've implemented the signature extraction via a memory read, where we just read the three signature bytes directly from memory (using the signature base address, which we extract from the TDF).

Testing with the AVR128DB28 target.

✅ Insight window works ✅ Reading & writing memory from SRAM works ✅ Setting & deleting breakpoints works ✅ GPIO pin manipulation works ✅ Flow control commands work

There's still some more work to do before I'll be happy with UPDI support:

• Update TDF validation scripts to ensure that all TDFs for UPDI targets possess the required data for the UPDI params. And ensure that the data meets the size constraints that appear to be unique to UPDI sessions.
• Look into issue with GDB attempting to read variable data from incorrect SRAM address (this may be an issue with GDB)
• Update AVR8 target config validation to prevent the user from using the generic "avr8" target config value in the config file.

Given how things are going, UPDI support will likely be included in the next release. But not sure when that will be ATM.

[navnavnav]

Development for UPDI support is complete. The changes have been merged into the develop branch, ready to be included in the next release.

I'm not sure when I'll create the next release, just yet. Will close this issue once the changes have been released.

[navnavnav]

Bloom now supports the UPDI physical interface, from version 0.3.0. See https://bloom.oscillate.io/releases

Closing this now.