Main Site Documentation

Panda intermittent booting with SD expansion


#1

I’m using a Panda v1.2 with the SD card expansion. I am using this to prototype and wanted the SD card to be on the side like on the Domino just for physical packaging reasons, so I put down some Kapton tape and stuck the expansion board on the back (see picture.) I wired it up with some 30awg wire across the back of the board and found that it no longer booted. I did a lot of checking but couldn’t find anything until I removed the wires to the expansion board at the expansion board end and it would boot again. I thought maybe I had a bad expansion board so I switched it out but same issue. Doing more experimenting the only consistent factor I have found is that when the lines to the expansion card are low impedance the board will not boot. It doesn’t seem to go into the user code at all as I changed it to turn on the LED first thing and it fails to do that.

Also the problem is worse when I use the com port for debugging (which I will in my application.) However just removing the mode jumper doesn’t fix the issue every time. I found that I could get the system to boot by just raising the wires off the back of the board, though this sometimes proved intermittent. My only thought on why this would work is that it changes the capacitance thus raising the impedance. To examine that further I took some sheet ferrite material and placed it under the lines to raise the inductance, this makes it stable and with that setup it will boot every time.

I’m getting the board this is going into laid out over the next week or so and am hoping to have some more understanding of what’s going on so I don’t end up making boards with the same problem. I’ll be using the USBizi chip directly in the layout and not the Panda board, but am basically following the board as a reference design. I checked the lpc23xx user guide and don’t find any layout notes for the SD bus. I’m wondering why changing the debug interface would have any effect on the situation. I’m considering just removing the ground plane under the SD lines in the final layout as a precaution. Any insight would be greatly appreciated.

Thanks for your help.


#2

Have you tried your setup with power supply? What voltage?


#3

I tried it with a +12v supply and that didn’t change anything, though I would be happy to try it at any voltage you would like. Interestingly I have found that even just putting the SD expansion board on with no SD card loaded using the included angle header causes the issue. Then when I disconnect the mode jumper it will work again. So it is strangely tied to booting with the com debug interface.

Also if I plug in an FTDI USB->Serial cable to the debug com port with or without the USB side of the cable plugged in to the PC the board boots no problem. I’m using the TTL-232RG-VIP-WE cable, I brought the serial tx/rx and gnd/3.3v(for reference) to a plug header and plugged in the cable.

Initially because the non-boot seemed like a power/clock issue I put a scope on the 3.3v, 5v and ground, I don’t notice any spurious signals or appreciable difference with anything I did. I tried tacking on another cap (right at the 3.3v regulator) when I noticed C12 was geographically far from IC4 (thinking maybe it was too far away to guarantee stability) and didn’t notice any major improvement.

Also I used a Mini with the SD in the same application without issue, but I need more GPIO lines than it has available.


#4

have you checked for any weird solder-bridges with a multimeter to see if you have connectivity between MODE and any other pin? I have a “bent” socket/header setup using standard female socket with a slight outward bend on it, and slightly bent male on the SD card daughtercard (to move them out of a shields way but still allow easy disconnect if needed), and I show no continuity between MODE or any other IO or 3v3/gnd - my Panda restarts fine.


#5

I checked all the connections and made sure nothing was shorted, I have actually done this with 3 Panda boards now trying different things(hope I wouldn’t make a soldering error that many times!) The only board that I used the angle bracket on is already mounted on some perf-board and has about 20 GPIO lines run to a IDC header to connect out to another PCB as well as a 5-pin header for the debug com port, perhaps this is the difference… When neither the com port or the IDC header is plugged into anything it won’t boot, won’t reset, won’t load bootloader. When I disconnect the mode jumper it’s fine. When I plug in the FTDI cable it’s fine with or without the jumper (wish I knew the circuit for that cable.) Also I’ve found if the board is starting intermittently, if I get it to not boot, reset does nothing and I have to power cycle it. However if I get it to boot sometimes resetting it with the reset button will cause it to hang and not reboot.


#6

Short MODE pin high or low to select the interface you want and try again.


#7

Not sure what you mean by this, so let me clarify my situation: I have added a two-pin header and a jumper (like on a PC motherboard) to short the mode pin to ground or not. I’ve never tied it to +3.3v if that’s what you mean by high, only to ground to select com1 as debug interface or disconnect (float) the pin to use the USB debug. I was only removing the jumper to test, I will always use the com1 debug interface in my application. In testing I have found that the problem usually only occurs when the debug interface is set to com1 using the jumper. I do not have a problem with getting the com1 debug interface selected I have a problem with the processor not booting at all when it is.


#8

So you are setting MODE low for COM debugging but the board sometimes doesn’t boot. This I understand but this in no way related to the SD card or wires. This can happen if there is nothing connected on the RX pin on COM1. The floating signal can cause noise on power up to the UART which cause problems. Add a pull down/up resistor to UART RX pin and it should fix your problem.


#9

Thanks! That was the problem, it also makes good sense why the mini worked now.