Thread: [libopenstm32-devel] stm32f103 and USB
Status: Inactive
Brought to you by:
uh1763
Menu
▾
▴
libopenstm32-devel
|
From: gwenhael.goavec <gwe...@fe...> - 2011-02-15 13:01:50
|
Hi, I have a custom board based on STM32F103 microcontroller. My toolchain is created thanks to summon-arm-toolchain script. I work with linux. I wish to use the usb device. In a first time, I have used examples shipped with library. With cdcacm or usbhid (maybe with others too), I have errors when I plug the usb cable. dmesg exemple for usb_hid.elf: [167604.696192] usb 3-1: new full speed USB device using uhci_hcd and address 21 [167609.843315] usb 3-1: unable to read config index 0 descriptor/start: -110 [167609.843326] usb 3-1: chopping to 0 config(s) [167614.845496] usb 3-1: string descriptor 0 read error: -71 [167614.845519] usb 3-1: New USB device found, idVendor=0483, idProduct=5710 [167614.845531] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [167614.845879] usb 3-1: no configuration chosen from 0 choices . lsusb shows the good informations about VendorId and ProductId. On a other side lsusb -v show bNumConfigurations : 0 Bus 003 Device 012: ID 0483:5710 SGS Thomson Microelectronics Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0483 SGS Thomson Microelectronics idProduct 0x5710 bcdDevice 2.00 iManufacturer 1 iProduct 2 iSerial 3 bNumConfigurations 0 To test if problem is relative to my board or an other problem, I have used prebuild usbmouse demo available on olimex's website. With this example, I have the good result. I have no idea of reasons of this problem, maybe my arm-none-eabi-gcc-4.5.1 If someone has an idea to correct this issue. Thank you very much. |
|
From: Gareth M. <ga...@bl...> - 2011-02-15 19:38:50
|
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. If you can take a capture of the usb activity with Wireshark, I'll have a look at it to see what I can find. Regards, Gareth On Wed, Feb 16, 2011 at 1:31 AM, gwenhael.goavec <gwe...@fe...> wrote: > Hi, > > I have a custom board based on STM32F103 microcontroller. > My toolchain is created thanks to summon-arm-toolchain script. > I work with linux. > > I wish to use the usb device. In a first time, I have used > examples shipped with library. > > With cdcacm or usbhid (maybe with others too), I have errors when I plug the usb > cable. > dmesg exemple for usb_hid.elf: > > [167604.696192] usb 3-1: new full speed USB device using uhci_hcd and address 21 > [167609.843315] usb 3-1: unable to read config index 0 descriptor/start: -110 > [167609.843326] usb 3-1: chopping to 0 config(s) > [167614.845496] usb 3-1: string descriptor 0 read error: -71 > [167614.845519] usb 3-1: New USB device found, idVendor=0483, idProduct=5710 > [167614.845531] usb 3-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 [167614.845879] usb 3-1: no configuration chosen from 0 choices > . > lsusb shows the good informations about VendorId and ProductId. > On a other side lsusb -v show bNumConfigurations : 0 > > Bus 003 Device 012: ID 0483:5710 SGS Thomson Microelectronics > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x0483 SGS Thomson Microelectronics > idProduct 0x5710 > bcdDevice 2.00 > iManufacturer 1 > iProduct 2 > iSerial 3 > bNumConfigurations 0 > > To test if problem is relative to my board or an other problem, I have used > prebuild usbmouse demo available on olimex's website. With this example, I have > the good result. > > I have no idea of reasons of this problem, maybe my arm-none-eabi-gcc-4.5.1 > If someone has an idea to correct this issue. > > Thank you very much. > > ------------------------------------------------------------------------------ > 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 > -- 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 |
|
From: Gareth M. <ga...@bl...> - 2011-02-15 21:03:16
Attachments:
sat-patch
|
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 |
|
From: gwenhael.goavec <gwe...@fe...> - 2011-02-17 13:37:32
|
On Wed, 16 Feb 2011 09:33:54 +1300 Gareth McMullin <ga...@bl...> 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 > Hi, I have just tested after having applied the patch. This ok! Thank you ! Regards, Gwenhaël |
|
From: Bernard D. <be...@go...> - 2011-02-16 00:02:10
Attachments:
smime.p7s
|
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 |
|
From: Piotr Esden-T. <pi...@es...> - 2011-02-17 19:03:43
Attachments:
PGP.sig
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X