DeviceOS 3.2.0 compiler warning - 'FLASH_CheckValidAddressRange'

Hey all - I have some pretty boring boron code that compiles clean against 3.1.0 - but when trying 3.2.0 toolchain, I get a fairly ominous:

Creating /Users/chris/development/ferry_control/target/3.2.0/boron/platform_user_ram.ld ...
MCU/nRF52840/src/flash_mal.c: In function 'FLASH_CheckValidAddressRange':
MCU/nRF52840/src/flash_mal.c:273:30: warning: comparison of unsigned expression in '>= 0' is always true [-Wtype-limits]
  273 |         return (startAddress >= 0x00000000 && endAddress <= 0x100000) ||
      |                              ^~
MCU/nRF52840/src/flash_mal.c:279:29: warning: comparison of unsigned expression in '>= 0' is always true [-Wtype-limits]
  279 |         return startAddress >= 0x00000000 && endAddress <= EXTERNAL_FLASH_SIZE;
      |                             ^~
Creating /Users/chris/development/ferry_control/target/3.2.0/boron/platform_user_ram.ld ...
   text    data     bss     dec     hex filename
  41064     544     500   42108    a47c /Users/chris/development/ferry_control/target/3.2.0/boron/ferry_control.elf




Creating /Users/chris/development/ferry_control/target/3.1.0/boron/platform_user_ram.ld ...
Creating /Users/chris/development/ferry_control/target/3.1.0/boron/platform_user_ram.ld ...
   text    data     bss     dec     hex filename
  40984     540     620   42144    a4a0 /Users/chris/development/ferry_control/target/3.1.0/boron/ferry_control.elf


I’ve done clean app and deviceOS (local), didn’t help. I’ve no idea what the above means, but it sounds like something not to be ignored.

Any clues as to how to resolve this?


These are merely warnings, hence the build does not fail.
They just tell you that the first part of your statement is superfluous as absolutely any value that variable may take on will satisfy the condition :wink:

But since you spent the time to type that statement the “new” compiler assumes you intended something other than you wrote and hence is kind enough to give you a heads-up while the old one just went with “don’t know, don’t care” :see_no_evil:

However, if you indeed meant what you wrote it would be much easier to just remove the startAddress >= 0 part of the statements entirely.
What you wrote is virtually the same as if (true && somethingElse) which is the same as if (somethingElse) but more complicated and hence “expensive”.


Hey ScruffR - ya I kinda get what the compiler is telling me, but this MCU branch is not my code and looks like it’s something to do with flash memory management.

Is this a deviceOS include, or something else?

If deviceOS, kinda didn’t expect to see any “just ignore it” warnings with 3.2.0, esp given it’s tagged for production use. If not deviceOS, then one of my includes is suspect and I’ll need to decide what to do about it.

I suppose I could do an empty setup/loop and see if it still happens

I see - that code can be found in device OS here

Maybe someone at Particle can add some compiler directive to not flag this warning (or just comment out that part).

e.g. like this

        return (/*startAddress >= 0x00000000 &&*/ endAddress <= 0x00100000) 
            || (  startAddress >= 0x12000000 &&   endAddress <= 0x20000000);
1 Like