Specifying RAM address in .ld does generate spurious flash section

Question

Hello there, 
 
 In order to have a continuous RTT debug during DFU, I followed advices found in: 
 - https://devzone.nordicsemi.com/f/nordic-q-a/20708/rtt-logging-from-application-started-by-bootloader 
 - https://devzone.nordicsemi.com/f/nordic-q-a/30310/easy-way-to-merge-bootloader-and-application-rtt-output 
 
 It seems to work, but the bootloader's .hex generated has spurious sections (full of zero) that correspond to the 3 blocks for which the address is fixed in my .ld file: 
 hexinfo.py build/nrf52832_xxaa_s132.hex

- file: 'build/nrf52832_xxaa_s132.hex'
entry: 0x700080E5
data:
- { first: 0x00072000, last: 0x0007CEAF, length: 0x0000AEB0 }
- { first: 0x0007E1D8, last: 0x0007E5D7, length: 0x00000400 }
- { first: 0x0007E9D8, last: 0x0007EA1B, length: 0x00000044 }
- { first: 0x0007EA58, last: 0x0007EACF, length: 0x00000078 }
- { first: 0x10001014, last: 0x1000101B, length: 0x00000008 }

Extracts of my .ld file: 
 MEMORY
{
 FLASH (rx) : ORIGIN = 0x72000, LENGTH = 0xC000

 /** RAM Region for bootloader. This setting is suitable when used with s132. */
 RAM (rwx) : ORIGIN = 0x20002C00, LENGTH = 0xc400

 /** Location of bootloader setting in flash. */
 BOOTLOADER_SETTINGS (rw) : ORIGIN = 0x0007F000, LENGTH = 0x1000

 /** Location in UICR where bootloader start address is stored. */
 UICR_BOOTLOADER (r) : ORIGIN = 0x10001014, LENGTH = 0x04

 /** Location of mbr params page in flash. */
 MBR_PARAMS_PAGE (rw) : ORIGIN = 0x0007E000, LENGTH = 0x1000

 /** Location in UICR where mbr params page address is stored. */
 UICR_MBR_PARAM_PAGE(r) : ORIGIN = 0x10001018, LENGTH = 0x04
}

SECTIONS
{
 [...]
}

SECTIONS
{
 [...]

 . = ALIGN(4);
 .dfu_trans :
 {
 PROVIDE(__start_dfu_trans = .);
 KEEP(*(.dfu_trans))
 PROVIDE(__stop_dfu_trans = .);
 } > RAM

 .rtt_ac_up 0x20004000 :
 {
 KEEP(*(.rtt_ac_up))
 } > RAM

 .rtt_ac_down 0x20004800 :
 {
 KEEP(*(.rtt_ac_down))
 } > RAM

 .rtt_segger 0x20004880 :
 {
 KEEP(*(.rtt_segger))
 } > RAM

} INSERT AFTER .data

The problems: 
 - 0x7e000 is reserved for MBR. How could the linker allow this ? 
 - since data should be handled by RTT, I do not want to use NOLOAD 
 - why can't those sections remain in bss (the zones are zeroes only). It inflates the .hex for nothing (and especially forbids a DFU of the bootloader since the new one does not fit in the previous one, which is why I found this strange thing). 
 
 Notes: 
 - SDK 12.0.0 & gcc 4.9 2015q3 under linux (juste Makefile) 
 - if I change the RAM's start address, the flash address changes (but in the reversed direction, RAM address increase implies Flash address decrease). 
 - with gcc 5.4.1 (the one shipped with my linux distro), the flash address start is changed, but the problem reappears by changing the RAM

marto · Accepted Answer

Hi Bj&oslash;rn, 
 
 What is the difference between your proposal and simply specifying NOLOAD (that I wanted to avoid) ? 
 .rtt_ac_up 0x20004000 (NOLOAD) :
 {
 KEEP(*(.rtt_ac_up))
 } > RAM

 .rtt_ac_down 0x20004800 (NOLOAD) :
 {
 KEEP(*(.rtt_ac_down))
 } > RAM

 .rtt_segger 0x20004880 (NOLOAD) :
 {
 KEEP(*(.rtt_segger))
 } > RAM

Do you confirm that there is no solution to zero-initialize these variables without embedding zeroes of the size of the variables ? 
 
 Regarding the Segger's part, how does the license play when publishing such diffs: 
 diff --git a/xxx/nrf52/lib/nrf-sdk/external/segger_rtt/SEGGER_RTT.c b/xxx/nrf52/lib/nrf-sdk/external/segger_rtt/SEGGER_RTT.c
index 9d399e8..f4bcf1f 100644
--- a/xxx/nrf52/lib/nrf-sdk/external/segger_rtt/SEGGER_RTT.c
+++ b/xxx/nrf52/lib/nrf-sdk/external/segger_rtt/SEGGER_RTT.c
@@ -945,6 +945,23 @@ int SEGGER_RTT_SetNameDownBuffer(unsigned BufferIndex, const char* sName) {
 return r;
 }
 
+/*********************************************************************
+*
+* SEGGER_RTT_Reinit
+*
+* Function description
+* Reinitializes the RTT Control Block.
+*
+*/
+void SEGGER_RTT_Reinit (void) {
+ // Clean-up ID since setting only "SEGGER RTT" is not enough
+ // to be detected by Jlink (at least V630c)
+ SEGGER_RTT_CB* p;
+ p = &_SEGGER_RTT;
+ memset(p->acID, 0x00, sizeof(p->acID));
+ _DoInit();
+}
+
 /*********************************************************************
 *
 * SEGGER_RTT_Init
diff --git a/xxx/nrf52/lib/nrf-sdk/external/segger_rtt/SEGGER_RTT.h b/xxx/nrf52/lib/nrf-sdk/external/segger_rtt/SEGGER_RTT.h
index 4d3a0bb..56da5e4 100644
--- a/xxx/nrf52/lib/nrf-sdk/external/segger_rtt/SEGGER_RTT.h
+++ b/xxx/nrf52/lib/nrf-sdk/external/segger_rtt/SEGGER_RTT.h
@@ -108,6 +108,7 @@ int SEGGER_RTT_ConfigDownBuffer (unsigned BufferIndex, const char* sNam
 int SEGGER_RTT_GetKey (void);
 unsigned SEGGER_RTT_HasData (unsigned BufferIndex);
 int SEGGER_RTT_HasKey (void);
+void SEGGER_RTT_Reinit (void);^M
 void SEGGER_RTT_Init (void);
 unsigned SEGGER_RTT_Read (unsigned BufferIndex, void* pBuffer, unsigned BufferSize);
 unsigned SEGGER_RTT_ReadNoLock (unsigned BufferIndex, void* pData, unsigned BufferSize);
 
 The RTT license says: 
 > Modified versions of this software in source or linkable form * > * may not be distributed without prior consent of SEGGER 
 Should we contact Segger ? 
 
 Thanks, 
 Marc.

Specifying RAM address in .ld does generate spurious flash section

Top Replies