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.

[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

[Daniel]

it fails right after reset at reset handler.

Reset_Handler:

    /* Workaround for Errata 185 RAM: RAM corruption at extreme corners 
     * found at the Errata document for your device located
     * at https://infocenter.nordicsemi.com/index.jsp */
    
    LDR     R0, =0x10000130
    LDR     R0, [R0]

It does not reach LDR R0,[R0]

Debug window log: 

Resetting target

Program
received signal SIGTRAP, Trace/breakpoint trap.
HardFault_Handler () at ../../modules/nrfx/mdk/gcc_startup_nrf52810.S:323
323 b .

[Daniel]

Looks like there is nothing at LDR     R0, =0x10000130.

So it is crashing. But this is all gcc generated file. Why it would fail. Do i need to do any settings in the makefile? 

[Håkon Alseth]

Hi,

 

Daniel said:

Looks like there is nothing at LDR     R0, =0x10000130.

So it is crashing. But this is all gcc generated file. Why it would fail. Do i need to do any settings in the makefile? 

 That is reading a specific address in the FICR space and performing an if on the value. Are you 100 % certain that this is where is faults?

Could you please post your code, makefile etc, and the debug info wrt. the readout CPU registers? You can read the CPU registers using "mon regs" in gdb, if you're using that.

 

Kind regards,

Håkon