# Xenon with Ethernet Feather and TfT display **URL:** \ **Category:** BLE // NFC\ **Tags:** xenon\ **Created:** [May 10, 2019, 6:28am UTC](https://community.particle.io/t/xenon-with-ethernet-feather-and-tft-display/49668 "2019-05-10T06:28:54Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![johnnyfp](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/johnnyfp/32/14738_2.png) [@johnnyfp](https://community.particle.io/u/johnnyfp)\ **Post date:** [May 10, 2019, 6:28am UTC](https://community.particle.io/t/xenon-with-ethernet-feather-and-tft-display/49668/1 "2019-05-10T06:28:54Z")
Trying to get and Adafruit Ethernet Feather working with the Adafruit 3.5"TFT display. I’ve just have a simple sketch which has the Startup FEATURE\_ETHERNET\_DETECTION and nothing else. If I have the Ethernet feather connected on it’s own it works fine. But when I connect the TFT display, all I get is a green flickering status and the last few debug output as below. I’ve moved the TFT CS’s lines from D3,D4,D5 to D6,D7,D8 and have the Feather on D3,D4,D5. Is there another pin I need to re map? ```auto 0000005905 [net.th] TRACE: Added FD61:ECAE:8BB::FF:FE00:FC00 0 0000005906 [net.th] TRACE: OT_CHANGED_IP6_ADDRESS_ADDED 0000005972 [net.th] TRACE: OT_CHANGED_THREAD_ROLE 0000005972 [net.th] TRACE: OT_CHANGED_THREAD_RLOC_ADDED 0000006038 [net.th] TRACE: OT_CHANGED_THREAD_PARTITION_ID 0000006038 [net.th] TRACE: OT_CHANGED_IP6_MULTICAST_SUBSRCRIBED 0000006047 [system.ot] TRACE: IPv6 address was added 0000006105 [system.ot] INFO: Role changed: leader 0000006105 [system.ot] TRACE: RLOC was added 0000006171 [system.ot] TRACE: Partition ID changed 0000006172 [system.ot] TRACE: Thread network data changed 0000006238 [system.ot] TRACE: Subscribed to IPv6 multicast address ``` ---
**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\ **Post date:** [May 10, 2019, 7:46am UTC](https://community.particle.io/t/xenon-with-ethernet-feather-and-tft-display/49668/2 "2019-05-10T07:46:46Z")
I think the problem is that, when using the Ethernet feature on Gen3 devices, you (currently) cannot use any other device on the same SPI interface since you have no control over the Ethernet stack which may at any given time pull its SS pin low either blocking or interfering with your concurrent SPI devices actions. While both of the following conditions should be true for a painless concurrency, I'm not sure whether the Ethernet stack uses SPI transactions and if these transactions are actually blocking concurrent transactions in the Gen3 implementation of SPI. And of course any concurrent library _ **also** _ needs to use transactions. BTW, what do you mean with that? > [@johnnyfp](#): > > I’ve moved the TFT CS’s lines from D3,D4,D5 to D6,D7,D8 There is only _one_ CS line for any given SPI client device. D3/D4 are the actual SPI1 communication lines MOSI/MISO which cannot be moved (unless you are using softSPI) - and where is your SPI clock? And D7 is already connected to the onboard LED which may also interfere with softSPI. ---
**Author:** ![rickkas7](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rickkas7/32/8681_2.png) [@rickkas7](https://community.particle.io/u/rickkas7)\ **Post date:** [May 10, 2019, 9:00am UTC](https://community.particle.io/t/xenon-with-ethernet-feather-and-tft-display/49668/3 "2019-05-10T09:00:54Z")
ScruffR is correct. It’s not currently possible to use SPI reliably on Gen 3 devices in an Ethernet FeatherWing. In theory, if the library uses SPI transactions, the library would take over the SPI bus for the duration of the operation, then release it for other code to use it once the operation is done. Unfortunately, there’s a bug in SPI transactions (0.8.0 through at least 1.2.0-beta.1) where the system and wiring (user firmware) each use a different mutex, thus they’re not actually protected against both using SPI at the same time, causing both to fail. ---
**Author:** ![armor](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/armor/32/18398_2.png) [@armor](https://community.particle.io/u/armor)\ **Post date:** [May 10, 2019, 9:48am UTC](https://community.particle.io/t/xenon-with-ethernet-feather-and-tft-display/49668/4 "2019-05-10T09:48:22Z")
> [@rickkas7](#): > > Unfortunately, there’s a bug in SPI transactions (0.8.0 through at least 1.2.0-beta.1) where the system and wiring (user firmware) each use a different mutex, thus they’re not actually protected against both using SPI at the same time, causing both to fail. Rick, would this possibly apply to Gen2 devices as well as Gen3 - i.e. where 2 slaves are on SPI and controlled with 2 CS pins OR is this just for Gen3 and Xenon with Ethernet Featherwing? ---
**Author:** ![armor](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/armor/32/18398_2.png) [@armor](https://community.particle.io/u/armor)\ **Post date:** [May 10, 2019, 9:50am UTC](https://community.particle.io/t/xenon-with-ethernet-feather-and-tft-display/49668/5 "2019-05-10T09:50:10Z")
Suggest you try either an I2C driven display (not going to be as good or as fast!) or something like the Nextion via the Serial. ---
**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\ **Post date:** [May 10, 2019, 10:33am UTC](https://community.particle.io/t/xenon-with-ethernet-feather-and-tft-display/49668/6 "2019-05-10T10:33:11Z")
> [@armor](#): > > the _ **system** _ and wiring (_ **user** _ firmware) each use a different mutex Which Gen2 device would you expect to use SPI from system firmware opposed to application firmware? I'm not really aware of any instance where Gen1/2 device OS uses SPI. ---
**Author:** ![armor](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/armor/32/18398_2.png) [@armor](https://community.particle.io/u/armor)\ **Post date:** [May 10, 2019, 10:48am UTC](https://community.particle.io/t/xenon-with-ethernet-feather-and-tft-display/49668/7 "2019-05-10T10:48:07Z")
You have answered my question/clarification - only applies to Gen3 where with ethernet enabled the system is using the SPI. Thanks ---
**Author:** ![johnnyfp](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/johnnyfp/32/14738_2.png) [@johnnyfp](https://community.particle.io/u/johnnyfp)\ **Post date:** [May 10, 2019, 8:24pm UTC](https://community.particle.io/t/xenon-with-ethernet-feather-and-tft-display/49668/8 "2019-05-10T20:24:18Z")
Hopefuly this will be remedied in later releases as it will be a show stopper for anything that would like to use both. D2 to D8 is on the short side of the GEN3 board where all the SPI pins are on the long side. And with SPI, you generally don’t have to use the SPI’s CS line to do CS stuff if the device is the master. Both Device on thier own work fine without the other on thier corresponding pins (ANd when I say mapped I just mean rewired on the display board to connect the CS’s from the boart to the alternative pins) What I still don’t understand is why just having the display board plugged in breaks the Ethernet feather. I’ve not yet initialized the User space SPI. Just wondering if there is another pin other than MSOI,MISO and SCK that is still being shared. ---
**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\ **Post date:** [May 10, 2019, 8:34pm UTC](https://community.particle.io/t/xenon-with-ethernet-feather-and-tft-display/49668/9 "2019-05-10T20:34:31Z")
> [@johnnyfp](#): > > And with SPI, you generally don’t have to use the SPI’s CS line to do CS stuff if the device is the master. Not sure what you mean by that. I'm not sure what can be considered _generally_ with SPI. I'd think _generally_ SPI was intended as a multi slave interface and thus CS/SS is _usually_ required with the _exception_ that you can omit the use of CS/SS for a bus with only one master and one slave. If you have multiple slaves on the bus (which seems to be the case here - Ethernet _and_ TFT) then the master _must_ use the respective CS or SS line to actively talk to _only one_ device at any given time. Maybe if you can provide a schematic of your setup and the code you use we might understand your issue better.