2016-04-03 07:20 PM
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 #cdc2016-04-04 09:56 AM
Hi Dave,
Thank you for your feedback. The issue has been reported internally.-Syrine-2016-04-12 02:33 AM
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.
2016-04-12 02:44 AM
Hi,
A similar issue is already discussed . 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.
2016-04-12 01:26 PM
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 receptaclePA9 (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 heapusbd_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=false2017-09-28 04:19 AM
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
2017-10-10 12:38 PM
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=false2017-10-11 05:00 AM
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
2017-10-12 12:37 AM
Hi Cyril!
Thanks for reply!1) The Stack and Heap look good: **GCC._user_heap_stack0x20000b18 0x6000 load address 0x08008d080x20000b18 . = 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!
2017-10-12 04:32 AM
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