Re: [libopenstm32-devel] stm32f103 and USB

[Piotr Esden-T. <pi...@es...>]

Hi everyone,

On Feb 15, 2011, at 3:32 PM, Bernard Davison wrote:

> 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

Just as a heads up. I added multilib support to SAT (https://github.com/esden/summon-arm-toolchain) now it should generate all the libraries with the correct parameters.

> 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.

I tested a little bit and the flags necessary to build the right assembler and link with the correct multilib are the following:
CFLAGS=-mcpu=cortex-m3 -mthumb -msoft-float
LDFLAGS=-mthumb -march=armv7 -mfix-cortex-m3-ldrd -msoft-float

> 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)
You should be able to generate just that by passing DEFAULT_TO_CORTEX_M3=1 to the SAT script. Please tell me if the parameters passed in there are not correct for someone.

> Please let me know if you have any questions.
Thank you for your and Eric Parsonage work on that. The changes in SAT are based on your work. I hope that solves the problems for most people if not everyone. :) 
> 
> 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

Cheers Esden

--
Blog: http://www.esden.net
Projects:
http://open-bldc.org
http://paparazziuav.org
http://github.org/esden/floss-jtag
http://github.org/esden/summon-arm-toolchain