fixes to NRF51822 GCC template #435
Conversation
|
Doesn't work with the USB-MSD code loader (but that's likely an unrelated issue already reported regarding compatibility between Nordic's intelhex loader and gcc's intelhex output). |
|
What are the steps that you're using to compile this? I tried checking out your branch and building the blinky test (test 25) using make.py, and it doesn't work. It looks like you're using an export rather than a standard test. Did you export and then change the Makefile to point into the git area? |
|
@webbbn Indeed I was using the export_test.py script, modified to just export the blinky example rather than the RTOS one. I looked into the make.py script and it was encountering the same linker issue (with --gc-sections). I looked into that a bit more and ended up comparing the NRF51822 linker script with the STM32 one... turns out the NRF51822.ld was missing "KEEP()" around some sections that the linker was discarding, so fixing the linker script is the correct fix for this issue. |
| @@ -23,7 +23,7 @@ CPU = -mcpu=cortex-m0 -mthumb | |||
| CC_FLAGS = $(CPU) -c -g -fno-common -fmessage-length=0 -Wall -fno-exceptions -ffunction-sections -fdata-sections | |||
| CC_SYMBOLS = {% for s in symbols %}-D{{s}} {% endfor %} | |||
|
|
|||
| LD_FLAGS = -mcpu=cortex-m0 -mthumb -Wl,--gc-sections --specs=nano.specs -u _printf_float -u _scanf_float | |||
There was a problem hiding this comment.
We really want to keep --gc-sections, this is how we keep the code size under control. If you find that you're getting useful sections removed, KEEP them explicitly in .ld rather than removing this argument.
There was a problem hiding this comment.
Yes indeed, my latest patch does that (took me a while to understand the linker script issues).
There was a problem hiding this comment.
Ah sorry, I hadn't pushed that patch yet.
Merge remote-tracking branch 'upstream/master'
|
How are you flashing the hex file? I'm trying to figure out a way to flash it under Linux. When I try to flash the combined.hex with openocd using an STLink adapter I get "Error: failed erasing sectors 0 to 204". I can erase flash with a JLink adapter and JLinkExe, but that doesn't seem to support hex format. I can't get openocd to work with the JLink adapter... |
fixes to NRF51822 GCC template
|
@webbbn Have a look in this Makefile example for how to do it with JLink: https://github.com/hlnd/nrf51-pure-gcc-setup/blob/master/template/Makefile.posix A similar approach should work with openocd though the commands for writing to memory (for removing the write protection: "w4 4001e504 1") would be different, I think it's "mww 0x4001e504 1" but haven't tried yet. So far I've just used gdb and "load" as I've been debugging. |
|
Thanks for the pointers. It was a bit arduous, but I was able to pull apart that Makefile and make a couple of JLinkExe scripts to flash the softdevice and then the program, and I'm now getting a flashing LED (at least on a PCA10000)! |
* add basic target files and cmakelists * added copyright header * fix emac test and add define for usb test * add JLink upload method * resolve rebase merge conflict * fix rebase conflict * fix upload JLink * Implement 120MHz clocking * Fix #if * Fix common tickers test * License fixes * Pin name fixes, add EEPROM component * Few more tweaks --------- Co-authored-by: Jamie Smith <jsmith@crackofdawn.onmicrosoft.com>
I have been experimenting with getting mbed projects compiled & linked with GCC. This fix allows me to compile & link the blinky example (exported with "export_test.py" from worspace_tools), and execute it successfully (so far tested using JLinkGDBserver, I'll try pyOCD next).
--wrap=main is required as common/retarget.cpp needs to wrap main. With --gc-sections I seem to get some needed sections dropped by LD (and the code doesn't run correctly) so I took it out for now. (-Map=out.Map can be used to see what the linker is doing).