Sad news Bill,
The radio and TFT now use "BAT" for power and nothing is drawing 3v from the itsy. But I had the exact same issue: It runs for a short time then locks up with the TFT sometimes going all white. Absolutely no difference.
I also have problems downloading code sometimes - I'm guessing the boot loader gets corrupted when it goes off into the weeds. I had to power cycle the board before I could upload more code (and I'm a little perplexed that this worked). I uploaded a file with nothing in setup() and loop() butthe Dotstar was a solid purple color. Anyway, this is a side issue.
So I snipped all the connections to all the pins on the itsy. Had to power cycle a couple times but I can now load code onto it and make the Dotstar led do it's normal tricks etc. The itsy seems to be working.
Whatever the issue is, it looks like it can corrupt the bootloader. I'm surprised that power cycling it fixes my ability to upload code but it does.
I'm going to start over. Maybe I had a solder bridge somewhere. I have no idea.
Can you tell me, is it possible my itsy is corrupted? Should I toss it?
And what about the tft/radio issue. If I breadboard a whole new board, should I use new parts? ($$$$$)
All I want for Christmas is to resolve this!!!
Multiple SPI devices cause code to jump into the weeds
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- TomHumbleAndHandsome
- Posts: 99
- Joined: Mon Feb 15, 2021 6:38 pm
- TomHumbleAndHandsome
- Posts: 99
- Joined: Mon Feb 15, 2021 6:38 pm
Re: Multiple SPI devices cause code to jump into the weeds
Maybe its the itsy.
I left the itsy running in a tight loop; it's flashing the Dotstar every 500mS.
After some time, it just stopped. No light flashing.
This happened twice: once after an hour, once after just 10 minutes. Each time my laptop (that was providing power through the USB) made a beep sound like I was connecting something to the USB port.
So whatever else was going wrong, I think my itsy is trashed. Please comment on whether this is expected when running on a laptop-powered USB connection or if it's an indication of a bad itsy.
Thanks
I left the itsy running in a tight loop; it's flashing the Dotstar every 500mS.
After some time, it just stopped. No light flashing.
This happened twice: once after an hour, once after just 10 minutes. Each time my laptop (that was providing power through the USB) made a beep sound like I was connecting something to the USB port.
So whatever else was going wrong, I think my itsy is trashed. Please comment on whether this is expected when running on a laptop-powered USB connection or if it's an indication of a bad itsy.
Thanks
- TomHumbleAndHandsome
- Posts: 99
- Joined: Mon Feb 15, 2021 6:38 pm
Re: Multiple SPI devices cause code to jump into the weeds
This gets more interesting by the minute.
My itsy rebooted when I stood up to leave the room. That's when it did the last time too. I'm not touching it or moving anything near it so the only thing I can think of is static electricity.
So............ That is yet another thing I have to consider. But it could explain much of this weird bug.
HOW do I go about:
1. Testing to see if I have a static electricity problem
2. Fixing it!
My itsy rebooted when I stood up to leave the room. That's when it did the last time too. I'm not touching it or moving anything near it so the only thing I can think of is static electricity.
So............ That is yet another thing I have to consider. But it could explain much of this weird bug.
HOW do I go about:
1. Testing to see if I have a static electricity problem
2. Fixing it!
- adafruit_support_bill
- Posts: 88093
- Joined: Sat Feb 07, 2009 10:11 am
Re: Multiple SPI devices cause code to jump into the weeds
At this point it is sounding like possibly a flakey Itsy. When did you purchase it?
- TomHumbleAndHandsome
- Posts: 99
- Joined: Mon Feb 15, 2021 6:38 pm
Re: Multiple SPI devices cause code to jump into the weeds
About 4 weeks ago. Would a flakey itsy be more sensitive to static electricity? It seems pretty consistent that when I stand from my chair and walk out of the room, it reboots or completely goes into the weeds.
- adafruit_support_bill
- Posts: 88093
- Joined: Sat Feb 07, 2009 10:11 am
Re: Multiple SPI devices cause code to jump into the weeds
Any processor can be affected by static. But one that is marginal could well be more sensitive.
Please contact [email protected] with a link to this thread and request a replacement.
Please contact [email protected] with a link to this thread and request a replacement.
- TomHumbleAndHandsome
- Posts: 99
- Joined: Mon Feb 15, 2021 6:38 pm
Re: Multiple SPI devices cause code to jump into the weeds
Ok thanks Bill.
Once I replace it and try this all again, I'll be back to let you know how things worked out.
Thanks for your help.
Tom
Once I replace it and try this all again, I'll be back to let you know how things worked out.
Thanks for your help.
Tom
- TomHumbleAndHandsome
- Posts: 99
- Joined: Mon Feb 15, 2021 6:38 pm
Re: Multiple SPI devices cause code to jump into the weeds
Took several steps back and discovered some things about the issue I’m having.
I want to know if you think my chip select lines for my SPI devices need pull up resisters so they will “snap back” to the deselected state after use. If so, can you advise how to do that, I’m not comfortable just hacking hardware. The rest of this post explains why I think I need them.
The simplest version of “loop()” code I can show you that makes the error is just 3 lines:
rf69_manager.available(); // sends SPI message to radio
tft.setCursor(0, 100); // sends SPI message to TFT
tft.print(++heartBeat); // sends SPI message to TFT
if I comment out the first line and only send messages to the TFT, it works correctly.
If I leave the first line uncommented, it goes into the weeds in under a minute
We’ve gone down a lot of dead ends but I’ve eliminated them one at a time.
The following are NOT the cause of this error:
* TFT hardware – I replaced it with another TFT and have the exact same issue
* Radio hardware – I replaced it with another radio and have the exact same issue
* ItsyBitsy M0 hardware – I replace it with another M0 and have the exact same issue
* is SPI compatible with M0??? - I replaced Itsy M0 with 32u4 and have the exact same issue
The only way I can make the 3 line program work is to put a delay between the radio SPI communications and the TFT SPI communications. BUT the delay has to be 3 seconds long!
I want to know if you think my chip select lines for my SPI devices need pull up resisters so they will “snap back” to the deselected state after use. If so, can you advise how to do that, I’m not comfortable just hacking hardware. The rest of this post explains why I think I need them.
The simplest version of “loop()” code I can show you that makes the error is just 3 lines:
rf69_manager.available(); // sends SPI message to radio
tft.setCursor(0, 100); // sends SPI message to TFT
tft.print(++heartBeat); // sends SPI message to TFT
if I comment out the first line and only send messages to the TFT, it works correctly.
If I leave the first line uncommented, it goes into the weeds in under a minute
We’ve gone down a lot of dead ends but I’ve eliminated them one at a time.
The following are NOT the cause of this error:
* TFT hardware – I replaced it with another TFT and have the exact same issue
* Radio hardware – I replaced it with another radio and have the exact same issue
* ItsyBitsy M0 hardware – I replace it with another M0 and have the exact same issue
* is SPI compatible with M0??? - I replaced Itsy M0 with 32u4 and have the exact same issue
The only way I can make the 3 line program work is to put a delay between the radio SPI communications and the TFT SPI communications. BUT the delay has to be 3 seconds long!
- TomHumbleAndHandsome
- Posts: 99
- Joined: Mon Feb 15, 2021 6:38 pm
Re: Multiple SPI devices cause code to jump into the weeds
In my previous post, I thought maybe the CS lines were not deselecting fast enough so I manually deselect them and immediately record if they have changed, and they have. The CS lines are working correctly. I used this code:
digitalWrite(TFT_CS, HIGH); // deselect TFT
while (digitalRead(TFT_CS) != HIGH)
Serial.print("*");
I'm finally out of ideas. It seems that the TFT and RADIO cannot be used on the same project because one or both of them don't work correctly. I'm disappointed. I can think of a lot of projects where I wanted to use both a radio and a TFT.
digitalWrite(TFT_CS, HIGH); // deselect TFT
while (digitalRead(TFT_CS) != HIGH)
Serial.print("*");
I'm finally out of ideas. It seems that the TFT and RADIO cannot be used on the same project because one or both of them don't work correctly. I'm disappointed. I can think of a lot of projects where I wanted to use both a radio and a TFT.
- adafruit_support_bill
- Posts: 88093
- Joined: Sat Feb 07, 2009 10:11 am
Re: Multiple SPI devices cause code to jump into the weeds
I don't have any first-hand experience with that exact combination of devices. But I'm consulting with some of the other engineers to see if they have any insights.
- adafruit2
- Posts: 22148
- Joined: Fri Mar 11, 2005 7:36 pm
Re: Multiple SPI devices cause code to jump into the weeds
iirc the RadioHead library doesnt handle interrupts and SPI nicely. are you using IRQs?
- TomHumbleAndHandsome
- Posts: 99
- Joined: Mon Feb 15, 2021 6:38 pm
Re: Multiple SPI devices cause code to jump into the weeds
I use the G0 (G zero) output on the radio to Itsy pin 1.
Is there an alternative to using an interrupt?
Come to think of it, I'm not sure how an interrupt service routine could check to see if another SPI device was operating anyway.
The display doesn't have an ISR, I don't think so anyway. So there's got to be a way!
- adafruit2
- Posts: 22148
- Joined: Fri Mar 11, 2005 7:36 pm
Re: Multiple SPI devices cause code to jump into the weeds
yeah the IRQ code of the radio may be messing with the SPI port and it isnt written interrupt friendly. you could put the TFT on other pins so they are not shared, you can try non-hardware-SPI config to start, see if that helps
- TomHumbleAndHandsome
- Posts: 99
- Joined: Mon Feb 15, 2021 6:38 pm
Re: Multiple SPI devices cause code to jump into the weeds
12/24:
I used the SoftSPI library with different pins for SCK, MOSI and MISO. It's been running for half an hour with absolutely no issues at all. I can't break it!
So now we can say without any doubt, the issue is confined to either the Radiohead or Adafruit_ILI9341 libraries.
But as far as I'm concerned, I have two semi-acceptable work-arounds.
1. use the SoftSPI library which is incredibly slow btw or
2. use 8 bit wiring for the TFT - I'm not sure if I have the pins available though
So how do we proceed from here? Can we assume Radiohead is aware of the issue? Will they notify anyone here if/when there's a fix? How can I be kept informed?
Thanks for you help Bill, it was a struggle but you came up with the solution.
- adafruit2
- Posts: 22148
- Joined: Fri Mar 11, 2005 7:36 pm
Re: Multiple SPI devices cause code to jump into the weeds
aweomse! yeah, radiohead isnt super maintained. i think they know about the SPI transaction issue - we use transactions on the TFT libraries but some old libraries do not.
another thing is if you are using a M0 is you can create another SPI port on a SERCOM set separate (e.g. called SPI1) and then use that for the TFT
https://learn.adafruit.com/using-atsamd ... rial-ports
another thing is if you are using a M0 is you can create another SPI port on a SERCOM set separate (e.g. called SPI1) and then use that for the TFT
https://learn.adafruit.com/using-atsamd ... rial-ports
Please be positive and constructive with your questions and comments.