Hello,
I’ve been trying to push a new piece of code to control a TFT display (7735) along with a temperature sensor (DHT22) but when I do the core starts updating and then stars “breathing red”… A slow pulse. Not entirely red, I can’t tell, seems like blue and red at the same time… Anyway, the code doesn’t work and I have to reset the core manually.
I can’t find what this visual clue is about.
thanks for the help
If you have the red and the blue sub-LED lit up in the RGB-LED it’s called magenta.
And is it a fading on/off cycle or more a digital on - off - on cycle?
So you could search the forum or the troubleshooting section of the docs for either “breathing” or “blinking”/“flashing” and “magenta”.
I sometimes had the breathing magenta, when I selected the wrong security setting for my WiFi network (e.g. WEP instead of WAP2).
I’m going to assume you’re trying to flash your new code over the Web IDE(?) Does that give an error perhaps?
That’s a broad definition. Would you mind being a bit more specific? I get that it doesn’t appear to work at all, but do the sub-routines work separately? Can you get the DHT22 to work, independently from the display, and visa versa?
Regardless, would you mind sharing your code? That should make it easier to debug. There are multiple libraries for the DHT22, for which some have proven to be problematic. The Piettetech library seems to be reliable.
I suspected it was Magenta…
It definitely is a fading on/off not blinking. The Wifi seems fine as it picks-up the need for an update and started flashing as if downloading the new firmware. It’s once its done that the problem appears.
In this case, I do agree with @Moors7 - can we see your code please?
And could you try to flash some very simple test code, if your Core does this all the time now, or only with your new code.
If the latter, could you provide a stripped down code, that produces the faulty behaviour?
BTW: SInce it’s magenta, I’d alter your topic title that way, if you don’t mind 
Flashing goes fine (using the Wed IDE correct). No error there.
My code basically takes the DHT22 data (temp + humidity) and sends that to Xively. I got that to work great. No issues.
Then I added the TFT display to display the temp on it, instead of just sending it to Xively. I wired the whole thing to the Spark, then added the “Adafruit_ST7735/Adafruit_ST7735.h” library and a piece of code to test out the display.
Flashing this causes the magenta breathing issue… No updates appear in Xively, hence my conclusion that the code is not working.
here is the relevant code for it:
// This #include statement was automatically added by the Spark IDE.
#include "Adafruit_ST7735/Adafruit_ST7735.h"
// This #include statement was automatically added by the Spark IDE.
// This #include statement was automatically added by the Spark IDE.
#include "Adafruit_DHT/Adafruit_DHT.h"
#define cs A2
#define dc D0
#define rst 0
Adafruit_ST7735 tft = Adafruit_ST7735(cs, dc, rst); // hardware spi
#define DHTPIN 6 // what pin we're connected to
#define FEED_ID "====removed==="
#define XIVELY_API_KEY "====removed==="
TCPClient client;
// Uncomment whatever type you're using!
//#define DHTTYPE DHT11 // DHT 11
#define DHTTYPE DHT22 // DHT 22 (AM2302)
//#define DHTTYPE DHT21 // DHT 21 (AM2301)
// Connect pin 1 (on the left) of the sensor to +5V
// Connect pin 2 of the sensor to whatever your DHTPIN is
// Connect pin 4 (on the right) of the sensor to GROUND
// Connect a 10K resistor from pin 2 (data) to pin 1 (power) of the sensor
DHT dht(DHTPIN, DHTTYPE);
int ledD = D7;
void setup() {
//Serial.begin(9600);
//Serial.println("DHTxx test!");
dht.begin();
tft.initG();
tft.fillScreen(ST7735_BLACK);
tft.setCursor(0, 0);
tft.setTextColor(ST7735_WHITE);
tft.setTextWrap(true);
tft.print("Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur adipiscing ante sed nibh tincidunt feugiat. Maecenas enim massa, fringilla");
tft.drawLine(0, 0, tft.width()-1, tft.height()-1, ST7735_YELLOW);
tft.drawLine(tft.width()-1, 0, 0, tft.height()-1, ST7735_YELLOW);
tft.drawPixel(0, tft.height()/2, ST7735_GREEN);
}
void loop() {
// Wait a few seconds between measurements.
delay(2000);
==== code removed - irrelevant =====
}
Just a quick stab in the dark
Try to alter this
Adafruit_ST7735 tft = Adafruit_ST7735(cs, dc, rst); // hardware spi
//into
Adafruit_ST7735 tft(cs, dc, rst); // hardware spi
A similar change once removed a build error in one of my projects - no idea why, but ever since, I’m doing it this way 
And you should also change dc and rst since 0 is the same as D0.
And as @Moors7 suggested, I’d also go for the PietteTech_DHT library - I’ve had blocking problems with the one you’re using.
@ScruffR Will try your changes.
Actually the rst and dc is something that bothered me and I wonder if the issue doesn’t come from this… I have the Reset pin of the TFT connected to the RESET Pin of the Spark… I also have the A0 Pin of the TFT to the D0 of the Spark…
I’ll try tonight, but I wonder if the “rst 0” definition is correct…
The reset pin of the Core is for you to reset the Core by pulling it LOW via a switch or some other hardware, and the rst pin of the TFT is for the Core to reset the TFT by pulling it LOW.
Sometimes you might want to only reset the TFT without the need to restart the whole Core, so I’d rather go for some pin that you can control from your program.
What do you mean with the A0 pin of the TFT? Which board are you using?
The Adafruit board I know (http://www.adafruit.com/products/358) doesn’t seem to have such a pin.
This is the TFT I use: http://www.ebay.com/itm/1-8-Serial-128X160-SPI-TFT-LCD-Module-Display-Screen-PCB-Adapter-w-SD-Socket-/200764741074?pt=LH_DefaultDomain_0&hash=item2ebe82d5d2
I didn’t buy it from Adafruit. One of the port is called A0 (can’t remember at the top of my head what it is used for)…
Without actually knowing, I’d say the display is I2C and the A0 pin is to choose one of possibly two I2C addresses the display can use.
By looking at the pinout diagram, I’m not sure if the SPI isn’t only used for the SD card slot.
Have you also read the bit about shorting JP1 to use the display at 3V3 (supply power) but leave it open if you power it off Vin (5V)?
I had some strange behaviors with the Vin in fact. I plugged the Pin+ of the TFT to the 3V3, but if I put the VCC pin of the TFT to the Vin of the Spark, the Spark will shut down after a few seconds… (Led off). So I ended up plugging the VCC of the TFT to 3V3 as well…
I will post my exact wiring tonight.
Ok. I did remove the reset link from the TFT and put it on D5 (changing the definition as well).
I also changed the object tft instanciation as you suggested.
Result: no more magenta… I think it is more due to the Reset wire honestly.
Now I still don’t have anything showing up on the display but at least I get some output in Xively which means it’s communicating.
My wiring is:
display SDK -> A3 Spark
display SDA -> A5 Spark
display CS -> A2 Spark
display RST -> D5 Spark
display VCC -> Vin (5V) Spark
display LED+ -> 3V3 Spark
LED- and GND -> GND
I haven’t wired the SD card, but when I do I think it will be:
SD SCK -> Display SCK (-> A3 Spark)
SD MOSI -> display SDA (-> A5 Spark)
SD MISO -> A4 Spark
SD CS -> D1 Spark
Not sure about the shorting JP1… Would I have to solder the jumper for that???
Yeah, the result is usually the same, but how they get there is subtly different!
Adafruit_ST7735 tft = Adafruit_ST7735(cs, dc, rst);
This one creates 2 objects - first a temporary (the one on the right side of =) and then the value of this temporary is used to assign the object on the left (which has been created using the default constructor.)
Adafruit_ST7735 tft(cs, dc, rst);
This avoids the creation of temporary objects and instead directly creates the object by calling the 3 argument constructor.
I hope that helps! 
@apassemard, since I do suspect that your board connects the display via I2C (despite the product description), I’m not surprised that you don’t see a thing
I haven’t had a look at the lib (if it supports I2C), but if it is I2C you’d have to connect the TFT to D0/D1 rather than A3/A5.
This would also require to move the SD’s CS over to A2 and the TFT CS to something like D2.
About JP1 it is a solder jumper, but if you do connect it, make sure never to apply 5V to Vcc.
But if you can get the display running with 5V, this is probably the saver bet, and you could still use it with 5V Arduino too.
Have you got the datasheet of the board downloaded? That should settle the I2C vs. SPI question.
Having a look at the datasheet it turns out, that it isn’t I2C, but the board supports 3- or 4-wire SPI, so forget everything I said about I2C : 
I did let myself be led astray merely by the pin descriptions of the PCB silk - should have looked at the datasheet first .
So, now I think you were right using the TFT A0 pin as D/C pin and wire it with the Core’s D0.
If you’re using TFT & SD in parallel, you have to make sure, you keep both CS lines active (HIGH), mutually exclusive.
Since the original issue is solved, it might be good to mark this as [Solved] and carry on with the TFT issue in a dedicated thread.
Yes I agree the initial issue is solved. It was due to the wiring of the reset pin of the board to the reset pin of the Spark which (for some reason) doesn’t make the system happy. I moving the wiring to another pin like D5 or whatever took care of the trouble…
Thanks for the update 
Just to make sure, this was the actual reason, could you do some “negative” tests, if the problem is comming back undoing this?
Since there were two actions taken at the same time, where either or the combination of them might have solved the issue, it would be good to definetly pin it down to what it actually was.
Edit: Just seen in the other thread, that you have already confirmed the RST as the actual cause
Without changing anything, if I wire the RST from the TFT to the Reset pin of my core, it will go into breathing magenta and stop working. If I wire and put the Reset from the TFT to another pin (D5 for example), I get a nice breathing cyan and communication with the cloud. So I confirm, the issue came from the wiring. I’m not clear what caused it though but that’s the behavior.