Programming problem on Open407I-C with LCD

[dannym]

Posted on December 17, 2012 at 22:26

I just started with the STM32F407 Open407I-C board:

http://www.wvshare.com/product/Open407I-C-Standard.htm

It's a pretty excellent demo board.  Very little pin commitment on the board, most are just straight brought-out to 0.1'' pin headers for the many cheap accessories to be plugged in.  LCD, camera, ethernet phy, USB phy, etc.The thing I love is there's straightforward, fully working demo code for EVERYTHING for EVERY board they make, including a Keil UVision project file.  Unfortunately, very little of that can be downloaded from their website, it's on a DVD you get with the motherboard.Anyhow, my problem is this.  Anytime I have the LCD plugged in, my Segger J-Link fails to program or debug with this:''No Cortex-M Device found in JTAG chain''Without the LCD plugged in, it programs fine through the J-Link, but there'd be no way to debug.So I contacted their support (broken English) and got:''The RESET pin will be shared, use the SWD mode to avoid it, thanks!!''Well that's not a good solution.  I'm not clear on what the consequences are of using the SWD, and I need to be able to program without removing the LCD each time!  There's the USB OTG port on the core breakout board containing the STM32, but I've got a Segger J-Link right here.I'm confused.  Yes, the LCD's Reset pin (active-low AFAIK) was tied to NRST (pin 31 of the 144-pin STM32F407), which doesn't make a lot of sense since the controller doesn't drive NRST AFAIK and it's not under software control.  It's an input to the LCD, and an ohmmeter shows only a 5meg pullup resistance to 3.3v on the LCD hardware itself.  So, any idea why the LCD would be interfering here?  I don't get it!  The only thing I could think of was maybe the demo code temporarily turned NRST into an output to reset the LCD alone from the STM32 (I'm unfamiliar with these STM32 hardware features, that may not make sense), and if the LCD was installed, maybe the code left it high but DRIVEN high (not high impedance).  Which would be an error.  I found nothing in the code so far that suggests this, but the code's fairly complicated.

[Tesla DeLorean]

Posted on December 17, 2012 at 23:00

Can't the processor drive NRST based on the internal POR circuit? It's a bidirectional pin on nearly every ARM processor I've encountered. Very big problems occur if it's actively driven high, and thus should only be driven low using open-drain drivers.

If the vendor says use SWD mode it's indicative that one of the JTAG mode pins clashes with the LCD. SWD uses two signal wires, and is a multiplexed JTAG like interface, that is just as effective for debugging purposes. Suggest you review the schematics with specific attention to PA15, PB3 and PB4.

[dannym]

Posted on December 18, 2012 at 08:34

Ah-ha!  Yes, PA15, PB3 and PB4 are LCD CS, CLK, and DOUT.  So that's the problem right there, nothing to do with RESET (NRST) pin.  I don't know Support told me that.

Gee, 144 pins on that package and they assigned a conflict between the programmer and the most likely peripheral you'd plug in most often... why??OK, I found the option to switch the J-Link over to SWD in Keil, I couldn't find that last night.  It works!  Looks fast, too, I was worried that this was a ''crippled'' interface but so far it looks ok.