20 replies to this topic

[scompo]

Hi, I've never noticed that the license for the examples of the stellaris launchpad were closed, they say explicitly that:

# Texas Instruments (TI) is supplying this software for use solely and
# exclusively on TI’s microcontroller products. The software is owned by
# TI and/or its suppliers, and is protected under applicable copyright
# laws. You may not combine this software with “viral” open-source
# software in order to form a larger program.

I wasn't very comfortable with this and I finally decided to write the needed linker script, startup file and the useful Makefile from scratch and license them with a BSD license.

You can find my impressions here and the code in this github repository.

Right now it doesn't support Stellarisware (It's basically the first working version) but I'm planning to add support for libraries in the Makefile as soon as I have time! I don't think it would be so difficult!

Of course the sofware it's opened, so: every help, suggestion, bug issue it's welcome!

I hope this would be useful in any way!

[bluehash]

Hi, I've never noticed that the license for the examples of the stellaris launchpad were closed, they say explicitly that:

# Texas Instruments (TI) is supplying this software for use solely and
# exclusively on TI’s microcontroller products. The software is owned by
# TI and/or its suppliers, and is protected under applicable copyright
# laws. You may not combine this software with “viral” open-source
# software in order to form a larger program.

I wasn't very comfortable with this and I finally decided to write the needed linker script, startup file and the useful Makefile from scratch and license them with a BSD license.

You can find my impressions here and the code in this github repository.

Right now it doesn't support Stellarisware (It's basically the first working version) but I'm planning to add support for libraries in the Makefile as soon as I have time! I don't think it would be so difficult!

Of course the sofware it's opened, so: every help, suggestion, bug issue it's welcome!

I hope this would be useful in any way!

Thanks scompo. You also got the OS badge.

[scompo]

Thanks scompo. You also got the OS badge.

Wow, thanks, a lot!

I cleaned up the makefile a little bit, fixed some warnings with the startup file and linker script and added support for stellarisware, just making the target in the directory tree.

https://github.com/s...ad-template-gcc

A lot of thanks to Wollw for his makefile wich is much cleaner than mine and helped me a lot.
And I forgot to say that to load a bin file to the stellaris launchpad I used lm4tools so thanks a lot to them too!

Also figured out a lot of changes to make it work better.

[doragasu]

I have been using your files for some test programs, and I think there must be an error in the startup code and/or linker script, because it fails when I use pre-initialized variables. The same programs with pre-initialized variables work perfect with TI files.

[scompo]

I have been using your files for some test programs, and I think there must be an error in the startup code and/or linker script, because it fails when I use pre-initialized variables. The same programs with pre-initialized variables work perfect with TI files.

Thanks for the catch. Yes, I've tried initializing a long before the main and it's not working. I'll look further into that and search for a solution.

[doragasu]

Thank's to you for your work. For me it's important to get rid of closed licenses in the stuff I develop in my spare time

I don't know where the problem exactly is, but to me it looks like .text section length is not properly set. Yesterday when I debugged the test program using TI files, text section end was at 0x2XXX. When I changed startup file and linker script to yours, text section end was at 0x09XX. It's strange there's a difference so big in code size, since the test program is the same, excepting little differences in startup code. Maybe a problem with the linker script?

[scompo]

Yes, I agree the problem should probably be in the LD script..
The strange thing it's that with the TimerIntRegister function the variable don't get initialized correctly. Instead using an interrupt assigned in the NVIC vector and just enabling it afterwards doesn't create any problem.
A quick&easy fix would be just declaring the global variable and initialize it inside the main or whenever it's needed instead of declaring and assigning at the same time (it would just get set to 0 in the .bss segment), so it would probably work fine.
The difference in the code size it's pretty strange too, as you said it should be pretty much the same. The only difference it's that I don't use any optimization and the TI makefile uses O2 (If I can recall correctly), maybe it depends on that, it's just really strange mine it's smaller. I'll try building the same program with the TI files and see what's different.
Btw I'm still investigating on the reason why the .data code doesn't get initialized right in some circumstances, any suggestion it's totally welcome

[doragasu]

I'm building the files myself (both your startup code and TI one), both without optimization (for debugging purposes), so there should be no code size difference because of optimization flags.

I need variable pre-initialization to work, because I'm trying to use DSPLib from CMSIS, and it uses pre-initialized variables. When I have some more time, I'll try debugging a bit more, but my problem is I don't know how to write linker script files

[scompo]

Thanks for the clarifications.
I understand, so there isn't a workaround as it is, sorry to hear that, it shouldn't behave as it is, it gives unexpected results.
I had no idea on how to write linker script too before writing this, I looked at the LD program manual and the sites mentioned here.
I'll dig more into this!

[scompo]

Quick update:
I've noticed that when the startup file start copying the value of the initialized variables to ram there's a problem, I guess that's what's causing the program size to be smaller too.
What I suppose it's happening it's that the linker script doesn't allocate enough space in flash to store the variables declared with the __attribute__ ((aligned(1024)) attribute in FLASH (the load address) for it but it does in RAM (reallocation address).
I'm still not sure if that's the reason (more likely to be) or vice-versa but I'll check it as soon as I can.
This causes the low level startup file to copy the data from FLASH to RAM with random values until the RAM_end_data address it's reached.
I could (probably I am) be wrong but I hope this is the case..

[scompo]

Quick update:
I've noticed that when the startup file start copying the value of the initialized variables to ram there's a problem, I guess that's what's causing the program size to be smaller too.
What I suppose it's happening it's that the linker script doesn't allocate enough space in flash to store the variables declared with the __attribute__ ((aligned(1024)) attribute in FLASH (the load address) for it but it does in RAM (reallocation address).
I'm still not sure if that's the reason (more likely to be) or vice-versa but I'll check it as soon as I can.
This causes the low level startup file to copy the data from FLASH to RAM with random values until the RAM_end_data address it's reached.
I could (probably I am) be wrong but I hope this is the case..

The issue wasn't really that, the linker script allocated memory correctly both in ram and flash, the problem was related to the alignment to a 1024 boundary but basically it was copying the .data initialized values from the end of text, with an aligned variable (vtable) the data was shifted because of that in memory so when it copied the values it just copied random stuff to the variables and the ram vector table (vtable). The solution I found was changing the order of the *(vtable) and *(.data.*) putting the .data before before the aligned ram vector.
I don't know if this would solve your problem, but I think your issue could be a similar alignment issue on the DSPLib you mentioned, do you have any code available for me to take a look at doragasu?

[doragasu]

I tried using your patched linker script, but unfortunately that didn't help .

 

I'm trying to build arm-fir-example, included in the CMSIS library. I have only added two lines to set up the system clock. I can upload the files I'm using, including Eclipse project if it helps, but assuming your paths aren't the same as mine, you'll have to do some modifications, and you'll have also to set up CMSIS library. This example uses a big amount of initialized data (input and output reference signals, filter coefficients, etc.).

[scompo]

I've downloaded that and take a look at it and I've never used that before.

It looks like in the cmsis/Device/ARM/ARMCM4/Source/GCC there are a linker script and a startup assembly file that should be ok to link in it I guess.

the ld script uses ARM.edix and extab sections, other than libc specific sections.

On github there's a test-newlib branch where mark roy has done a lot of work on integrating that into it, I'm still testing that out, but it's working somehow. You can find it here (the branch) and here (mroy's fork).

[doragasu]

I tried building the project using mroy's fork, but got a lot of unresolved externals from libc:

 

arm-none-eabi-ld -L/home/jalon/src/stellaris/stellarisware/driverlib/gcc-cm4f -L/home/jalon/sat/lib/gcc/arm-none-eabi/4.6.2 -L/home/jalon/sat/arm-none-eabi/lib -L/home/jalon/src/stellaris/cmsis/CMSIS/Lib --static --gc-sections -T../LM4F.ld -o "arm-fir-example.elf"  ./LM4F_startup.o ./arm_fir_data.o ./arm_fir_example_f32.o ./arm_fir_f32.o ./arm_fir_init_f32.o ./math_helper.o   -ldriver-cm4f -ldsplib-lm4f -lm -lgcc -lc
</p><div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-dtoa.o): In function `quorem':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/stdlib/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/stdlib/dtoa.c:60: undefined reference to `__aeabi_uidiv'</div>
<div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/reent/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/reent/sbrkr.c:60: undefined reference to `_sbrk'</div>
<div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-writer.o): In function `_write_r':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/reent/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/reent/writer.c:58: undefined reference to `_write'</div>
<div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-closer.o): In function `_close_r':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/reent/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/reent/closer.c:53: undefined reference to `_close'</div>
<div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-fstatr.o): In function `_fstat_r':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/reent/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/reent/fstatr.c:62: undefined reference to `_fstat'</div>
<div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-isattyr.o): In function `_isatty_r':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/reent/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/reent/isattyr.c:58: undefined reference to `_isatty'</div>
<div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-lseekr.o): In function `_lseek_r':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/reent/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/reent/lseekr.c:58: undefined reference to `_lseek'</div>
<div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-readr.o): In function `_read_r':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/reent/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/reent/readr.c:58: undefined reference to `_read'</div>
<div>make: *** [arm-fir-example.elf] Error 1

[scompo]

 

I tried building the project using mroy's fork, but got a lot of unresolved externals from libc:

 

 

arm-none-eabi-ld -L/home/jalon/src/stellaris/stellarisware/driverlib/gcc-cm4f -L/home/jalon/sat/lib/gcc/arm-none-eabi/4.6.2 -L/home/jalon/sat/arm-none-eabi/lib -L/home/jalon/src/stellaris/cmsis/CMSIS/Lib --static --gc-sections -T../LM4F.ld -o "arm-fir-example.elf"  ./LM4F_startup.o ./arm_fir_data.o ./arm_fir_example_f32.o ./arm_fir_f32.o ./arm_fir_init_f32.o ./math_helper.o   -ldriver-cm4f -ldsplib-lm4f -lm -lgcc -lc
</p><div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-dtoa.o): In function `quorem':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/stdlib/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/stdlib/dtoa.c:60: undefined reference to `__aeabi_uidiv'</div>
<div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/reent/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/reent/sbrkr.c:60: undefined reference to `_sbrk'</div>
<div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-writer.o): In function `_write_r':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/reent/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/reent/writer.c:58: undefined reference to `_write'</div>
<div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-closer.o): In function `_close_r':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/reent/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/reent/closer.c:53: undefined reference to `_close'</div>
<div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-fstatr.o): In function `_fstat_r':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/reent/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/reent/fstatr.c:62: undefined reference to `_fstat'</div>
<div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-isattyr.o): In function `_isatty_r':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/reent/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/reent/isattyr.c:58: undefined reference to `_isatty'</div>
<div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-lseekr.o): In function `_lseek_r':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/reent/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/reent/lseekr.c:58: undefined reference to `_lseek'</div>
<div>/home/jalon/sat/arm-none-eabi/lib/libc.a(lib_a-readr.o): In function `_read_r':</div>
<div>/home/jalon/src/stellaris/summon-arm-toolchain/build/arm-none-eabi/newlib/libc/reent/../../../../../gcc-linaro-4.6-2011.10/newlib/libc/reent/readr.c:58: undefined reference to `_read'</div>
<div>make: *** [arm-fir-example.elf] Error 1

 

Does this need a different compiler?

 

I have also browsed the startup code inside CMSIS, and it looks like it's missing a lot of interrupt vectors...

 

If I can recall correctly I think he's using the toolchain available here: https://launchpad.ne...c-arm-embedded, I switched to that too, but I haven't tried building that.

I've forked the work of mrnuke on the libopencm3 library, we're both implementing basic LM4F120xl support in it. It's still very basic.

It looks promising, but still under development.

[doragasu]

Thanks for the info!

 

I have also played a bit with the assembly startup code included in CMSIS. It builds, but instead of calling main() when it finishes startup, it calls start(). Maybe I'm missing something, because CMSIS examples use the standard main() function as C entry point.

[dellwoodbu]

I think TI is listening...

 

 

http://e2e.ti.com/su...1/t/230468.aspx

 

Also the Energia folks appear to have worked with TI to resolve some of the other issues...

 

https://github.com/e...f/startup_gcc.c

 

The linker script energia is using is their own. But may be helpful https://github.com/e...lm4f/lm4fcpp.ld

 

Finally since you mentioned the FIR examples in CMSIS i infer you are wanting the DSP libraries?  Check this app note which is CCS specific but may help some, Also EuphonisTI uses the DSP Library for his stuff.  http://hackaday.com/...aris-launchpad/

[Rickta59]

If you are tracking the Energia stellarpad development, you might want to switch to the master tree. Robert merged the stellarpad branch into master. No more commits will be done on the stellarpad branch.

lm4fcpp.ld


-rick

[doragasu]

Thanks for the info!

 

It's good to know TI is going to correct the license terms for the Makefiles. I hope they also do so for the startup code and the linker script!

 

I'll try the code from Energia ASAP, but I'm very busy lately. Real life can be extremely time consuming

[doragasu]

I had some time to play with this again. The Energia files use startup_gcc.c file from TI, so it still has the license problems, right?

 

I have been trying to debug scompo's files, and I think the problem is in the linker script. I suspect the initialization is wrong. I have done some modifications to it, and browsed the labels involved in variable initialization in the generated .map file. This is what I found:

 

1.- If I leave the linker script as is (have a look to _end_text, _start_data and _end_data labels): http://pastebin.com/T6MuCaEi

    Then the generated .map file allocates _end_text in the .rodata section, and I suppose this is wrong. Also _end_data is allocated in the .vtable section, and I suppose this is also wrong (but I'm not sure on this): http://pastebin.com/gT70MYxs

 

2.- If I modify the _end_text and _end_data labels like this: http://pastebin.com/Uq6QMcAe

    Then to me it looks like _end_data is properly placed, at the end of the .data section, just where .bss starts. But something strange happens with _end_text. I expected it to be at the same location .rodata section is, but it's not, it's in the middle of the .rodata section: http://pastebin.com/sZRt7Ycz

 

Can this be the problem? How can I fix it?