Hex file does not match with Segger and GCC. GCC produced hex does not work.

[Daniel]

Hi,

I want to set up visual code studio for development. I was able to successfully run the blinky app on PCA10040 board and also emulated PCA10040e example. 

After this, I removed the "DEVELOP_IN_NRF52832" flag from makefile and also removed the define from the configuration but I am not able to see the device advertisement.

I flashed both softdevice and application using nrfstudio programmer but no success. 

[awneil]

So you're developing for an nRF52810 target?

Have you seen this: https://devzone.nordicsemi.com/f/nordic-q-a/33812/developing-for-nrf52810---the-full-story

What debugging have you done to find what's going wrong?

[Daniel]

Yes I am developing for nrf52810. I used the PCA10040e project, to begin with. So I don't think I need to change the settings. 

These are the defines I have 

"APP_TIMER_V2",

                "APP_TIMER_V2_RTC1_ENABLED",

                "BOARD_PCA10040",

                "CONFIG_GPIO_AS_PINRESET",

                "FLOAT_ABI_SOFT",

                "INITIALIZE_USER_SECTIONS",

                "NO_VTOR_CONFIG",

                "NRF52810_XXAA",

                "NRF52_PAN_74",

                "NRF_SD_BLE_API_VERSION=7",

                "S112",

                "SOFTDEVICE_PRESENT",

                "NRFX_COREDEP_DELAY_US_LOOP_CYCLES=3"

                "DEVELOP_IN_NRF52832"

 

I did the following exercises.

1) Compiled PCA10040e blinky app in segger. Worked fine on dev board(PCA10040). 

2) Compiled the same using armgcc makefile for PCA10040e. It worked fine on the dev board(PCA10040). 

3) Compiled the same blinky app in segger for nRF52810 by removing the "DEVELOP_IN_NRF52832" preprocessor. It worked fine on my custom nrf52810 board. 

4) Complied the same blinky app using armgcc by removing  CFLAGS += -DDEVELOP_IN_NRF52832 from make file.

It did not work. 

I did not compare the hex file until step4. I am not sure if steps 1 and 2 generate the same hex files.

[Håkon Alseth]

Hi,

Could you try adding -DDEBUG to the preprocessor symbols to see if you can get a more detailed assert (or that is whats happening), and if a fault occurs; post the call stack?

 

Kind regards,

Håkon

[Daniel]

/* Dummy Exception Handlers (infinite loops which can be modified) */

.weak NMI_Handler
.type NMI_Handler, %function
NMI_Handler:
b .
.size NMI_Handler, . - NMI_Handler


.weak HardFault_Handler
.type HardFault_Handler, %function
HardFault_Handler:
b .
.size HardFault_Handler, . - HardFault_Handler

It does not even go to main.

It halts at Hardfault handler.

[awneil]

[Daniel]

Attached the snap of the code.

[Håkon Alseth]

Hi,

 

Daniel said:

It halts at Hardfault handler.

But, where did it occur? There's a call stack if you enter debug mode and look at the stack trace. If this happens at SystemInit, I would recommend that you look at the cpu registers, especially the SP to see if it is out-of-bounds. Check your linker script, to see if the RAM region exceeds 0x20006000.

 

Kind regards,

Håkon