Servos on RX and TX stop working

Hi Everyone,

Last weekend I moved one of my bigger projects from the Core to the Photon. All went well except for a non-working servo on what is now the DAC pin on the photon. Easily fixed I thought and moved the servo input to WKP. This worked the first time but stopped working after waking up from Deep Sleep. So I thought it’s probably something to do with Deep Sleep grabbing WKP to act as the wakeup pin. Moved servo to RX and finally TX. Both these pins made the servo behave intermittently and/or with long delays.

I ran across this post

Similar to my situation but not clearly solved. So I spent the last couple of days trying to come up with something to make this behaviour repeatable and simple to demonstrate. This is what I’ve come up with.

This may be something for either @peekay123 or @ScruffR but all are welcome to try.

To show the strange behaviour you need;

  1. A Photon running 0.4.5 firmware

  2. A servo like the one that comes with the maker kit

  3. The following code

    #define ledblue D7
    #define servocontrol_1 RX //TX also shows the same behaviour


    Servo servo_1;

    void setup() {

    pinMode(ledblue, OUTPUT);


    void loop() {

    // Flash blue LED slowly while waiting for wifi.ready flag
    while (!WiFi.ready()){

     digitalWrite(ledblue, HIGH);    
     digitalWrite(ledblue, LOW); 




    // Flash blue LED quickly while waiting for the pariticle.connected flag
    while (!Particle.connected()){

     digitalWrite(ledblue, HIGH);    
     digitalWrite(ledblue, LOW);



    for(int i=0; i<=10; i++) {


Connect your servo signal line to RX, flash the code OTA and watch the servo move one way then the other way and then wag back and forth just like it should.

Then make one change, un-comment the SYSTEM_MODE(SEMI_AUTOMATIC) line, flash and watch the servo.

This time the servo may or may not move, during the wag section it should move back and forth with each flash of the blue LED. The LED flashes but the servo may only move 2 or three times not the ten times as it did with SYSTEM_MODE(SEMI_AUTOMATIC) commented out.

I can make the servos make all the moves if I increase the delays after the Servo_1.Write statements to something in the neighbourhood of 3000 to 5000. Waiting 3 to 5 seconds for the servo to react isn’t normal but may point to where to problem is.

If you attach the servo to the WKP pin and your Photon goes into a Deep Sleep cycle then the servo never gets re-attached to the WKP pin when it wakes up.

I don’t know what is causing this but thought this might help the team in troubleshooting this anomaly. All other PWM pins behave as they should with this code.

As a secondary item, you may notice that the blue LED does not flash during the wait for the wifi.ready flag. It did when running on the Core. I’m assuming this is because WiFi.connect is now blocking. Is that correct? Of have I messed up the code somehow that I can’t see. (I’m new to C programming)

Thanks for listening, hope this helps in some way.

1 Like

I could imagine, that this comes from the fact, that the Photon (unlike the Core) automatically opens the USB serial port, which might interfere with the PWM.

Maybe @mdma has got something to say to that.
Especially since Serial.end() does make the COM port disappear from my Device Manager, but doesn’t help the servo.

1 Like

To my knowledge, there’s nothing in Serial that should affect TX/RX (Serial1).

The “automatically open serial port” functionality I want to make configurable going forward so that it’s easy to specify the baudrate in the app or via DFU.

Doh’ :flushed: of course :stuck_out_tongue_winking_eye:
Serial is USB and NOT RX/TX - silly me!

But what’s causing it then??? :puzzled:

I have a similar issue that might be related:

My photon’s RX and TX pins can no longer Ouput after finishing listening mode WiFi configuration. Not only does PWM not work, but I cannot write HIGH/LOW either. Even when I reconfigure the pins as Outputs after exiting listening mode they still do not work. They only start working normally again after hitting the reset button.

Hope this can help.

1 Like

I think this is because there’s part of listening mode that is using Serial1. This is only required during manufacturing so I’ve removed it for the 0.4.6 release.


@mdma I have the same issue with both pins on the v0.7.0 firmware.