Thanks for any idea that can be shared.
It is probably a near vs. far address problem. Most pointers, like "const char *" or "const __FlashStringHelper *", are 16-bit addresses (i.e., "near" in the first 64K).
For function calls to "far" destinations, the linker is "supposed" to use a "trampoline" to get there, jumping to a "near" address first. I get the impression that far calls are usually handled correctly.
For "far" data, I can't find anything other than managing it yourself with explicit declarations like uint_farptr_t and xxxx_PF variants, like memcpy_PF.
I don't think FLASH data (e.g., declared via the F macro) is guaranteed to be anywhere in particular. The sketch code is preferentially loaded in the first 64K, but libraries may extend past that boundary. I wonder if the code size pushes FLASH data past the 64K address boundary. Then it is dereferenced incorrectly by code that expectes near pointers (e.g., Print methods).
To force the code to use far pointers for FLASH data, you have to do something like this:
const char someFlashData[] PROGMEM = "stringity string.";
void farPrint( const char *farFD )
{
uint_farptr_t farAddr = pgm_get_far_address( farFD );
do {
char c = pgm_read_byte_far( farAddr++ );
if (!c)
break;
Serial.write( c );
}
}
void foo()
{
farPrint( someFlashData );
}
Untested. Functions/macros documented here.
If the AES library is using FLASH data, it would have to be modified to always use far pointers. If it's just your sketch that is using FLASH data, you should be able to modify all the F macro uses to do something different. Initial values may also fall into that category: they are loaded from FLASH into the RAM variable being initialized.
That's about all I can suggest. Free advice is worth what you paid for it, my $0.02, YMMV, etc., etc.
You've been warned. 