IAR to GCC porting issue with debugging the code

Question

I ported an existing application(modified from SDK 15.2.0) from IAR compiler to GCC compiler in windows environment. I used the SEGGER SES for final linking using the default flash_placement.xml file. During the linking I provided the entry point as 'Reset_Handler'. The compiling and linking was successful, but when I flashed the program to controller, its stuck in Soft device Flash address range.(I have pre-loaded the S132 soft device hex file). 
 I can see that the Reset handler function is getting called and then nRFInitialize, followed by SystemInit() in system_nrf52.c file. In this function while executing errata_12() function, it jumps soft device address range and then stays there. Before and after screenshots below: 
 Before: 
 
 After: 
 
 And stuck in this line: 
 
 Need assistance for the startup sequence to jump to application main. 
 
 Also Need further information as to 
 1. How the startup sequence works in nRF52832 device? Whats the reset address? 2. How the Soft device software handles the startup sequence and how it jumps to address of 'Reset_handler' function when this address value can be dynamic? 3. As I am compiling my code in GCC does this affect the precompiled soft device software? How do I compile soft device in GCC too? Can I get its symbol file(.elf/.out) so that I can debug my code?

wpaul · Accepted Answer

The start-up behavior is defined by the ARM Cortex-M4 CPU design. I recommend having this manual in addition to the Nordic nRF52832 product spec handy: 
 http://infocenter.arm.com/help/topic/com.arm.doc.dui0553b/DUI0553.pdf 
 Refer to the vector table description in section 2.3.4. You'll see that the first few words are the initial stack pointer value and the reset vector. 
 The default vector table location at CPU power-up or reset is at address 0x0, which is in the flash. At power-on or reset, the CPU will load the SP register with the "Initial SP value" (offset 0x00000000) and load the program counter (PC) register with the "Reset" value (offset 0x00000004). The CPU will jump to that address and begin execution. 
 Subsequent fields are used for other exception vectors. The first 16 slots in the vector table are reserved for exceptions that are related to the ARM CPU itself. This includes NMI, faults, system call handler and the systick timer interrupt. (All ARM CPUs have one built in systick timer.) All vectors after that are vendor-specific. For the Nordic chip, this means the radio, UARTs, SPI, I2C, RTC and all other peripheral devices. (This is how it works in the ARM SoC works: ARM designs the CPU core, the SoC vendor designs everything else and puts everything together.) 
 You'll notice that the vector addresses (not including the SP value) are all odd numbers (i.e. the LSB is set) even though the actual handler is at an even numbered address. With ARM, all instructions are either 2 bytes (thumb mode) or 4 bytes (ARM mode). This means that the LSB is never used for address decoding. Instead it's used to indicate if the target address contains thumb mode code or ARM mode code. Setting the LSB means thumb mode. 
 So if the reset vector address is 0xA81, that means the actual code starts at addres 0xA80, and it's thumb mode code. 
 If you create an application which does not use the SoftDevice, then you can store your code starting at address 0x0 in the flash and the vector table in your code will control everything. 
 When you use the SoftDevice, then it goes at offset 0x0 instead. Your application goes somewhere else. With the latest S140 SoftDevice, that somewhere else is 0x26000. So your vector table ends up at 0x26000 instead of 0x0. The SoftDevice actually captures all exception events. Some it handles itself (like the radio interrupt), while others it will forward to the application. The idea is that the application code doesn't really know that any of this is happening. The only thing that changes between these two cases is that the linker script puts your application's vector table at 0x26000 instead of 0x0. 
 This adds a little latency to interrupt processing because a bit of SoftDevice code is executed before it jumps to your own handler, but this is kept as small as possible. 
 The Cortex-M4 processor also has a Vector Table Offset Register (VTOR). You can actually use this to move the vector table to another location, i.e. make the CPU use a base address other than 0x0 when jumping to an exception handler. This has to be set by software though: you always have to have the initial vector table with (at bare minimum) the reset vector and stack pointer at address 0x0 in order for the CPU to boot correctly, and then you can have your code move it later. 
 With the SoftDevice in place, the CPU reaches the SoftDevice's reset handler first. Actually, it reaches the boot block -- the SoftDevice .hex file actually has the boot block at address 0x0 and the SoftDevice starting at 0x1000. The boot block will get control of the CPU first, and then eventually it will branch to the reset vector at 0x26004, which passes control to your application's reset vector. (Nordic doesn't distribute the source code for this, so there's no way to know exactly what it does.) 
 -Bill

Sigurd · Answer

Here is an example on how a flash_placement.xml file in SDK 15.2 looks like (from ble_app_beacon example): and in the SES project file(.emProject) we have the following, snippet: linker_section_placement_file="flash_placement.xml" linker_section_placement_macros="FLASH_PH_START=0x0;FLASH_PH_SIZE=0x80000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x10000;FLASH_START=0x26000;FLASH_SIZE=0x5a000;RAM_START=0x200018a8;RAM_SIZE=0xe758" linker_section_placements_segments="FLASH RX 0x0 0x80000;RAM RWX 0x20000000 0x10000"

Sigurd · Answer

Looks like you are missing the NO_VTOR_CONFIG (This definition tells SES to expect a SoftDevice to be present that will forward exceptions and interrupts to the application.)

IAR to GCC porting issue with debugging the code

Top Replies