[mbed] fixes to NRF51822 GCC template (#435)
janekm
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).
You can merge this Pull Request by running
git pull https://github.com/janekm/mbed master
Or view, comment on, or merge it at:
https://github.com/mbedmicro/mbed/pull/435
Commit Summary
- fixes to NRF51822 GCC template
File Changes
Patch Links:
—
Reply to this email directly or view it on GitHub.
janekm
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).
webbbn
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?
janekm
@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.
Bogdan Marinescu
In workspace_tools/export/gcc_arm_nrf51822.tmpl:
> @@ -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
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.
janekm
In workspace_tools/export/gcc_arm_nrf51822.tmpl:
> @@ -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
Yes indeed, my latest patch does that (took me a while to understand the linker script issues).
janekm
In workspace_tools/export/gcc_arm_nrf51822.tmpl:
> @@ -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
Ah sorry, I hadn't pushed that patch yet.
webbbn
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...
Bogdan Marinescu
Merged #435.
janekm
@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.
webbbn
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)!