cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F4Discovery and USB

davhak
Associate II
Posted on January 22, 2014 at 13:16

Dear All,

I had a workign VCP example on STM32F4Discovery board until some recent changes to my own code (the USB and standard peripheral libraries are not changed).

I use EmBlocks 1.42 IDE for compilation/debugging under Windows.

The problem occurs already at the USBD_Init function call

[b]

USBD_Init(&USB_OTG_dev,

#ifdef USE_USB_OTG_HS

          USB_OTG_HS_CORE_ID,

#else

          USB_OTG_FS_CORE_ID,

#endif // USE_USB_OTG_HS

          &USR_desc,

          &USBD_CDC_cb,

          &USR_cb);

[/b]

where the variable USR_cb which is defined in one of the sources of the USB library contains pointers to some internal functions. The first function pointer should point to an Init function (which is an empty function in my case). The point that at the USBD_Init call the first functions pointer of the USB_cb variable points not to the Init function but has an address 0x04xxxxxx which is obviously outside of the dedicated scope for the program residing in FLASH.

If I add a line USB_cb.Init(); just before calling the USBD_Init(...); then I see that the USB_cb.Init function pointer is properly initialized (has an address 0x08xxxxxx). Tracking down to the point where the USB_cb is initialized one reaches the CopyDataInit: loop in the Reset_Handler routine of the startup*.S file. Already there the initialization of the function pointer of USB_cb (at RAM address 0x2000013C) is done incorrectly and at the offset of 0x13C in the Flash memory where the initial value (correct address of function Init) should be written (at address 0x08014398) another value 0x04xxxxxx is sitting.

The program size is small (~88KB). The linker script seems to also having an adequate values:

[b]Linker script[/b]

[i]

_estack = 0x20020000;    /* end of 128K RAM */

_Min_Heap_Size = 0;      /* required amount of heap  */

_Min_Stack_Size = 0x400; /* required amount of stack */

MEMORY

{

  FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 1024K

  RAM (xrw)       : ORIGIN = 0x20000000, LENGTH = 128K

  MEMORY_B1 (rx)  : ORIGIN = 0x60000000, LENGTH = 0K

}

[/i]

Interestingly, initially the program was working when its size was twice as bigger as the current one (~150KB). I have tried to decrease/increase the stack size in the linker script without any positive outcome.

The variable USB_OTG_dev is properly aligned by __ALIGN_BEGIN / __ALIGN_END directives. These directives are always defined (regarding whether DMA is enabled or not).

This problem still looks like having some alignment related issues, although I have not changed anything in the USB aligned variables.

Can somewhat advise how may I track down further why is a wrong value in the FLASH is written for initializing the USB_cb variable?

Thanks very much for any help.
3 REPLIES 3
davhak
Associate II
Posted on January 22, 2014 at 13:40

Small addition:

Just noted the this value 0x04xxxxxx is written in the Flash address which is by -4 bytes smaller than the actual Init function address value i.e. 0x04xxxxxx is written at address 0x8014398 and the Init address is written at 0x801439C. How can this happen that the variable in ram at offset 0x13C (address 0x2000013C) has its initialization value written in the flash at offset 0x13C + 4 starting from the Flash block part which holds the initial values for the variables (address 0x801425C) ?

Thanks a lot for any suggestion.

Posted on January 22, 2014 at 16:05

I've tried to muddle through the narrative there, and I'm not sure what's going on. So I'll ask some questions.

Are you using C++?

Are the constructors (ctors?) being called by the startup code?

Is the stack adequately sized?

Does the .MAP file reflect the odd locations of the variables in question?

How about the .LST? Can you provide a snippet of the assembler code around the call, and the literals pool it's drawing from.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
davhak
Associate II
Posted on January 24, 2014 at 11:24

Dear Clive,

Thank you very much for your consideration.

The problem is now solved i.e. the program is working, although I have not gone into analysing is there something wrong with the linker script or the startup files. I switched to using the ones provided by EmBlocks and they seem to produce a correct code.

For more information for those who are interested and also for working VCP examples with/without FreeRTOS please see

http://www.emblocks.org/forum/viewtopic.php?f=26&t=171

.