Very slow debugging

[lrustand]

Hello again, I am using a MPLAB Snap to debug an Atmega2560 and this works great, however the whole debugging process is very slow, stepping a single line of code takes roughly 5 seconds, and flashing a new program takes almost one full minute. This is a bit annoying when trying to do fast iterations of debug -> code -> flash -> debug.

I have enabled debug output in Bloom and see that a lot of time is spent on backing up and re-flashing the EEPROM, however I have no need for this. Is there any way of disabling this in Bloom?

Also when single stepping through code I see in the output from Bloom that it is setting a breakpoint, resuming running, breaking on the breakpoint, then removing breakpoint again, instead of simply just stepping. I wonder if this is the cause of why it is so slow. Is this because of a limitation in the (reverse engineered?) protocol of the Snap?

[navnavnav]

The MPLAB Snap is quite slow, and OCD with JTAG is noticeably slower than the other physical interfaces, in my experience. Not much I can do about this.

stepping a single line of code takes roughly 5 seconds

This is probably due to the back-and-forth with GDB and Bloom - GDB will step a single instruction at a time, so stepping a single line could mean a lot of back-and-forth with GDB. Range stepping may help with this, but Bloom doesn't support this ATM.

A lot of time is spent on backing up and re-flashing the EEPROM, however I have no need for this. Is there any way of disabling this in Bloom?

When programming the target, we have to erase its program memory. With EDBG tools (like the Snap), according to the EDBG protocol documentation, JTAG targets only support chip erase mode, meaning we have to perform a full chip-erase when erasing program memory. Some AVR targets have a fuse that can be set to preserve EEPROM when erasing the chip, but Bloom does not utilise this ATM. This is why Bloom has to backup the EEPROM and restore after a chip erase. There's no way to disable this ATM.

when single stepping through code I see in the output from Bloom that it is setting a breakpoint, resuming running, breaking on the breakpoint, then removing breakpoint again, instead of simply just stepping.

This is something GDB does. Range stepping may help here, but I'm not sure about that. I might have a look at implementing support for range stepping at some point, but won't be anytime soon.

[lrustand]

I am a bit confused why continuing over a line is faster than stepping over it, since it seems as Bloom/GDB under the hood is setting a breakpoint and continuing even for single stepping.

That breakpoint being set is at an address which doesn't match any of the instructions you stepped over, so my guess is that it has nothing to do with the stepping. By default, GDB removes and sets breakpoints every time the target halts and resumes, respectively. Do you have any other breakpoints you've set in the code? Try removing them, then step again - does GDB still set and remove a breakpoint then?

Aha, it does not do this when I do not have any other breakpoints.

[lrustand]

Usable for you, but not for others who don't want their EEPROM data to be wiped every time they update their program. @mraardvark how does Studio handle this? Does it set the preserving EEPROM fuse before erasing JTAG targets? If a user programs their JTAG target without updating EEPROM, is the EEPROM data wiped?

Does Bloom still wipe the EEPROM if the user has set the fuse to preserve it?

[navnavnav]

Does Bloom still wipe the EEPROM if the user has set the fuse to preserve it?

Yes, because Bloom isn't capable of reading that fuse ATM. I'm not sure if all AVR targets even have that fuse. This is why i'm curious to know how Studio does it.

[lrustand]

Yes, because Bloom isn't capable of reading that fuse ATM.

Okay, I was under the impression that setting this fuse actually disabled something in hardware so that Bloom would not be able to wipe it, but I guess this is not the case then.

[navnavnav]

Okay, I was under the impression that setting this fuse actually disabled something in hardware so that Bloom would not be able to wipe it, but I guess this is not the case then.

Sorry, my previous comment wasn't clear - the fuse does prevent Bloom from wiping EEPROM during a chip erase, but Bloom has no idea about it, so it will still take a copy and restore.

It looks like Studio gives the user the option to have it automatically set that fuse. This may be something Bloom could do. Something to look at in the future.

[mraardvark]

how does Studio handle this? Does it set the preserving EEPROM fuse before erasing JTAG targets? If a user programs their JTAG target without updating EEPROM, is the EEPROM data wiped?

Studio usually programs flash, but always goes in and manipulates the OCDEN fuse for debugging (and switches it off afterwards). While its in there it can also set the preserve EEPROM fuse, but this is optional, and in the end the user's problem to either set the fuse itself or the debug-option to set the fuse. I think all AVRs have this fuse

I'd have to maintain that cached data by updating it every time a breakpoint is set/removed.

You don't have to do this - also if you 'take a copy' of flash that is programmed in outside of GDB to populate the cache with, then assume its constant after that? (or am I missing something...)

TargetMemoryType::EEPROM

If I remember correctly, inside prog mode EEPROM_PAGE might be faster?

By default, GDB removes and sets breakpoints every time the target halts and resumes,

These devices have the most generous number of hardware breakpoints of all AVRs (4?) - are they being used? Software breaks are very much slower...

[navnavnav]

Studio usually programs flash, but always goes in and manipulates the OCDEN fuse for debugging (and switches it off afterwards). While its in there it can also set the preserve EEPROM fuse, but this is optional, and in the end the user's problem to either set the fuse itself or the debug-option to set the fuse. I think all AVRs have this fuse

So if the user hasn't set the fuse, and hasn't configured Studio to do it automatically, what does Studio do when programming? Does it just wipe the EEPROM?

You don't have to do this

IIRC, GDB reads flash at the breakpoint address, shortly after setting a breakpoint. If it doesn't see the BREAK instruction at that address, it starts misbehaving. This is why I couldn't use EDBG memory types where the breakpoints were being filtered out. But this was a while ago - I may be misremembering.

also if you 'take a copy' of flash that is programmed in outside of GDB to populate the cache with, then assume its constant after that? (or am I missing something...)

Assuming I could just take a single copy and assume it's all constant from then on, this would still mean adding a lot of complexity, as it would be an optional cache, only available once the user has attempted to program the target during that debug session. All of this for a small performance gain, which may be negligible on other targets like UPDI, PDI and maybe even debugWire - it just doesn't seem worth it.

If I remember correctly, inside prog mode EEPROM_PAGE might be faster?

We're already using EEPROM_PAGE when programming mode is enabled, TargetMemoryType::EEPROM is an internal enum value, not part of the EDBG protocol:

Bloom/src/DebugToolDrivers/Protocols/CMSIS-DAP/VendorSpecific/EDBG/AVR/EdbgAvr8Interface.cpp

Lines 738 to 762 in 0583283

	case TargetMemoryType::EEPROM: {
	switch (this->configVariant) {
	case Avr8ConfigVariant::UPDI:
	case Avr8ConfigVariant::XMEGA: {
	avr8MemoryType = Avr8MemoryType::EEPROM_ATOMIC;
	if (this->configVariant == Avr8ConfigVariant::XMEGA) {
	// EEPROM addresses should be in relative form, for XMEGA (PDI) targets
	startAddress -= this->targetParameters.eepromStartAddress.value();
	}
	break;
	}
	case Avr8ConfigVariant::MEGAJTAG: {
	avr8MemoryType = this->programmingModeEnabled
	? Avr8MemoryType::EEPROM_PAGE
	: Avr8MemoryType::EEPROM;
	break;
	}
	default: {
	avr8MemoryType = Avr8MemoryType::EEPROM;
	break;
	}
	}
	}

These devices have the most generous number of hardware breakpoints of all AVRs (4?) - are they being used? Software breaks are very much slower...

Bloom doesn't use HW breakpoints ATM.