STM32f4 discovery USB device example

[Ed Sutter]

Posted on August 26, 2013 at 22:45

Hi, I'm trying to run the ''USB Device VCP example'' using the gcc (sourcery-lite) tools.  I can build it and it appears to be running (led is blinking and the message ''USB device library started'' comes out the UART; but then I get ''Unknown Device'' on the USB side when I plug it into a PC.  

Has anyone built any of the USB device demos with GCC? #usb

[Tesla DeLorean]

Posted on August 26, 2013 at 22:54

Has anyone built any of the USB device demos with GCC?

Yes, both VCP and MSC. The VCP enumerates in a somewhat squirrely fashion whether GNC/GCC or Keil is used.

[Ed Sutter]

Posted on August 26, 2013 at 23:29

That's good to hear.  I must have something screwed up with my translation from the project files used under MDK-ARM (I assume this is Keil) and my makefile with gcc.  Didn't look like anything too tricky, but I've yet to get it running, so apparently I'm missing something...

I have the Discovery board mounted on the STF4BB base board so I've got USART6 connected to my PC along with the USB cable for VCOM on the other end.  I steer the printf output of the application to that USART, and at startup I see the message ''USB device library started'', and then the LED just keeps blinking, so it appears that all is sane.I updated the system_stm32f4xx.c file to match the board (clock/pll/etc...) and other than that I just use   -mcpu=cortex-m4 -mthumb-D USE_STDPERIPH_DRIVER -D STM32F4XX -D USE_USB_OTG_FS to complile each file, then link it. Are there any other mods that need to be made to this for a GCC build?  Hey, better yet, is there a makefile out there somewhere that I could just shamelessly steal for this?UPDATE: actually, the above isn't quite true... if I use just ''-D USE_USB_OTG_FS'' the LED does not blink; if i build with -D USE_USB_OTG_HS  -D USE_ULPI_PHY then the LED blinks continuously.

[Tesla DeLorean]

Posted on August 27, 2013 at 02:01

https://docs.google.com/file/d/0B7OY5pub_GfIdnREeExyRWNXbFE/edit?usp=sharing

[Ed Sutter]

Posted on August 28, 2013 at 15:21

Sorry for the late reply (was out of office yesterday).  Thanks much,  I'll try this today.

Meanwhile, I noticed quickly that this code is quite different than the code that comes with examples .zip file as supplied by Element14 where I purchased the board-set.  Is there a more up-to-date version of that set of examples?

[Tesla DeLorean]

Posted on August 28, 2013 at 15:35

Is there a more up-to-date version of that set of examples?

I guess that would be something you need to discuss with Element 14, I'm not responsible for their code, or ST's for that matter. I built my code using the most current/appropriate firmware at the time I put it together. You could download ST's from the site here, and then merge/diff to see what changed.

[Ed Sutter]

Posted on August 28, 2013 at 19:08

Ok, I was able to build and run your source, thanks much.

I added support for USART6 which is the default (jumperable) tied to the DB9 connector of the DMSTF4BB expansion board.  One thing I noticed (regardless of whether I use USART2 or USART6), I only see data characters from VCP to USART, but not USART to VCP.  Is that expected?BTW, if you want the USART6 change let me know.  It uses USART2 by default but -D USE_USART6 makes the change.

[Tesla DeLorean]

Posted on August 28, 2013 at 20:14

As I recall it should go both ways. Check Pin configurations, IRQ Handler, NVIC settings, etc.

What pins is USART6 on with this board?

[Ed Sutter]

Posted on August 29, 2013 at 17:06

Ok, I managed to get bidirectional data working, but I don't quite understand the problem.

Maybe you can shed some light on this...I managed to narrow the problem down (it never ceases to amaze me just how much debugging you can do with a few leds!) to determine that the variable 'APP_Rx_ptr_in' was not being initialized to zero.  Looking at the memory map with objdump I saw some very odd entries...

out/demo.elf:     file format elf32-littlearm

architecture: arm, flags 0x00000112:EXEC_P, HAS_SYMS, D_PAGEDstart address 0x08000188Sections:Idx Name          Size      VMA       LMA       File off  Algn  0 .isr_vector   00000188  08000000  08000000  00008000  2**0                  CONTENTS, ALLOC, LOAD, READONLY, DATA  1 .text         00002410  08000188  08000188  00008188  2**2                  CONTENTS, ALLOC, LOAD, READONLY, CODE  2 .data         0000013c  20000000  08002598  00010000  2**2                  CONTENTS, ALLOC, LOAD, DATA  3 .bss          00000f94  2000013c  080026d4  0001013c  2**2                  ALLOC  4 .bss.cfgidx.8217 00000001  200010d0  08003668  0001013c  2**0                  ALLOC  5 .bss.USBD_cfg_status 00000004  200010d4  0800366c  0001013c  2**2                  ALLOC  6 .bss.USBD_ep_status 00000004  200010d8  08003670  0001013c  2**2                  ALLOC  7 .bss.USBD_default_cfg 00000004  200010dc  08003674  0001013c  2**2                  ALLOC  8 .bss.usbd_cdc_AltSet 00000004  200010e0  08003678  0001013c  2**2                  ALLOC  9 .bss.USB_Tx_State 00000001  200010e4  0800367c  0001013c  2**0                  ALLOC 10 .bss.cdcLen   00000004  200010e8  08003680  0001013c  2**2                  ALLOC 11 .bss.APP_Rx_ptr_in 00000004  200010ec  08003684  0001013c  2**2                  ALLOC 12 .bss.APP_Rx_ptr_out 00000004  200010f0  08003688  0001013c  2**2                  ALLOC 13 .bss.FrameCount 00000004  200010f4  0800368c  0001013c  2**2                  ALLOC 14 .bss.APP_Rx_length 00000004  200010f8  08003690  0001013c  2**2                  ALLOC 15 ._usrstack    00000100  10000000  10000000  00018000  2**0                  ALLOC 16 .comment      00000070  00000000  00000000  0001013c  2**0                  CONTENTS, READONLY 17 .ARM.attributes 0000002f  00000000  00000000  000101ac  2**0                  CONTENTS, READONLY 18 .debug_aranges 00000978  00000000  00000000  000101e0  2**3                  CONTENTS, READONLY, DEBUGGING 19 .debug_info   000139de  00000000  00000000  00010b58  2**0                  CONTENTS, READONLY, DEBUGGING 20 .debug_abbrev 00002ffd  00000000  00000000  00024536  2**0                  CONTENTS, READONLY, DEBUGGING 21 .debug_line   00008458  00000000  00000000  00027533  2**0                  CONTENTS, READONLY, DEBUGGING 22 .debug_frame  000015f0  00000000  00000000  0002f98c  2**2                  CONTENTS, READONLY, DEBUGGING 23 .debug_str    0005a77f  00000000  00000000  00030f7c  2**0                  CONTENTS, READONLY, DEBUGGING 24 .debug_loc    00005d75  00000000  00000000  0008b6fb  2**0                  CONTENTS, READONLY, DEBUGGING 25 .debug_ranges 00000970  00000000  00000000  00091470  2**3                  CONTENTS, READONLY, DEBUGGING 26 .debug_macro  0001123d  00000000  00000000  00091de0  2**0                  CONTENTS, READONLY, DEBUGGING

Notice all those ''.bss.XXXXX'' sections, one of which is .bss.APP_Rx_ptr_in.

For some reason the linker is putting some variables in their own sections.  Unfortunately, they are outside of the areas that are mapped for initialization in startup_stm32f4xx.s.  I haven't been able to nail down why that's happening, but I was able to work around this by forcing the initialization of each of these variables at the top of main.  After doing that, magically I now have data transfer in both directions.Have you ever seen this behavior before?I'm using gcc version 4.7.3 20130312 on Cygwin.  

[Tesla DeLorean]

Posted on August 29, 2013 at 18:10

The release has an earlier .LD file, you need to add *(.bss.*) into the .bss section

/* This is the uninitialized data section */
.bss :
{
. = ALIGN(4);
/* This is used by the startup in order to initialize the .bss secion */
_sbss = .;
*(.bss)

*(.bss.*)

*(COMMON)
. = ALIGN(4);
/* This is used by the startup in order to initialize the .bss secion */
_ebss = . ;
} >RAM

I use Yagarto for GNU/GCC under Windows.