@sazp96, I’ll share my library later (not at home). The 3 minute thing is perplexing which is why I want to test on a stand alone microSD breakout. What type of microSD are you using?
1 Like
Awesome, thanks @peekay123.
I’m using a SanDisc 4G microSD card. I have 3 prototypes built and they are all failing consistently in the same “random” way.
For the 3 min mitigation, I was wondering if that is the time that it takes to charge the capacitors on the PCB. Or it could be the time that it take the wall power source to stabilize the power source… Really, I’m just guessing here, I have no idea and it is affecting me badly.
How does it fail? I notice slow write speed of ~20kB/s for the Photon but not exactly sure the reason yet.
@sazp96, are you using a high quality power supply? How are you powering the display - specifically how are you distributing power to the Photon and display. Do you have decoupling caps near the Photon?
The 3 min thing is not charge time IMO. There is something parasitic going on. Can you post a picture of your setup?
@kennethlimcp, SD.begin() returns false. Digging a bit deeper, in the SDClass::begin() in SD.cpp, both volume.init(card); and root.openRoot(volume); are returning false.
@peekay123, I’m using three different power supplies to test it. It seems that it fails a bit less with one of them. The primary source I’m using is from Seeed studio.
Below is the layout and schematic. I have decoupling caps near the photon and near the LCD.
2 Likes
Thanks @kennethlimcp, right now all the prototypes are working well. I will get one into the faulty state and try your library. I will report back. Thanks!
1 Like
@sazp96, I don’t see a current limiting resistor on the speaker! Remember, the max pin current on the Photon is 20ma. What is the purpose of R1 near J6?
The display schematics show that there are level shifters on the SD lines which should not cause problems. Worst case you can slow the SPI clock to see if the SD works better. Am I correct in assuming the display works on SPI Mode 0?
The “LITE” line goes to a diode with a 10K pull-up to Vcc (5V) on the other side. With LITE low, the Photon pin will sink the current without problems. However, with LITE high or at 3.3v, there is enough delta voltage to forward bias the diode and have current flow INTO the Photon pin - not ideal.
Here is the issue I see with this board. It is a 5V board designed to work with 5V and 3.3v logic, somewhat. I would power the entire board with 3.3V IMO instead of 5V so there are no voltage level surprises.
2 Likes
You are absolutely right. This is in my list of things to fix. I will add a transistor.
I was trying to lover the voltage to 1.5V. That didn't work. But is not critical so I will can that question for a latter day.
Very very interesting. Could you elaborate a bit more on this point. I currently do:
pinMode(pinLite, OUTPUT);
analogWrite(pinLite, 250);
pinMode (SD_CS, OUTPUT);
if (!SD.begin(SD_CS)) Spark.publish("Error/SD.Begin");
Do you think that keeping the pinLite low could solve this issue?
Good point. I need the 5V to power a LED strip. What I could do is power the LCD from the 3.3V output of the Photon. Would this work? I could implement this in the next version of the PCBs.
-
what was the purpose of the 1.5V?
-
With voltage higher on one side of a diode than the other, IF the diode is forward biased (lower voltage on cathode, higher on anode) AND the voltage difference is higher than the diode’s forward voltage (usually 0.7 volts or so for silicon diodes) then the diode will conduct. In this case 5v-3.3v = 1.7v so the diode will conduct and current will flow INTO the photon pin.
-
If you run the board at 5V, you could use a level shifter on the PIN_LITE line, solving the voltage difference issue.
-
With the LEDs, the display will consume too much power from the Photon IMO. It is probably easier to simply use level shifters for the lines going to the display. You could also have an onboard 3.3v regulator just for the display.
1 Like
@kennethlimcp I’m getting a digitalWriteFast was not declared in this scope.
Do you have the code for that function?
Opps… haha! It’s only for V0.4.3 now. You can use:
STM32_Pin_Info* PIN_MAP = HAL_Pin_Map();
void pinSetFast(pin_t _pin)
{
PIN_MAP[_pin].gpio_peripheral->BSRRL = PIN_MAP[_pin].gpio_pin;
}
void pinResetFast(pin_t _pin)
{
PIN_MAP[_pin].gpio_peripheral->BSRRH = PIN_MAP[_pin].gpio_pin;
}
void digitalWriteFast(pin_t pin, uint8_t value)
{
if (value)
pinSetFast(pin);
else
pinResetFast(pin);
}
2 Likes
Thanks @peekay123:
- The 1.5V is to power a clock movement. Any ideas on how can I lover the voltage from 5V in an easy way?
- The pin_Lite pin is working just fine. It is able to control the level of brightness of the screen. Do you think I might be having this issue with the SD_CS?
- I love the idea of powering the display with a 3.3V regulator. Do you know of one? Maybe the one that is used by the Photon.
Now, with my pressing issue of my existing PCBs, I will implement @kennethlimcp SD library. Hopefully that would solve it. If not, I will reduce the speed of the SPI. I will keep you posted.
I gotta say, I've never lovered a voltage and I'm married now, so... 
To power a clock movement, I am assuming it is relatively low current. So one way to lower the voltage is to use a zener diode regulator. Another way is to use an LM117 fixed or adjustable voltage regulator.
-
The PIN_LITE will work but it would be better with a level shifter if you stick with a 5V supply for the display. I don't believe it affects the SD_CS pin.
-
For 3.3V regulator, you only need about 250ma max IMO so you could use a linear device like the LM117/317 or LM4931. There is also this little SMPS that could do the job but may be overkill. The Photon uses a SMPS but the regulator is difficult to find due to demand.
@kennethlimcp, I have implemented your library (very nice btw, thanks). Unfortunately it keeps failing in this random way. The error I get when it fails is: “initialization failed. Things to check:”.
@peekay123, do you think the root cause of the random SD initialization issues is the 5V power vs 3.3V logic mixing?
@sazp96, I need to run some tests tonight before I can answer that.
1 Like
Awesome. I will wait patiently. Thanks!
Some bad news. I powered the LCD from 3.3V source and I still get the same behavior. Sometimes it works, sometimes it doesn’t.
I’m wondering if I have an error in the way I’m initializing the SPI of the LCD and then the SPI of the SD. If there is a race condition between them that could be creating the “random” failures.
First I want to check that both are using the same SPI Speed:
In libraries\Adafruit_HX8357.h I have:
#define SPARK_SPI_SPEED SPI_CLOCK_DIV4
In libraries\SD.cpp
return card.init(SPI_QUARTER_SPEED, csPin) &&
volume.init(card) &&
root.openRoot(volume);
Do I need to change the SPI speed in another location?
Oh yes. That might be the issue.
I think the SD library i am using is DIV4. You might have to go for DIV4 then.
Did you test with SD only first? If you hand soldered, it might be worth taking a look at the joints.
We might have to do more hacking at that library was for Core but it worked somewhat fine on my Photon. The operating frequency is much higher at 120Mhz and the SPI speed division might be causing issues.
@sazp96, @kennethlimcp, as I posted in ANOTHER topic regarding this issue (!!), I have a working SD library for the Photon. I tested successfully with two different microSD breakout. The tests were done with SPI DIV4. Would you like me to share the code? 
So, if the stand-along code (no display, etc) does not work, then it’s an issue with wiring or the display unit design (which I doubt).