analogWrite - PWM Problem in IDE-Version 1.8.10

[Nnambles]

There is a Bug in Version 1.8.10 of the Arduino IDE using analogWrite() for PWM on Arduino Mega 2560. If i use analogWrite() with any value for the pwm-Pins once in the loop()-Method everything works fine. If I put a second call of analogWrite() with the same pin and any value that is not 0 or 255, nothing happens. The loop-Method keeps on working, but the PWM-Pin used in analogWrite() shows an continous output of 0V. In Version 1.8.9 the same programm works fine.

[alaqadi]

I discovered the same issue today as I teach Arduino to my students , and a few of them has the issue of when putting a second analogWrite() for a second PWM on the same pin or a different pin, it will case online one PWM signal to appear. This happened on Mega 2560. After testing multiple boards with multiple Oscilliscopes, I was finally to find the reason as I tested one board on a computer that had 1.8.8 and it worked fine. I tried 1.8.11 it had the same problem.
Please fix or remove 1.8.10 and 1.8.11 from the main download page. This is a major bug

[facchinm]

Should be moved to ArduinoCore-AVR and fixed ASAP (although I think it's due to the compiler update more than any core update)

[Rocketct]

Hi all, i made some tests, and i found that:

1. Seems taht as @facchinm sayas the issue does not depend from the core AVR but from the compiler;
2. setting, for the analogWrite, the attribute __attribute__((optimize(**...**))); and giving some properly value to the optimize it is possible make it works properly, i get the following results:

• __attribute__((optimize("-O0")));
  WORKS:
  The sketch use:
  flash: 2332 byte
  ram: 9 byte

• __attribute__((optimize("-01")));
  WORKS:
  Sketch size:
  flash 1964 byte
  ram: 9 byte

• __attribute__((optimize("-02")));
  WORKS
  Sketch size:
  flash: 1830 byte
  ram: 9 byte

• __attribute__((optimize("-0s")));
  NOT WORKS

Sketch size:
flash: 1830 byte
ram: 9 byte

• Without any __attribute__
  NOT WORKS
  Sketch size:
  flash: 1836 byte
  ram: 9 byte

the AVR-Core patch to test it is the following:

diff --git a/cores/arduino/Arduino.h b/cores/arduino/Arduino.h
index 91eeb16..b86496f 100644
--- a/cores/arduino/Arduino.h
+++ b/cores/arduino/Arduino.h
@@ -136,7 +136,7 @@ void digitalWrite(uint8_t pin, uint8_t val);
 int digitalRead(uint8_t pin);
 int analogRead(uint8_t pin);
 void analogReference(uint8_t mode);
-void analogWrite(uint8_t pin, int val);
+void analogWrite(uint8_t pin, int val) __attribute__((optimize("-O0"))); unsigned long millis(void);
 unsigned long micros(void);

[matthijskooijman]

Can anyone post a short example sketch that shows the problem, along with a description of what (incorrect) output it shows?

[Rocketct]

yes sure:

void writeTest(int a) {
  analogWrite(3, a);
  delay(5000);
}

void setup() {
}

void loop()
{
  writeTest(128);
  writeTest(64);
}

if you check the output of the pin 3 with an oscilloscope, the correct output should be two PWM wave were in the first you have the 50% of the duty cycle and in the seconds the 25%, (two different square wave in other words), in the incorrect case the pin 3 doesn't show any activities

[matthijskooijman]

@Rocketct And can you also describe the output you get when you run this particular sketch?

[Rocketct]

yes sorry added on the previous comment let me know if clear 😄

[matthijskooijman]

@Rocketct, Thanks, perfectly clear. I have tried your sketch and looked at the generated machine code, which actually looks to be correct. I don't have an Arduino at hand right now to check if the same problem occurs for me, though.

What Arduino did you test this with?

[PaulStoffregen]

I can confirm the problem happens with Arduino Mega using Arduino IDE 1.8.12.

However, Arduino Uno seems to be unaffected. I got PWM output in pin 3 with the code as shipped.

[PaulStoffregen]

On Arduino Mega, I see this on pin 3:

and upload again with this with this in Arduino.h:

void analogWrite(uint8_t pin, int val) __attribute__((optimize("-O0")));

I get this on pin 3:

[PaulStoffregen]

Here's how I tested (an old clone ... sorry, the only Mega board I have...)

[matthijskooijman]

Ah, confirmed here: Uno works, Mega is broken. Gotta run now, I hope to look at the assembly again in the next days.

[matthijskooijman]

I had a look at the generated assembly. Most is similar, except that the analogWrite has a jump table rather than nested branches to select between the different timers (probably because the mega has more timer pins). I originally thought the jump table handling was messed up (wrong RAMPZ value), but while annotating the assembly below, I realized it did seem correct after all. In any case, below is the assembly (comments with # added by me):

0000031e <analogWrite.part.0.constprop.2>:
# Note that the pin number is constant propagated, only the val is passed in r24
void analogWrite(uint8_t pin, int val)
 31e:   9c 01           movw    r18, r24
                switch(digitalPinToTimer(pin))
# This loads the timer value from a progmem table (item inside the table is at 0x01A7)
 320:   e7 ea           ldi     r30, 0xA7       ; 167
 322:   f1 e0           ldi     r31, 0x01       ; 1
 324:   e4 91           lpm     r30, Z
 # This checks for NOT_A_TIMER or similar, and jumps to 0x48c which handles that case
 326:   e1 50           subi    r30, 0x01       ; 1
 328:   e2 31           cpi     r30, 0x12       ; 18
 32a:   08 f0           brcs    .+2             ; 0x32e <analogWrite.part.0.constprop.2+0x10>
 32c:   af c0           rjmp    .+350           ; 0x48c <__LOCK_REGION_LENGTH__+0x8c>
# This is the jump table part. It takes the value returned by digitalPinToTimer(pin)
# (r30), extends it to r30:r31:r24 (little-endian, and adds 0x19c (by
# subtracting 0xfffe64, which wraps
# around to add 0x19c, which is half of 0x338 which is where the jump table
# starts). tablejump2 below then doubles this value, so it ends up looking
# at 0x338 + 2*digitalPinToTimer(pin), which makes sense since the jump table
# starts at 0x338 and each entry is 2 bytes (note that a timer 0 is invalid, so
# the table actually starts at 0x338 + 2).
 32e:   f0 e0           ldi     r31, 0x00       ; 0
 330:   88 27           eor     r24, r24
 332:   e4 56           subi    r30, 0x64       ; 100
 334:   fe 4f           sbci    r31, 0xFE       ; 254
 336:   8f 4f           sbci    r24, 0xFF       ; 255
 338:   ef c1           rjmp    .+990           ; 0x718 <__tablejump2__>
# This is the jump table, the first entry for digitalPinToTimer(pin) == 1
# This jumps to 0x01af (word address, so byte address 0x35e) which seems sane
 33a:   af 01           movw    r20, r30
 33c:   b4 01           movw    r22, r8
 33e:   b9 01           movw    r22, r18
 340:   c3 01           movw    r24, r6
 342:   cd 01           movw    r24, r26
 344:   46 02           muls    r20, r22
 346:   d7 01           movw    r26, r14
 348:   df 01           movw    r26, r30
 34a:   e7 01           movw    r28, r14
 34c:   f1 01           movw    r30, r2
 34e:   fb 01           movw    r30, r22
 350:   05 02           muls    r16, r21
 352:   14 02           muls    r17, r20
 354:   1e 02           muls    r17, r30
 356:   46 02           muls    r20, r22
 358:   28 02           muls    r18, r24
 35a:   32 02           muls    r19, r18
 35c:   3c 02           muls    r19, r28

# The jump table ends here, and this is the first case handler
                        case TIMER0A:
                                // connect pwm to pin on timer 0, channel A
                                sbi(TCCR0A, COM0A1);
 35e:   84 b5           in      r24, 0x24       ; 36
 360:   80 68           ori     r24, 0x80       ; 128
                                OCR0A = val; // set pwm duty
 362:   84 bd           out     0x24, r24       ; 36
 364:   27 bd           out     0x27, r18       ; 39
 366:   08 95           ret
# This function continues with more case handlers
...

00000718 <__tablejump2__>:
 718:   ee 0f           add     r30, r30
 71a:   ff 1f           adc     r31, r31
 71c:   88 1f           adc     r24, r24
# I suspect this is the RAMPZ register, which contains the upper bits for a
# > 16bits elpm (should be 0 here)
 71e:   8b bf           out     0x3b, r24       ; 59
 720:   07 90           elpm    r0, Z+
 722:   f6 91           elpm    r31, Z
 724:   e0 2d           mov     r30, r0
 726:   19 94           eijmp

I guess this either needs some debug prints (to read back various register values) or a JTAG debugger to verify what parts are correct and where the problem starts (or looking at the asm more closely and really verifying that all the values are correct). I probably won't have more time for this soon, though.

[matthijskooijman]

Also, it might be useful to run with -fno-jump-tables to see if that also prevents the problem.