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

[bloombloombloom]

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

[navnavnav]

Thanks for reporting this, @maximevince

I think I see the problem here.

When I wrote the driver for the Xplained Pro debug tool, I found that it had issues with any memory access (read or write) that exceeded 256 bytes in size. For this reason, a software limit was introduced for that debug tool.

The flash page size for the atxmega128a1u is 512 bytes, so this effectively means we cannot access flash memory on that target, via the Xplained Pro, with this soft limit.

However, XMEGA and UPDI enabled targets don't actually require flash memory accesses to be paged. So I think that check to ensure that the flash page size does not exceed the maximum memory access size is not necessary for XMEGA or UPDI targets.

I'm going to remove it and prepare an unofficial build for you. It will be ready in the next 30-45 mins.

[maximevince]

I've assumed that you're on a Debian-based system, but let me know if you need an RPM instead.

Like the memes say: "I'm on Arch, btw", but the Debian release works fine, thanks!

The build you created connected immediately! Awesome.
I'll test flashing some sample apps in the next couple of days. Thanks!

Worst-case I have a PICKit4 which I could try as well

[xedbg]

I tested with the Atmel-ICE and the Power Debugger - both worked fine. The issue only occurred when using the onboard debugger.

Ah, of course, yes - and the explanation there still holds. So never mind me, just getting forgetful ;)

[navnavnav]

Thanks for confirming @maximevince

BTW, I've just shipped the bug fix release v0.8.3, with that fix and a fix for another issue I noticed with target package variants with a large pin count (such as those available for the ATxmega128A1U). You can download the new release via https://bloom.oscillate.io/download

Thanks

[maximevince]

Wow, that was FAST

[navnavnav]

Wow, that was FAST

You caught me at a good time 😃

Unofficial build: https://bloom-public-bucket.s3.eu-west-1.amazonaws.com/misc/Bloom-0.8.2-Linux-unofficial.deb

I've assumed that you're on a Debian-based system, but let me know if you need an RPM instead.

Remove your current build:

sudo apt-get remove bloom;

Install the new build:

sudo apt install /path/to/unofficial/build.deb

Then try running Bloom again from your project directory. Please let me know how it goes.

Also BTW, judging from a very quick glance at the documentation for the XMEGA A1U Xplained Pro board, you probably need to use the PDI physical interface. But some XMEGAs support JTAG as well, so JTAG may work.

[xedbg]

FWIW - I do recall you mentioning this issue, but I am still not convinced... on paper the edbg protocol max frame size is about 900 bytes, so 512 byte payloads should be possible... i should try to set this up in python and test it out...

[navnavnav]

Hi @xedbg, I described the exact AVR command frame being sent to the Xplained Pro here.

The board I was using was the ATMEGA4809 XPLAINED PRO. I couldn't replicate the issue when connecting any other debug tool to the target, via the UPDI pins provided on the board:

I tested with the Atmel-ICE and the Power Debugger - both worked fine. The issue only occurred when using the onboard debugger.

If you are unable to replicate it, please let me know and I'll give it another go.