Just that SPI1 has no methods when you try and call them in the code. It’s working now with 6.1 and I haven’t changed the code at all.
You’ll need to have the CLI for local flashing, since the desktop IDE currently doesn’t handle wired flashing as far as I’m aware. If you’ve got the CLi, hook up your device in DFU mode and issue
particle flash --usb firmware.bin from the respective directory. Make sure you’ve got the DFU drivers installed though.
That’s basically what I’ve been doing but I figured if I’m flashing locally via CLI I might as well use Atom instead of the web IDE as it does have some useful features. I have had this working before just as a test, but the problems I’m having at the moment are just to do with libs not being included properly. I’m gonna start another project from scratch and see where I’m going wrong.
DHL have just rang up and my new Electron will be arriving tomorrow so it’s been a productive day today.
Hmm, I’m not sure - it shouldn’t be.
The only thing I could imagine is that
loop() might be called less frequently due to cellular connection. But if you use
SYSTEM_THREAD(ENABLED) that influence should get removed from the equation.
I tested this with threading enabled and I can’t really see any difference in performance between Photon and Electron.
Great, I’ll give it a go when I get a chance, I have a replacement Electron now.
I’ve had a PCB made too, the spec for my project is: as small a package as possible containing an Electron, lipo, touchscreen, wireless charging, haptic feedback and piezo. I made the PCB so that it will accept either the resistive or capacitive TFT and the pinouts are such that it will work with either a Photon or Electron as I realised it might be useful for others.
I’m going to design a 3D printable case too so I might start a thread about it see if anyone else is interested. The end result is a kind of no-fuss / super easy to use smartphone. You could write the firmware to make it do whatever you like.
When using an Electron with a display, one thing to check before finishing your PCB is whether your display would run off the 3.7V provided by the Electron’s Vin pin when you only run on battery.
You might need a buck boost converter then - unless you have other means to power the setup.
Yes it runs fine off 3.3v - 5v
Just a bit of an update on this and it’s just more of the same. I don’t get why I seem to have so many problems with this platform.
The PCBs have arrived and I’m just building a test rig using headers so I can interchange parts.
I had the circuit up and running on a breadboard fine, swapped it over to PCB and it doesn’t work. It’s actually a very simple PCB and really just connects the Particle to the TFT breakout. So I checked all the pin connections with the devices in situ with a meter and everything is as it should be.
I spent some time diagnosing the issue and after an hour or 2 I got it working but essentially nothing had changed. The issue seemed to be intermittent SPI. At some point between trying 2 different Photons and 2 different Electrons, it just started working.
For some reason, half way through one of the Photons started flashing blue. This morning I’ve come to look at it and after re-adding it I now get flashing cyan, then red. So looked up other people with the same issue and it looks like corrupt keys.
So following the instructions to generate/add new keys and the last step… “particle keys send photon.pub.pem” returns the error… “Please provide a filename for your device’s public key ending in .pub.pem” The file is there, I used tab to auto-complete it. so once again I’m at a dead end.
I just don’t get why everything seems to require so much effort. I love a challenge and I’m sure I’ll get there in the end, but sometimes I just want to crack on and work on the solution I’m trying to make and it feels like I spend 90% of my time debugging issues with the platform rather than the app I’m trying to make. Yesterday when I was trying to debug the PCB/SPI issues. 50% of the time I was swapping photons, or resetting them, or adding them because they weren’t connecting to WiFi.
Would love to see the GERBER screenshots for the top and bottom copper layer if that’s shareable.
I would simply switch back to the breadboard setup with the same photon and see if everything works fine. If that’s working fine, there’s probably more to look into for the PCB design.
I have the PCB working now, and putting the photon/electron back on the breadboard also worked. I have an entirely different issue now and that’s neither of the photons will connect to WiFi. Although the Electrons work fine over 2G.
I gave up trying to set new keys on the Photon that was blinking blue yesterday and switched to another. Now this one is blinking blue and I haven’t changed anything since last night.
WiFi and cloud is working because the other 3 Photons I already have setup and working in other projects are woking fine.
That’s why look at the GERBER might give us some clue.
- Does it connect to WiFi when you remove it from the PCB?
- Does it enter blinking blue immediately upon powering up?
- What happens when you place the Photon in Safe mode?
I’ve added a PNG to this post > Electron + touchscreen + haptic + wireless charging
It only started flashing blue once yesterday so I just swapped it out for a different photon and carried on. Now this morning that one has started flashing blue.
After they flash blue, I tried re-adding them via the android app which stopped them flashing blue they now flash cyan, then 1 red. They won’t go back to flashing blue unless I put them in listening mode. I’ve tried a full factory reset and re-add but still just flashing cyan then 1 red.
Tried to re-add the keys but ran into the issue above.
It was the keys, I followed the instructions from a different post about the same issue and they worked…
So now I have both Photons working by updating the keys. BTW this has nothing to do with the PCB I’ve been doing all this with the Photon disconnected from everything.
I thought I’d try out the electron as that’s the ultimate goal for the PCB anyway. However, I now have the same issue with that.
So I’m trying to update the keys on that too except now I have another issue.
If I put the Electron into DFU mode it freezes when I connect the USB cable. Or if I try and put it in DFU when already connected the LED flashes orange once and stops.
I’m not trying to do anything clever here, just drive a TFT breakout with a photon/electron. I’ve not even got to writing any code yet I just spend all my time debugging connection and cloud issues.
In searching for answers I’ve found similar posts of other people having endless connection/key issues. I know they can all be solved but I just don’t get why it feels so flakey.
Also, lets say I get it all working and it stays working long enough to develop the solution. I then package it up and put it into use and one of the keys mysteriously gets corrupted. I’m going to have to recover the device, open it up, plug in the USB, reflash it etc etc.
I’ve already invested loads of time into Particle, I’ve been using Cores since the very first shipment and I really want it to work but I’m honestly at my whit’s end.
Particle has got some safe guards for such issues as the outdated keys and dim D7 LED built into 0.7.0 which should get the first RCs out soon.
Here’s my comments for the issue:
- If you place the Photon in the breadboard without any external connection, powered by microUSB, with tinker firmware, and the blinking blue issue persist then there’s definitely some issue with the hardware itself.
- If the issue is persistent whenever a Photon is attached to your PCB while not having issue on a breadboard, there’s something to examine on the PCB side.
- I would say that looking at the charging coil and it’s proximity to the photon/electron, I will not be surprised if you end up with some wireless connectivity issue + EMC/EMI complication.
- It also looks like the ground plane is filling up the entire PCB (at least that’s what i guessed from looking at a picture and not the gerber). That’s definitely going to introduce connectivity related problems.
This is all with them in breadboards. They haven’t blinked blue again unless I put them in listening mode. However, I can’t get either photo to reliably connect now. If I run key doctor or play around with keys I occasionally get a connection, but once I reset it’s back to cyan/orange. One of them has also disappeared from my list of devices but I can’t add it back via CLI or web IDE as it says a device by that ID already exists. Bizarrely the second electron which I had working won’t connect now but the first (faulty) electron does seem to connect OK, although that has now stopped working again.
The issue of SPI not working if I have the resistive panel connected at boot seems to have been resolved by setting the system to threaded mode. I decided to do this so I could carry on debugging the PCB without a cloud connection and now it just works 100% of the time.
I haven’t added the charging coil yet, I just want to get it working 1 step at a time.
Can you explain, please? I’m no expert and this is my first PCB design. I thought the point of the ground shield was to fill up all the unused space on the PCB to a) provide a shield against EMI and b) make PCB production easier/cheaper. I’ve got all the GNDs tied to that shield but obviously nothing else.
The on-board antenna on a Photon needs clear space around it on the top and bottom in order to function properly. You should not have copper under the antenna portion of the Photon on your board. There is a clear keep out area on the Photon datasheet that shows this:
Ah, that makes sense. As it happens after the Photons started working again (I changed nothing they just started working after being left alone for a few hrs) I did try them in the PCB and they worked fine. I do have them on headers though so they are 10mm or so above the board. I’ve got an electron soldered directly but of course it has an external ant.
I’ll update the PCB and leave some space clear as per the data sheet. Thanks!
EDIT - Just realised this is irrelevant as the photon will be sandwiched between the PCB and TFT breakout anyway so it will require an external ant as per the Electron regardless of the PCB design.
I’ve been working on quite an involved build this last week on both Photn and Electron and I’ve started to see a pattern forming.
The issues I’m having mainly seem to be cloud connection issues, not WiFi / cellular. The project I’m working on has a tft screen that shows the RSSI, cloud connection status and system events, in realtime, so it’s quite easy to get a fell for what’s going on.
At the start of the day everything works fine, devices respond and I can flash via the cloud (using Atom). After reset, they take a second or 2 to reconnect. Even the Electron after it’s initial cold boot is really fast.
Then after a few hours and many OTA and USB flashes and many resets, all the devices start having cloud connection issues. And that’s it I won’t get another successful connection until I leave everything alone for a few hrs.
In the past, this was a massive pain, but now I’m using system thread mode so I can carry on developing offline. However, it doesn’t solve the issue.
It’s like there’s some kind of rate limiting being applied, or my account/cloud connection just goes into meltdown after an hour of flashing.
Can anyone suggest a solution, I’m heavily invested in this project now and I’ve sidestepped the issues for development, but once it’s finished the issue will need resolving.