BUG in nrf52_common.ld?

[Torsten Robitzki]

Using GCC 4.8.4, it seems to me, that the nrf52_common.ld shiped with the sdk version 12.2 contains a bug:

If an image is defined where the .text data fits into the flash, but where the .data initialization data would lead to an overflow of the flash, the linker does not complain about the overflow.

The reasons for this seems to be that the linker script doesn't declare the .data section to be within the flash MEMORY. Adding AT > FLASHto the end of the .data section declaration seems to fix the issue:

__etext = .;

.data : 
{
    __data_start__ = .;
    *(vtable)
    *(.data*)

    . = ALIGN(4);
...
    __data_end__ = .;

} > RAM AT > FLASH

The start of the section seems a little bit suspicious to me too. What happens if __etext is not properly aligned?

[David García Polo]

Hi

I have checked the problem and you are entirely right. Nevertheless instead of your proposed solution what do you think of an assert? (Adding some spacings on underscores to avoid text formatting)

{code} Wrong code, see bellow. {endcode}

The symbols used allow for users to add sections after .text (before .ARM.extab) and after .data (before .bss) and still be covered.

I will modify the linker scripts on a future release if you do not think there is any problem.

[Torsten Robitzki]

Well, I think my fix would be much more straightforward, but when you fix works as well, then it's once to me, how this is fixed :-) Anyway: Thank you!

[David García Polo]

yes, I had noticed it does not work. thanks.

[David García Polo]

No coding without sleeping.

{code} /* Check if text sections + data exceeds FLASH limit */ DataInitFlashUsed = bss_start - data_start; CodeFlashUsed = __etext; TotalFlashUsed = CodeFlashUsed + DataInitFlashUsed; ASSERT(TotalFlashUsed <= LENGTH(FLASH), "region FLASH overflowed with .data and user data") {code}

[Dave_couling]

Does this bug apply to SDK 12.3.0?

[Sigurd]

Hi Dave_couling ,

Yes, this issue applies to the current SDK versions. The current version of the MDK(8.14.1) does not include this fix. I believe it will be included in the next upcoming version of the MDK.