USB data buffer overlaps with stack leading to fault

[bnp979]

Posted on January 25, 2015 at 10:27

Hi,

I am running a USB MSC project on my STM32L1 board generated using the CubeMX software.I am noticing that during enumeration, the device receives a Read10 request for 16 blocks of data (each 512 bytes in size). I see that the pointer for the data buffer allocated for this request (and passed to Storage_Read_FS as parameter 'buf') eats into the current boundary of the stack. As a result when I write the relevant read data into this buffer it corrupts the stack, thereby leading to a fault.I notice that when this corruption occurs, the stack is only 0x136 bytes in size whereas the size of stack that I have configured is 0x800. This makes be believe that the issue is not that the stack is too small.Here is my stack size configurationStack_Size      EQU     0x00000800I'm wondering why the location for the USB data buffer was allocated too close to the stack.Any inputs are greatly appreciated.Thanks,Ben 

[Tesla DeLorean]

Posted on January 25, 2015 at 15:38

Well I guess the question you have to ask yourself is where the buffer memory allocation is coming from. ie Static (Linker), Dynamic (Heap), Local/Auto (Stack)

And if it's overrunning the allocation.If it is a local rather than static, 16 blocks will take 8KB, for which a 2KB stack will be insufficient.

[bnp979]

Posted on January 25, 2015 at 20:50

Hi,

This buffer is provided by the Cube framework and not by my code.I see that ultimately the packet is being created in USBD_static_malloc which *always* returns a buffer of size 1000 bytes, whereas the requested buffer size is 8192 (based on the read data size).Any idea why the size is set to 1000? I'd have thought for MSC class devices this should be set to the packets corresponding to  maximum read/write size supported.Is this something I as the user am supposed to modify?

[Tesla DeLorean]

Posted on January 25, 2015 at 21:33

Well I'm not an advocate for HAL/Cube, it's not clear to me why it would be allocating buffers. If the allocator is broken you'll need to wade through that portion of the source, and make sure the initial heap size is adequate for the anticipated use patterns.

If Cube is using the underlying compiler libraries, then those need to have sufficient heap space, and throw errors if the allocation fails. For Keil the heap size is defined in startup_stm32fxxx.s, and the heap is typically just below the stack.