• Hi.

    I am using the Espruino WiFi board to control an "L298N Dual H-Bridge Stepper Motor Driver Board".

    I want to control the speed of each motor independently, so I decided to apply a different PWM signal to the motor speed control pins "EnA" and "EnB".

    I randomly chose two pins on the the Espruino WiFi, which are both documented as PWM-capable: A0 and A7.

    But when I use the following commands to set the speeds of the 2 motors they run at different speeds.
    analogWrite(A0,0.5, {freq:500});
    analogWrite(A7,0.5, {freq:500});

    If I use only A0 as the control input to EnA and EnB then the motors run at identical speeds.

    Am I misinterpreting the PWM features of the Espruino WiFi board?


  • Hi,

    What you're doing there sounds fine - and I just tried it on a Wifi board attached to an oscilloscope and the result is just as you'd expect. However because it's using two separate PWM channels the two signals are out of phase.

    You have 4 channels on the L298N - OUT1...4. OUT1+2 are connected to EnA, and OUT3+4 are EnB.

    Is it possible that you have actually wired one motor to OUT1+3 and one to OUT2+4 or something like that? In that case each motor would be controlled by both enables and the fact that the two enables were out of phase might change things.

    If you're not sure, you could try slowing the frequency right down to 1Hz or so and attaching LEDs to the outputs so you can get some idea what's going on?

  • Hi Gordon.

    Thanks for the quick reply.

    The diagnostic LED + slow frequency sounds like a good idea. I will try that out.


  • Okay, time for some feedback.

    After spending 2 days experimenting with various hardware configurations and code implementations, and questioning my sanity, I have discovered that using pin A0 does not give me any discernible PWM output variation on my LED, but when I eventually gave up on pin A0 and switched to using pin A7 everything started working as expected.

    Since I don't have an oscilloscope (yet) I am unable to do any additional diagnostics, all I can say is that, with exactly the same code, the A0 pin either turns the LED or motor fully on or fully off, yet pin A7 give me the expected PWM variation.

    For example, if I use the following code and ramp the value of the 'speed' variable from 0.1 to 0.9 over a few seconds then the LED turns fully on or off at 0.1.
    analogWrite(A0,speed, {freq:500});

    But if I use the same code on pin A7 then the LED and motor ramp up exactly as expected.
    analogWrite(A7,speed, {freq:500});

  • I might have answered my own question.

    I have a setwatch enabled on 'BTN', and according to the setwatch documentation it appears that pin A0 may be affected by the setwatch command?

    Is that maybe the reason for my A0 PWM problem?

    Update: it seems that the setwatch command is not the cause of my problem. Even after removing the code there was no improvement in the PWM behaviour of pin A0

  • Ok, at least we're getting somewhere!

    Can you turn an LED attached to pin A0 on and off manually with digitalWrite? And what does getPinMode(A0) report?

    If you power on the board and run just the two analogWrite lines:

    analogWrite(A0,0.5, {freq:1});
    analogWrite(A7,0.5, {freq:1});

    With nothing connected to the board apart from 2 LEDs, do the two LEDs flash? Because I'm trying that here now and it's fine - so it sounds like it could be a hardware problem, especially if you can't even use digitalWrite on A0.

  • 1) reset()

    2) analogWrite(A0,0.5, {freq:1});
    LED flashes on for half a second and then off for half a second and then remains on.

    3) analogWrite(A0,0.1, {freq:1});
    LED stays on

    4) analogWrite(A0,0, {freq:1});
    LED switches off

    5) >getPinMode(A0)

    6) digitalWrite(A0, 1);
    LED turns on.

    7) digitalWrite(A0, 0);
    LED turns off.

    8) getPinMode(A0)

    6) analogWrite(A7,0.5, {freq:1});
    LED flashes on and off for half a second and continues to flash as expected.

    7) getPinMode(A7)

  • Hi Gordon

    In order to keep my project moving I am just going to switch to using ports A7 and B1, those two ports are fine. It is just A0 that is acting flaky, but if you need me to keep testing various scenarios I will do so.


  • Thanks for trying that out - that's extremely strange behaviour as that first line on mine works perfectly (it just keeps flashing).

    Does that even happen after a hardware reset (full power down and up)? Your behaviour is almost as if the hardware timer for that PWM output never rolls over.

    Which firmware do you have installed on your board? You can check with process.version.

    What's displayed if you type dump()?

    Also, does analogWrite(A0,0.5, {freq:1,forceSoft:true}); work for you? That'll use software PWM based on interrupts.

    Which country are you in? I'd be happy to exchange your board for one that I know works perfectly if we can't figure out what's up.

  • 1) process.version

    (I previously did a reset()/save())

    3) analogWrite(A0,0.5, {freq:1,forceSoft:true});
    This works perfectly

    4) A full power cycle doesn't make a difference.

    Thanks for the offer, but a replacement isn't necessary. I was just worried that I was doing something wrong. I will just switch to using other ports, or use the 'forceSoft' option where necessary.

    Thanks for your time and effort in helping me to resolve the issue.


  • Hi, no problem - thanks!

    You definitely weren't doing anything wrong - what you did should have worked fine.

    Out of interest, do you get similar issues on A1? It uses TIM5 which'll be the same timer as A0 (just a different channel).

    Interestingly I just tried a second Espruino WiFi board (that had some Wifi code on it), did a reset(), and I got exactly the same problem. However after a save() and a power cycle it fixed itself. Now I can't reproduce it, even by uploading the code I had on it before!

    You might find that just re-flashing the Espruino 1v93 firmware helps you out, as that would definitely clear out anything at all that might have been left in flash?

    If anyone finds out how to reproduce this, please let me know! If I can reliably reproduce it I can get it fixed.

  • My apologies, it turns out that I was mistaken.

    After doing a reset()/save() and then a power cycle, pin A0 works perfectly with this command;
    analogWrite(A0,0.5, {freq:1});

    When I stated that a power cycle didn't help I was referring to all previous cases, where I had done a reset(), but not a save(), before cycling the power.

    Interestingly I am running wifi code as well, so it could very possible be related to the wifi system.


  • In my case the problem isn't the WiFi code.

    I spent some time adding comments to my code until I isolated the lines that triggered the problem;

    Line 3 was the culprit (I included the rest of the SPI configuration commands in case they are relevant)

    var spi = new SPI();
    spi.setup({mosi: B6 /* D1 */, sck:B5 /* D0 */});
    oled = require("SH1106").connectSPI(spi, B8 /* DC */, B7 /* RST - can leave as undefined */, screenReady);
  • That's amazing - thanks! I managed to reproduce it!

    In fact, by copying in all the code and then deleting stuff I got it down to this:

    analogWrite(A0,0.5, {freq:1});

    And I can reproduce it on the Pico and WiFi boards too - this is a really big issue and I'm amazed that nobody has noticed this before.

    Basically the utility timer (used for soft PWM, digitalPulse, and Waveforms) uses TIM5 too it seems, so TIM5 should have been taken out of the list of available timers - but it wasn't.

    It's getting late here but I'll make sure I sort this out first thing next week.

  • I'm glad that you have solved the mystery.

    I hope that I was of some assistance, although all I really did was complain :-)

  • You didn't just complain though - coming up with a simple, reproducible way to get the error is often 90% of the way to getting the problem solved. If you hadn't posted the code above, I wouldn't have been able to figure out what was wrong :)

    Anyway, now I know the issue - basically A0/A1/A2 are affected whenever digitalPulse/Waveforms/soft PWM are used. Other PWM outputs are fine.

    However that should all get fixed on Monday/Tuesday.

  • Ok, it's all fixed now! Just copy/paste the URL of the wifi's .bin file from http://www.espruino.com/binaries/travis/¬≠master/ into the 'advanced flash' option in the IDE and you'll be sorted - or I should be doing a proper 1v94 release soon as well.

  • Awesome.


  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

analogWrite to pins A0 and A7 produce different outputs

Posted by Avatar for Frank @Frank