Re: [libopenstm32-devel] stm32f103 and USB
Status: Inactive
Brought to you by:
uh1763
From: Bernard D. <be...@go...> - 2011-02-16 00:02:10
|
Another thing to note when working with the tool chain / gcc is that when you compile you need to make sure that the linker is including the correct multilibs. To find the options that you need do the following. arm-none-eabi-gcc -print-multi-lib This will print something like: .;@msoft-float thumb;@mthumb@msoft-float thumb/v7;@mthumb@march=armv7@msoft-float armv4t;@mthumb@march=armv4t@msoft-float thumb2;@mthumb@march=armv7@mfix-cortex-m3-ldrd@msoft-float If we want / need to include the thumb2 versions of the multilibs then we must specify every option for that library set. i.e. -mthumb -march=arm7 -mfix-cortex-m3-ldrd -msoft-float Note that what you have will be different from the above and will need adjusting accordingly. The alternative to this is to build gcc so that it only supports the target architecture. (This is NOT what the summon-arm-toolchain currently does) Please let me know if you have any questions. Cheers, Bernie. On 16/02/2011, at 7:33 AM, Gareth McMullin wrote: > On Wed, Feb 16, 2011 at 8:38 AM, Gareth McMullin > <ga...@bl...> wrote: >> Ok, there seems to be a lurking bug in the USB code. You aren't the >> first person to have this problem. I unfortunately can't reproduce the >> problem with either of the two hosts I have available. > > I've found the problem: just tried building with summon-arm-toolchain, > and I observe the same problem. The build_config_descriptor() function > uses memcpy() to contruct the configuration descriptor, on entry to memcpy > an invalid instruction is encountered and the target is found in > blocking_handler(). > No further USB requests are handled. > > It seems that summon-arm-toolchain is linking in an ARM mode memcpy > instead of thumb. This can be solved by adding -mthumb to the linker > options. > > I've attached a patch to the generic makefile, which just added the full CFLAGS > to the linker command line. It solved the problem and should be safe. > I've also removed the "-Wl,--gc-sections", and changed options to "-O0 -g3". > The options in git make the examples very hard to debug, and I think this > may create a barrier to newbies trying out the library. Especially > for an example, > we can give up some size to make things easier. > > Regards, > Gareth > > -- > Black Sphere Technologies Ltd. > > Web: www.blacksphere.co.nz > Mobile: +64 27 777 2182 > Tel: +64 9 478 8885 > Skype: gareth.mcmullin > LinkedIn: http://nz.linkedin.com/in/gsmcmullin > <sat-patch>------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb_______________________________________________ > libopenstm32-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libopenstm32-devel |