bluehash 1,581 Posted November 28, 2012 Share Posted November 28, 2012 Try increasing your stack a little. Quote Link to post Share on other sites
doragasu 0 Posted November 29, 2012 Author Share Posted November 29, 2012 I don't think that's the problem, but sure it's worth a try. Thanks for the suggestion, I'll try it ASAP. This is what the datasheet says about hard faults: Hard Fault. A hard fault is an exception that occurs because of an error during exceptionprocessing, or because an exception cannot be managed by any other exception mechanism. Hard faults have a fixed priority of -1, meaning they have higher priority than any exception with configurable priority. No other exception is triggered before the hard fault (I have an empty handler with a while(1); to catch all unused exceptions), and memset is not called while processing other exception, so for me it doesn't make sense that a hard fault exception is raised. Reading a bit more, chapter 2.6.1 states that a hard fault can be caused also by a "Bus error on a vector read". I don't really know what that means exactly ¿?. I'll also have to try reading HFAULTSTAT register to see if it sheds some light... Quote Link to post Share on other sites
scompo 0 Posted December 2, 2012 Share Posted December 2, 2012 I don't know if you already saw this but here this guy used CMSIS dsp library to build an audio analyzer. The code it's available here. Maybe you'll find this useful. Quote Link to post Share on other sites
doragasu 0 Posted December 2, 2012 Author Share Posted December 2, 2012 I already saw that, but that project is built using CCS. Building CMSIS with CCS is an entirely different process, but thanks for the tip anyway! Quote Link to post Share on other sites
jimk3038 1 Posted January 2, 2013 Share Posted January 2, 2013 Was any solution ever found for this problem? I hit the same issue while trying to get FreRTOS up and running. Everything works great until memset is called - which seem to generate a hard fault. Even TI's stock example "/stellarisware/boards/ek-lm4f120xl/freertos_demo/gcc/freertos_demo.bin" locks up. Quote Link to post Share on other sites
doragasu 0 Posted January 14, 2013 Author Share Posted January 14, 2013 Unfortunately, I couldn't find a way to solve this problem, and I've been extremely busy with other stuff If anybody knows how to fix this, please tell us how. Quote Link to post Share on other sites
doragasu 0 Posted January 14, 2013 Author Share Posted January 14, 2013 @jimk3038, to build FreeRTOS, are you using startup code and linker scripts made by Scompo? I suspect there's something wrong with the linker script that might be causing problems with the initialization of the libraries. I'm discussing this problem in this thread: http://forum.stellarisiti.com/topic/327-stellaris-launchpad-gcc-makefile-startup-file-and-linker-script-bsd/?p=2162 Quote Link to post Share on other sites
doragasu 0 Posted January 15, 2013 Author Share Posted January 15, 2013 I have solved the main problem with the library . Using TI startup code and linker script, now I'm able to build CMSIS with GCC, and use it. I have tested arm_fir_example, and works perfect! The problem is I was linking with the ARM libgcc library, instead of the Thumb one. To jump to the memset function, gcc was using a BLX instruction instead of a BL one, and BLX instruction isn't supported by cortex CPU's because they only support Thumb instructions. When the CPU tried to execute the BLX instruction, the HardFault exception was raised. TI Should document that HardFault exception is also raised when an invalid instruction is found. I searched thoroughly the docs, and didn't find it. Would have saved me a lot of time . I have solved the problem using gcc instead of ld to link. Passing gcc the switches -mthumb -mcpu=cortex-m4, makes it automatically select the right libraries, and uses BL instead of BLX to jump. I still have to figure out why building with Scompo's startup code doesn't work, but at least, everything works perfect with TI files. bluehash 1 Quote Link to post Share on other sites
bluehash 1,581 Posted January 15, 2013 Share Posted January 15, 2013 Thanks for the indepth explanation. Quote Link to post Share on other sites
doragasu 0 Posted January 27, 2013 Author Share Posted January 27, 2013 Fixed the problems I had building with Scompo's files. Now I have a working GCC library, 100% built with FOSS utils and code . For more details about the startup code fixes, read here. If you are using Sompo's startup files, be warned you'll also have to enable the FPU in your code, because Scompo's code doesn't do it. Quote Link to post Share on other sites
doragasu 0 Posted January 27, 2013 Author Share Posted January 27, 2013 As promised, I wrote a tutorial on building CMSIS DSPLib with GCC, and using it with Eclipse. I hope someone finds it useful bluehash 1 Quote Link to post Share on other sites
ronszon1426459902 0 Posted February 9, 2013 Share Posted February 9, 2013 Hi, I fell in the same memset/blx hole as you I believe... I am trying to build the simpliciti stack for stellaris launchpad using gcc, but calls to memset use blx instruction what then causes hard failure of the program. However, I use only TI files for the moment. Also, I made sure (I think) I put -mthumb and -mcpu=cortex-m4 in the Makefile, so it should work according to your post. Any clue what alse could have gone wrong? I am no compilation expert, could you say in which way I could check which libraries were compiled in? Thanks! Quote Link to post Share on other sites
ronszon1426459902 0 Posted February 10, 2013 Share Posted February 10, 2013 Hi, Ufff, after a bit of debugging (and learning about gcc, that is never lost time ) I noticed that when I build with "-mfloat-abi=softfp" I get the default libgcc.a as doragasu earlier explained (memset gets compiled to blx instruction -> that gives a hard fault). Strangely, it seems that it was the summon-arm-toolchain that did not compile 'softfp' version. Is that possible? I don't have previous experience with arm toolchains... Any idea how I could force 'sat' to compile for 'softfp'? Either way, using 'hard' as '-mfloat-abi' does work! bluehash 1 Quote Link to post Share on other sites
doragasu 0 Posted February 11, 2013 Author Share Posted February 11, 2013 The problem I had was not in the compilation steps, it was in the linking stage. What flags are you calling the linker with? Also are you linking with gcc or with ld? Quote Link to post Share on other sites
ronszon1426459902 0 Posted February 13, 2013 Share Posted February 13, 2013 I link with arm-none-eabi-ld, but the problem was that LIBGCC=${shell ${CC} ${CFLAGS} -print-libgcc-file-name} where CFLAGS= -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp results in ~/sat/lib/gcc/arm-none-eabi/4.7.2/libgcc.a which is wrong. Putting -mfloat-abi=hard gives " ~/sat/lib/gcc/arm-none-eabi/4.7.2/thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16/libgcc.a so that the correct library is linked. So it is precisely the same problem you had, however for some reason the "softfp" lib is not installed... Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.