CubeMX V4.14 Nucleo STM32f446re USB Problem

Sidlauskas.David · ‎2016-04-03

Posted on April 04, 2016 at 04:20

Using CubeMX I've built a simple USB FS device CDC project targeted to the Nucleo 64 STM32f446 board. When I run the generated code, DP is never even pulled high so USB doesn't even get started.

I loaded the USB VCP demo project for the EVAL board into the Nucleo and it starts up OK so I think the hardware is good.

Does anyone know of problems with CubeMX generating USB code for Nucleo F446RE's?

Thanks,

Dave

#device #usb #cdc

Nesrine M_O · ‎2016-04-04

Posted on April 04, 2016 at 18:56

Hi Dave,

Thank you for your feedback. The issue has been reported internally.

-Syrine-

pushok · ‎2016-04-12

Posted on April 12, 2016 at 11:33

Hello, Dave. Try this. After generating code in Cubex check in file usbd_conf.c line ''hpcd_USB_OTG_FS.Init.vbus_sensing_enable'', this property must be disable. This is a Cubex bug. Independently of setting vbus property in CubexMX after generating code this property is always set enabled.

Amel NASRI · ‎2016-04-12

Posted on April 12, 2016 at 11:44

Hi,

A similar issue is already discussed

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32L4%20DISCO%20USB%20DEVICE%20DOES%20NOT%20WORK

.

You have some valuable suggestions there from forum users. Problem is still under review internally.

-Mayla-

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

tsuneo · ‎2016-04-12

Posted on April 12, 2016 at 22:26

Here is a couple of points to be aware of.

NUCLEO-F446RE

- CubeMX: v4.14

- STM32Cube_FW_F4_V1.0

- USB CDC device

1) Connection of USB B-type receptacle

PA9 (CN10 pin21) -- VBUS <-- required

PA12 (CN10 pin12) -- D+

PA11 (CN10 pin14) -- D-

GND (CN10 pin9) -- GND

Generated code enables VBUS sense option.

usbd_conf.c

USBD_StatusTypeDef USBD_LL_Init (USBD_HandleTypeDef *pdev)

{

...

// line 287

hpcd_USB_OTG_FS.Init.vbus_sensing_enable = ENABLE;

And then, connect VBUS (5V) to PA9.

2) Clock source - MCO from ST-Link

My NUCLEO-F446RE (MB1136 C-03 revision) has default MCO connection from on-board ST-Link. If your board would be C-01 revision, solder the jumpers, following to section ''5.6.1 OSC clock supply'' of the NUCLEO64 manual (UM1724).

http://www.st.com/web/en/resource/technical/document/user_manual/DM001058pdf

On CubeMX - Pinout tab,

RCC - High Speed Clock (HSE) - BYPASS clock source

3) Heap size

USBD_CDC_Init() claims 0x0214 bytes from heap

usbd_cdc.c

static uint8_t USBD_CDC_Init (USBD_HandleTypeDef *pdev,

uint8_t cfgidx)

{

...

// line 517

pdev->pClassData = USBD_malloc(sizeof (USBD_CDC_HandleTypeDef)); // 0x0214 bytes

Increase heap size on CubeMX Project Settings dialog (default 0x200)

Project menu > Settings > Minimum Heap Size

CubeMX setting file is attached.

Tsuneo

________________

Attachments :

cube_nucleo_f446_cdc_device.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzJR&d=%2Fa%2F0X0000000bN6%2FS0wpf58h2no7cYugp2m_Eh.41r7CFmXMcI8w4MGSMmo&asPdf=false

Cyril FENARD · ‎2017-09-28

Posted on September 28, 2017 at 13:19

Hi

Sidlauskas.David

,

According STM32F446xC/E datasheet p138/202:

'When VBUS sensing feature is enabled, PA9 and PB13 should be left at their default state (floating input), not as alternate function.A typical 200 µA current consumption of the sensing block (current to voltage conversion to determine the different sessions) can be observed on PA9 and PB13 when the feature is enabled.

As I understand, CubeMx generates code correctly as far vbus is concerned.

'DP is never even pulled high', as you wrote, suggests the software running on you target seems to be crashed.

Did you follow help from

Chinzei.Tsuneo

? Is issue solved your side now?

Note also that CubeMx in 4.1 version is currently available and it is recommended to upgrade to new version.

Regards.

Cyril

Vladislav Leschenk · ‎2017-10-10

Posted on October 10, 2017 at 21:38

Hi All!!

I have the same issue with GCC (AC6 STM32 MCU GCC toolchain) but, the same code generated for uVision5 works well.

I used:

1) CubeMX 4.0

2) Last version of STM32 workbench

The issue is that VCP can't be opened by reason that it is can't be configured - windows 10 is wrote (tested with 5 PC). But at the same time W7 - everything looks good (i tested weth only one PC with W7)

May be someone faced with it and know how it can be fixed for GCC? Whats the problem?

________________

Attachments :

error.PNG : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyNU&d=%2Fa%2F0X0000000b6q%2Fc.DNNS25F._t.rF0ZECog.C4IPb8o0RjcunmeqCa3yQ&asPdf=false

Cyril FENARD · ‎2017-10-11

Posted on October 11, 2017 at 12:00

Hi

leschenko.vladislav

,

Application binaries appear to behave differently depending on the compilation chain.

Can you inspect your application map file and verify that the stack pointer is properly set with enough memory for the stack to compete with the memory for the heap (in the case of GCC, please check SW4STM32/startup_stm32f446xx.s)?

In any case, before trying to connect to VCP, please make sure that your USB device is properly enumerated and that the VCP is available ( in system property of your PC OS software).

It may be necessary in some cases to connect/disconnect device so that it is properly seen by the host PC.

Hopping it helps understanding and solving the issue.

Regards.

Cyril

Vladislav Leschenk · ‎2017-10-12

Posted on October 12, 2017 at 07:37

Hi Cyril!

Thanks for reply!

1) The Stack and Heap look good:

**GCC

._user_heap_stack

0x20000b18 0x6000 load address 0x08008d08

0x20000b18 . = ALIGN (0x8)

0x20000b18 PROVIDE (end, .)

[!provide] PROVIDE (_end, .)

0x20002b18 . = (. + _Min_Heap_Size)

*fill* 0x20000b18 0x2000

0x20006b18 . = (. + _Min_Stack_Size)

*fill* 0x20002b18 0x4000

0x20006b18 . = ALIGN (0x8)

** uVision

__heap_base 0x20000a98 Data 0 startup_stm32f446xx.o(HEAP)

__heap_limit 0x20002a98 Data 0 startup_stm32f446xx.o(HEAP)

__initial_sp 0x20006a98 Data 0 startup_stm32f446xx.o(STACK)

2) When I connect the VCP to PC the device appear in the system without any errors!

It works well time to time after programming and it woks while the GREEN led is light on the STLink. After power OFF/ON reboot the VCP appear in the system again but I can't open it by the reason that I had described in my first post.

3) If it helps someone to dig this issue and helps another people to use GCC I would add the project for reviewing. This topic I have already found in a several forums, but the solution is to change the HEAP and STACK size and may be it will work. It is a

rain dance!

Just I faced at the first time with the unpredictable behavior with GCC!

Cyril FENARD · ‎2017-10-12

Posted on October 12, 2017 at 11:32

Hi

Leschenko.Vladislav

‌,

As my personal experience, I observed that the stack consumption with the compiled code through the GCC tool chain is double that the arm compiler.

So I suggest you enter the debugging to verify that the depth of the stack does not alter the heap when the application runs.

The map file can give an idea of size for stack and heap, and adding GCC option such as -fstack-usage can give you an idea of the depth of the stack (stack consumption due to interrupt processing may add more in depth).

Knowing this you can estimate that if it will fit in worst case.

Note also that the implementation of memory allocation may be different between toolchains, for GCC, you can re-target sbrk() that is used by your allocator library. This way sbrk () could check the possible memory collision with the stack area.

Hoping this brings more ideas.

Regards.

Cyril