USB OTG interferes with ST-Link

[macfrenz]

Posted on December 19, 2014 at 15:10

I have a problem where USB OTG sometimes interferes with the ability to program the MCU though the mini USB port. Basically what happens is that when I try to program the MCU, the software on computer halts. When I press the reset button it starts programming the chip correctly. Also it will be able to program the chip after waiting a few minutes.

The problem seems to arise when I try to force the usb otg to device mode by setting FDMOD bit in OTG_FS_GUSBCFG register. Also the micro USB cable needs to be connected to the computer for this to happen, if I unplug either end of the cable this doesn't happen. Also commenting out the initialization of pins (8, 9, 11, 12 on GPIO A) helps somewhat, but still programming doesn't succeed within a few first seconds after reset. I'm using STM32F4Discovery board. For programming I use openocd and I compile with GCC. Also I am _not_ using any USB stack but trying to write my own.

[Tesla DeLorean]

Posted on December 19, 2014 at 17:18

A common way to lose debug communications is to place the device into a low power mode, or reconfigure the GPIO pins used by the JTAG/SWD interface.

For issues which you can confine to OpenOCD operations, you'd need to discuss with the developer/community for that project. Alos be aware that the ST-LINK isn't considered a strong commercial grade debugger, for that you might want to look at Segger's J-Link, which is markedly more robust.

[macfrenz]

Posted on December 19, 2014 at 17:51

A common way to lose debug communications is to place the device into a low power mode, or reconfigure the GPIO pins used by the JTAG/SWD interface.

I double checked and I'm doing neither. For issues which you can confine to OpenOCD operations, you'd need to discuss with the developer/community for that project. Well, I can't rule out problems with openocd, but still, certain settings in USB OTG FS registers cause this problem to appear. Other times OOCD works flawlessly. One thing I noticed that seems to cause this is if I try to force device mode too soon after powering transceiver up through bit 16 in OTG_FS_GCCFG register. Adding some delay between those register writes seems to help somewhat. However even 20 ms of delay wasn't enough, 200 ms did do it... Still I can't quite get how all this can affect the operation of debug port...?

[Tesla DeLorean]

Posted on December 19, 2014 at 18:12

Still I can't quite get how all this can affect the operation of debug port...?

Yeah me neither, but the STM32F4-DISCO has a whole load of crap on the board, rather than being just a break-out board, so I wouldn't rule out some undesired connectivity there. Review the pins being used, and the schematic. Check also DBGMCU settings, and how those might need to be set. Try using a different debugger, Keil for example works directly with the ST-LINK, and can use GNU/GCC code.

[macfrenz]

Posted on December 19, 2014 at 19:13

> Still I can't quite get how all this can affect the operation

> of debug port...?

>

> Yeah me neither, but the STM32F4-DISCO has a whole load of crap > on the board, rather than being just a break-out board, so I wouldn't > rule out some undesired connectivity there. Review the pins being > used, and the schematic. I've checked the schematics and there seems to be no problem. Of course I could have missed something... By the way, when I request a reset through the st-link, is it done by pulling NRST pin low or via a soft reset? > Check also DBGMCU settings, and how those might need to be set. > Try using a different debugger, Keil for example works directly with > the ST-LINK, and can use GNU/GCC code. I can try another debugger when I'll have access to a windows machine. Unless you can suggest something that runs on linux? Also I did check DBGMCU settings and I couldn't find anything relevant.

[Rogers.Gary]

Posted on December 20, 2014 at 03:34

Sounds suspiciously similar to the problem I am having - just posted in this forum thread and I hope someone can help me. The Discovery baord works OK with the IAR debugger downloading, connecting and running. But when I use the ST Link, the SPI stops working so I can no longer control an attached board with a peripheral.

Makes no sense...I don't think ST has any idea how annoying this is...gasp...

[macfrenz]

Posted on December 20, 2014 at 14:39

Okay, so it seems that this isn't caused by the discovery board or stm chip after all... Finally I got idea to monitor the USB traffic, which I should have done long ago.

Both the mini-usb for programming and micro-usb for the OTG were connected to the same host controller through computer's internal hub. Since my device's setup package handling wasn't yet filly implemented, host had problems addressing the device and kept trying to do that, blocking the USB traffic to ST-link. I'll get back when I can confirm that this fixed the problem. But thanks for your help and suggestions so far.