Cube Middleware for USB CDC fails to create port on STM32F4x9I-EVAL board

[jon239955_stm1_stmicro]

Posted on July 20, 2016 at 00:51

I am using STM32CubeMX to generate code to create a USB CDC device on the STM32F4x9I-EVAL MB1045 Rev B board which has a STM32F429VGT6 microcontroller. 

For testing I connect the OTG FS1 USB connector on the STM32F4x9I-EVAL board to a Raspberry Pi acting as the host Linux system.  When I run the Cube generated code (see attached project) I do not see a virtual TTY appear on the Raspberry Pi system. I have run the same test using Cube generated code for the STM32F4-DISCOVERY board with an STM32F407 Microcontroller and with that board I do see a /dev/ttyACM0 virtual TTY appear. With the failing test on the STM32F4x9I-EVAL board I have tried both the OTG FS1 and the OTG FS2 connectors.  I do see the associated LD7 and LD9 LED's turn green when I connect the micro USB cable.  I am wondering if there is some board configuration or jumper that I have missed?  Note that I am running the CUBE generated code without modification except for testing return code from the USB Init routines in MX_USB_DEVICE_Init().  There are no errors returned by the generated code for the STM32F4x9I-EVAL board.  The demo is being compiled and run using Keil uVision V5.20.0.0 I added a counter in the OTG_FS_IRQ handler and compared the difference between the failing F429 board and the working F407 board When the USB cable is connected from the Linux system to the F407 board it generates about 97 interrupts before creating the virtual TTY port. When the USB cable is disconnected it generates 1 interrupt and the virtual TTY is deleted. When the USB cable is connected from the Linux system to the OTG FS 1 connector on the F429 board it generates about 1140 interrupts and no virtual TTY port is created. When the USB cable is disconnected from the OTG FS 1 port then one interrupt is generated When USB cable is connected or disconnected from Linux to the OTG FS 2 connector on F429 board no interrupts are generated. From this information I am inclined to conclude that the F429 board is recognizing the Linux host but failing to establish the connection after numerous retries.

The attached ZIP file contains the full project and also the Cube IOC file.  Looking for solution to getting CDC working on STM32F4x9I-EVAL.

#cubemx #eval #bug #stm32f4

[Amel NASRI]

Posted on July 20, 2016 at 16:37

Hi newbill.jon,

Please refer to

http://www.st.com/content/ccc/resource/technical/document/user_manual/12/4b/55/6a/c4/b2/4f/27/DM00093451.pdf/files/DM00093451.pdf/jcr:content/translations/en.DM00093451.pdf

. You find there the required HW update you need to do in order to use USB OTG1 FS or USB OTG2 FS.In OTG2 FS case for example, a PCB rework is needed for example. ALl details are there in the application note.-Mayla-

[jon239955_stm1_stmicro]

Posted on July 20, 2016 at 19:04

@Mayla,

I have already looked at

http://www.st.com/content/ccc/resource/technical/document/user_manual/12/4b/55/6a/c4/b2/4f/27/DM00093451.pdf/files/DM00093451.pdf/jcr:content/translations/en.DM00093451.pdf

quite a bit.  In section 2.7 on OTG FS 1 I do not see that any PCB modifications are necessary to use OTG FS1 other than the removal of JP16 which was already removed.  Section 2.12 table 9, I believe has a typo as it says JP16 must be 'fitted' to connect to USB FS1 DM.  This contradicts the statement in section 2.7.  I believe the red highlighted '

fitted

' below should read unfitted.   Although I have tried testing with and without JP16 without success.  From reading UM1667 section 2.8 the only port that it says requires PCB mods is OTG FS2.  As described above attempts to use FS1 are failing although cable connection to FS1 is generating over 1000 USB OTG interrupts.

Section 2.7

      JP16 must be removed when using USB OTG FS as mentioned in Table 9

Section 2.12 Table 9

    JP16

    PA11 is only connected with USB FS1 DM signal when JP16 is

fitted

. (default setting)

    PA11 is connected with CAN RX signal when JP16 is fitted.  If the CAN function is being used, USB connector CN14

             should be disconnected to leave

USB FS1_DM signal floating

This is further confirmed by looking at the schematic which shows that PA11 is hard wired to USB FS1 DM and that installing JP16 connects CAN1 RX to PA11 and therefore JP16 should be removed when using OTG FS1.

[jon239955_stm1_stmicro]

Posted on July 22, 2016 at 22:10

I received the following from tech support

There is a bug found in the latest PCD HAL driver v1.5.0 (\F429CDCONLY\Drivers\STM32F4xx_HAL_Driver\Src\ stm32f4xx_hal_pcd.c)  in functionâ€� HAL_PCD_IRQHandlerâ€�

The function assumes a HCLK = 180MHz  “  uint32_t hclk = 180000000;â€�   you need to change this value  according to your AHB clock (so here 16MHz).

Also there is another fix to be done which is allocating more space for the heap memory ( by default CubeMx allocates 0x200 bytes) , 

I had already discovered the insufficient heap problem when testing with the F407-DISCOVERY board.  Making the change to the

stm32f4xx_hal_pcd.c file has resolved the issue.  I have tried to find the heap allocations to add error checking but so far have not found them.

[Tesla DeLorean]

Posted on July 23, 2016 at 01:19

Keil usually defines stack and heap sizes in startup_stm32fxxx.s

[jon239955_stm1_stmicro]

Posted on August 04, 2016 at 22:29

@clive1 ,

You misunderstood my final question.  I had already increased the heap value in startup_stm32fxxx.s to solve the problem.  My question was why there was not a more appropriate error or exception for the out of heap failure.  I was questioning where the calls to new/malloc were in the USB CDC and/or HAL library routines and why there appears to be no error handling.  It would have been much easier to see the heap issue if the failure had been reported with some form of error/exception.