Turning on GCC optimizations prevents application from loading without debugger

RE: Turning on GCC optimizations prevents application from loading without debugger

senorwigglez — Thu, 14 Feb 2019 13:01:33 GMT

Well I was able to figure this out by finally get breakpoints to work within the bootloader while debugging. The program seemed to freeze in the nrf_drv_clock_uninit function during the bootloader's initialization in nrf_dfu_init. From here, I was able to find several users with the same problem and I guess SDK 14 doesn't support the WDT and buttonless DFU. I guess SDK 15 does but we don't want to transition to a new SDK after getting this one setup.

The workaround suggested is to comment out the nrf_drv_clock_uninit function which seems to be working so far. What a pain.

RE: Turning on GCC optimizations prevents application from loading without debugger

Nguyen Hoan Hoang — Wed, 13 Feb 2019 20:09:13 GMT

that's about it. you can use the LED or some print to UART if debug is a most. Alternatively, you use this Eclipse based DFU project for SDK15.2. You can put breakpoint anywhere. https://github.com/I-SYST/EHAL/tree/master/ARM/Nordic/nRF52/exemples/dfu

RE: Turning on GCC optimizations prevents application from loading without debugger

senorwigglez — Wed, 13 Feb 2019 09:52:32 GMT

I actually have debugging turned completely off in my main project and I only turned it on because I had no idea what was happening in the bootloader and I didn't know how to debug it outside of the RTT Client. In my original project, I have pretty much anything with "LOG" in it disabled and I removed the log initializations from my main program. Is there anything else I would need to change?

RE: Turning on GCC optimizations prevents application from loading without debugger

Nguyen Hoan Hoang — Wed, 13 Feb 2019 09:26:47 GMT

Try to disable RTT when not debugging. It is known to cause issues. GCC optimization is not the cause.

RE: Turning on GCC optimizations prevents application from loading without debugger

senorwigglez — Wed, 13 Feb 2019 08:25:43 GMT

Sure. What's the easiest way for me to send you the code?

RE: Turning on GCC optimizations prevents application from loading without debugger

Susheel Nuguru — Wed, 13 Feb 2019 08:07:05 GMT

is there any chance that you could help me reproduce this issue. I find it easy to narrow it down if I could reproduce it on my desk.

RE: Turning on GCC optimizations prevents application from loading without debugger

senorwigglez — Mon, 11 Feb 2019 09:10:15 GMT

You are right I evidently was reading false information concerning the flash location. I've left my program at 0x23000 and I'm still experiencing the same issue. Is there a way to step through the debugger like a normal program while debugging?

RE: Turning on GCC optimizations prevents application from loading without debugger

Susheel Nuguru — Mon, 11 Feb 2019 09:03:32 GMT

[quote user="senorwigglez"]According to the documentation I could find, the S132 softdevice should occupy 0x01000 - 0x20000.[/quote]

Which documentation says the above? Can you please redirect me to that info. I do not think that is correct. You should look into the sizes of the softdevice in its release document.

RE: Turning on GCC optimizations prevents application from loading without debugger

senorwigglez — Fri, 08 Feb 2019 12:56:35 GMT

I'm not sure either honestly. I received the following error without that flag:

../../../../../components/libraries/bootloader/nrf_bootloader_app_start_asm.c: In function 'nrf_bootloader_app_start_impl':
../../../../../components/libraries/bootloader/nrf_bootloader_app_start_asm.c:129:1: error: r7 cannot be used in asm here
 }

But that's neither here nor there at this point. I read that the memory locations for the bootloader needed to be modified slightly because the bootloader binary would be too big to fit in it's originally allocated memory space so I just arbitrarily made it bigger based on another post I saw. Here are the current memory configurations (that don't work):

Bootloader:

  FLASH (rx) : ORIGIN = 0x78000, LENGTH = 0x6000
  RAM (rwx) :  ORIGIN = 0x20002830, LENGTH = 0xd7d0
  
  bootloader_settings_page (r) : ORIGIN = 0x0007F000, LENGTH = 0x1000
  uicr_bootloader_start_address (r) : ORIGIN = 0x10001014, LENGTH = 0x4
  mbr_params_page (r) : ORIGIN = 0x0007E000, LENGTH = 0x1000
  uicr_mbr_params_page (r) : ORIGIN = 0x10001018, LENGTH = 0x4

Application:

  FLASH (rx) : ORIGIN = 0x23000, LENGTH = 0x55000
  RAM (rwx) : ORIGIN = 0x20004300, LENGTH = 0xBD00

The softdevice is S132. According to the documentation I could find, the S132 softdevice should occupy 0x01000 - 0x20000. This seems to contradict what the linker script sets for the secure ble bootloader example sets (0x23000 as shown above). I tried setting this back to 0x20000 but I get a merge conflict with mergehex so clearly they are overlapping.

RE: Turning on GCC optimizations prevents application from loading without debugger

Susheel Nuguru — Fri, 08 Feb 2019 10:56:31 GMT

Hi Andrew,

[quote user=""] needed to add -fomit-frame-pointer otherwise the linker[/quote]

I did not realize that a compiler will force you to set the omit-frame-pointer option. In my head, it was the other way around, that you can set it, but the compiler will still decide to use and not use frame pointer allocations for functions necessary. I am not able to understand why a linker will force you to set this.

FLASH (rx) : ORIGIN = 0x53000, LENGTH = 0x26000

So the problem is not with the set of instructions produced but the data fetched. So there is high chance that your earlier flash settings were in conflict with some other module using the flash address between 0x78000 and (0x78000+LENGTH).

If it was a code overlap due to two linker script conflicts (having memory segments too close to each other) then you should have seen problem when not using optimization, which would result in code size being a bit larger and possibly overflowing into next memory segment.

I would recommend to check all your memory segments in various linker scripts and also see if any part of your code has hardcoded memory address to the flash size in 0X78000 to 0x78000+LENGTH.

RE: Turning on GCC optimizations prevents application from loading without debugger

senorwigglez — Thu, 07 Feb 2019 12:35:53 GMT

I am combining the bootloader, the bootloader settings, the soft device, and the application into a single hex file and then programming that file.

nrfutil settings generate --family NRF52 --application $(OUT_FILE) --application-version 1 --bootloader-version 1 --bl-settings-version 1 ../bin/bootloader_settings.hex

I am generating the settings using the above command in a Makefile. The exact same commands are run for this whole process independent of the optimization level.

1. Program is compiled using make

2. Bootloader settings are generated

3. The four files named above are combined into one hex file using mergehex

4. Device flash is erased using nrfjprog --eraseall

5. Hex file is programmed and device is reset

RE: Turning on GCC optimizations prevents application from loading without debugger

Turbo J — Thu, 07 Feb 2019 10:21:21 GMT

[quote userid="67878" url="~/f/nordic-q-a/43437/turning-on-gcc-optimizations-prevents-application-from-loading-without-debugger"]Once I hit pause, I'm in a non-defined section of the program[/quote]

Nope, you are still in the bootloader. Note the rather high address, which is bigger than 0x78000.

Which explains yor problem: The NRF bootloaders calculate the checksum of the flashed program, and refuse to start it should that be different to the saved settings.

Workarounds:

Flash the app with the bootloader or
Flash the correctly calculated checksum into the bootloader settings page