ST-Link Connection Causes NUCLEO-F411RE Demonstration to Fail When Reading SD Card

[xlh1460]

Posted on April 06, 2016 at 19:02

I encountered this problem while trying to run the demonstration firmware under the debugger.

I am running the Demonstration firmware on the NUCLEO-F411RE board with the Adafruit 1.8'' TFT Shield attached. I have two of each board and have pretty much ruled out bad hardware. I checked the datasheet for the MCU and there is a warning in the SPI section about a potential conflict with the SWD/JTAG ports and certain pins. I have thoroughly checked the documentation for the NUCLEO board and the Shield and the pins used for the debug interfaces don't appear to be relevant to this hardware configuration. The following steps consistently demonstrate the failure: 1. Connect the USB cable to the NUCLEO board. 2. The demo application launches and runs correctly (the images on the SD card are displayed) 3. Launch the STM32 ST-LINK Utility. Press the connect button, once connected, press the disconnect button. 4 The demo application again launches but displays ''Open directory fails.'' when it tries to access the SD card. 5. Press the reset button, same failure as in step 4. 6. Disconnect and reconnect the USB cable and the application again runs correctly. I have also tried the demonstration from different versions of the firmware (v1.4 and v1.10). Since neither the hardware nor the code were developed by me, I am wondering if it would be appropriate to attempt to go directly to ST for support. If anyone has any ideas or suggestions on what the issue may be or what to try next, I would appreciate it. Thanks in advance. Dale.

[Tesla DeLorean]

Posted on April 06, 2016 at 19:26

Since neither the hardware nor the code were developed by me, I am wondering if it would be appropriate to attempt to go directly to ST for support.

Are you a big enough customer to expect that level of support? If no, then the burden of working through this will fall on you, and others, working with these board combinations.Who's demonstration software are we talking about here? Which pins is it using, what pins are being complained about?For the SPI SD implementations, I'd expect your issue relates to the initialization, or reinitialization, of the card.

[xlh1460]

Posted on April 08, 2016 at 05:06

Hi Clive,

Thank you for taking the time to respond.

I wasn't aware that size mattered to ST although I did feel that I should reach out to the community first.

The demonstration that I am talking about is that which is provided by ST with the stm32cubef4 firmware library under the folder ''STM32Cube_FW_F4_Vx.y.z\Projects\STM32F411RE-Nucleo\Demonstrations''.

The pins used to communicate between the shield and the NUCLEO board are as follows:

PB0 - ADC1_8 used for Joystick

PA5 - SPI1_SCK used for TFT display and SD card reader       PA6 - SPI1_MISO used for TFT display and SD card reader PA7 - SPI1_MOSI used for TFT display and SD card reader PB6 - SPI1_CS used for TFT display               PA9 - used for Data/Command on TFT display PB5 - used for CS on SD card reader

I am not sure what you meant when you asked about which pins are being complained about.

There is a warning in the SPI section of the the STM32F411RE reference manual about a potential conflict between the debugger and the following pins:

PA13,PA14,PA15,PB3,PB4

None of those appear to be in use for this application which is why I am confused as to why the debugger seems to be interfering with normal operation.

I guess I need to roll up my sleeves and put on my thinking cap ...

[Tesla DeLorean]

Posted on April 08, 2016 at 06:42

Sorry, just trying to frame expectations, a $10 board isn't going to get anyone hundreds of dollars of engineering time/focus. Doing $100K-$1M might get you an engineer, or two. You should probably use the forum(s) to find people with similar boards/issues/goals to work through the issues with.

Avoiding specific pins, will allow debugger connectivity. Parking a peripheral debug view over an SPI or USART type peripheral is likely to break it. The debugger does not have magic access to the registers, any view you take of them will have the same side effects, ie reading DR clears bit in the SR. So single stepping SPI code while peering into the peripheral state is likely to fail. CubeMX throws up contention indicators when peripherals and pins clash, options and choices are make available, or removed. Can't say I've looked at those specific Cube examples, but there is certainly plenty of example code from the last 6-7 years that have defects, errors and omissions. The SPI-SD code has certainly had issues with SDHC cards. I've had both SPI and SDIO interfaces working with NUCLEO boards, with SDHC and SDXC cards, so they are definitely viable at a hardware level, but I'm not using the Cube/HAL.

[xlh1460]

Posted on April 08, 2016 at 15:47

deleted duplicate post.

[xlh1460]

Posted on April 08, 2016 at 15:47

Clive, thanks but I don't think that I need to have my expectations framed since I had no expectations to start with. I simply posed a question as to whether or not it would be worthwhile running it by ST support. You clearly think not, I can accept that, moving on.

''You should probably use the forum(s) to find people with similar boards/issues/goals to work through the issues with.'' That is what I thought/hoped I was doing by posting here. Did I post this in the correct place? The points/cautions that you made about the debugger were received loud and clear though. There I likely

did

have unreasonable expectations,

However, to clarify:

1. I have confirmed that the pins that the debugger uses are not being used by this application.

2. Simply connecting/disconnecting the ST-Link Utility causes the application to fail. I am not parking the debugger nor single stepping the code to cause the failure. 3. System reset doesn't restore operation but POR does. I clearly don't have in depth knowledge of how the ST-Link works nor how it impacts the MCU internals so maybe this behavior is normal. Thanks again. Dale.

[Tesla DeLorean]

Posted on April 08, 2016 at 18:35

This is as good a place as any, but the more specific the issue, the shallower the pool of respondents. This is primarily a user forum, ST does not have a high level of participation here. Customer support typically comes via distribution channels, their FAE's and ST's FAE's.

People have been complaining about reset issues with the recent ST-LINK firmwares, you might want to update that first. 

http://www.st.com/web/en/catalog/tools/PF260217

With external SPI/I2C devices there typically isn't any asynchronous reset signal, these peripheral can start in odd states, this perhaps can be exacerbated by methods used by the debuggers to wrestle control of the part, especially if you try to access these parts early in your own code. Check options like ''connect under reset''

[xlh1460]

Posted on April 08, 2016 at 20:58

I hear you. I am sure if someone had an easy fix they would have likely chimed in by now.

I have before me a learning opportunity. :) Thanks again for your time and your patience with this newbie. Dale.