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
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
