[bug #44128] sprintf fails when printing floats and code is in flash address > 0xffff

[avrs-admin]

Fri 30 Jan 2015 12:26:12 AM CET

I was performing some test with bootloaders on atmega1284 (testing if they can program all the available flash) and one test included printing a floating point number, the reason is in the file ftoa_engine which store some number in a table and read them using lpm. It works fine when the table is stored in a low memory address ( < 64K words) but when the table is stores in the upper memory region the lpm instruction cannot load the data.

This issue was migrated from https://savannah.nongnu.org/bugs/?44128

[sprintersb]

ftoa_engine.S has a lookup table located in .progmem.data. The assumption is that .progmem.data fits in the lower 64 KiB of program memory; if not, then too much progmem is used.

As an extension, the table could be moved to progmemx.data, but then the address computations and accesses have to be adjusted to ELPM or ELPMx which is not that straight forward because assembly.

As a simple addition, we could add an assertion to the linker script, so that at least no wrong code is generated.

[sprintersb]

Fixed by 32a152e8878f9643f7d1696d27b616ed1b3b1dca.

Though there are more places that use LPM on ELPM devices, see issue #962. To date that issue is only partially fixed by upgrading some libc functions. However there is a bunch of libm asm function, too, that read coefficients using LPM.