Nordic NRF52x Devices 14.2R2

Sysprogs forums Forums VisualGDB Nordic NRF52x Devices 14.2R2

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #20656
    jisea
    Participant

    Hello,

    I have been working with the Nordic NRF52x Devices using VisualGDB 14.2R2 for a while and it seems in the latest version has a substantial increase in the flash usage regarding the previous versions.

    For example in the previous version my flash usage was below 20%, now it jumps to 42% which affect my application operation where the flash usage is critical. The same behavior was seem in all the Sample Projects.

    Is that huge flash usage increase going to be fixed soon?

     

    Thanks,

    Jose

     

    #20659
    support
    Keymaster

    Hi,

    This might be caused by some internal changes in the Nordic SDK. As the SDK comes directly from Nordic, its contents are outside our control, however we can help you understand what is causing this and find a possible workaround.

    Please create a separate project using each SDK version and run “arm-eabi-objdump -h <ELF file>” on each of them. Then compare the dumps using a diffing tool (e.g. KDiff3). Most likely you will observe one of the following:

    1. The new file contains more sections than the old file and the new sections contribute to the footprint increase (note that only the sections marked with ALLOC actually consume device memory). Those sections were introduced in one of the recent SDK versions and you might be able to disable them by excluding some source files (refer to Nordic documentation for details).
    2. The softdevice section is considerably larger. This should not normally happen, so let us know the old/new sizes if you observe it and we can double-check.
    3. The regular .text and .data sections are larger (most likely). This comes from extra functions added to the SDK and can be narrowed down by loading both binaries in Embedded Memory Explorer and comparing symbol sizes/names. Again, you might be able to exclude some of the new code by disabling the corresponding configuration defines, or commenting out support for cases that you don’t need.

    Hope this helps. If not, let us know your findings and we can advise you further.

Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.