Port, board and/or hardware

nRF, microbit v2

MicroPython version

MicroPython v1.18 on 2023-10-30; micro:bit v2.1.2 with nRF52833

Reproduction

On v2 microbit. I find machine.time_pulse_us() returns bad values about half the time, for a range of pulse widths.
I have verified the pulse widths with an oscilloscope, there is no (visible) EMC problem.

The problem occur immediately after a power cycle, on a naked board, just USB power, with one crocodile lead between pins 0 and 2. The board has no main.py or boot.py.

# pin 2 is connected to pin 0 with a wire.

from microbit import *
import time, machine

pin2.set_pull(pin2.NO_PULL)
pin2.read_digital()

period=10000

pin0.set_analog_period_microseconds(period)
time.sleep_ms(500)

for a in range(20):
    duty=a**2+1
    pin0.write_analog(duty)
    print('%6i : ' % (duty*period//1024),end='')
    for b in range(8):
        time.sleep_ms(50)  # this is longer than the period, to give the write_analog time to settle
        print('%6i' % (machine.time_pulse_us(pin2,1,80000)),end='')
    print(' ')

Expected behaviour

Expect machine.time_pulse_us() to return the width of the pulse correctly, within some jitter limitations.

Observed behaviour

I measure the pulse width eight times for each different duty cycle.
there is no clear pattern except that the bad values seem to occur mostly beyond 1000 us.

Each line shows the expected pulse width, and eight sequentional time_pulse_us results.

     9 :     10    10     9    10    10     9    10    10 
    19 :     19    20    25    20    20    20    20    10 
    48 :     49    63    50    49    49    50    50    45 
    97 :     98    99    94    25    99   100    99   104 
   166 :    163   168   164   164   168   100   162   163 
   253 :    253   257   251   160   256   252   235   120 
   361 :    361   360   365   160   360   366   220   361 
   488 :    490   340   487   120   488   489   185   488 
   634 :    638   310   637   396    90   633   200   632 
   800 :    802   355   805    95   801   799   150   801 
   986 :    988   285   984    20   988   989   984   988 
  1191 :   1189   134  1191  1191   235  1192  1192   340 
  1416 :   1416    95   375    91   305  1418    75  1418 
  1660 :   1660   165  1660  1665   275   165    74  1660 
  1923 :   1921   185  1925  1923   270  1922    10  1922 
  2207 :   2209   115  2210  2204   220  2210  2209   325 
  2509 :   2508    75   165  2511   210  2511  2511   320 
  2832 :   2832    95  2833  2827   300  2830  2831   260 
  3173 :   3173    10  3173  3177    60  3172   400   225 
  3535 :   3535  3539   340  3468   100  3534  3534   185 
>>> 

Additional Information

On v2 microbit. I find machine.time_pulse_us() returns bad values about half the time, for a range of pulse widths.

The problem will occur immediately after a power cycle, on a naked board, just USB power, with one crocodile lead between pins 0 and 2. The board has no main.py or boot.py.

However, there is a strange dependence on what else has been configured on the board, which I can't isolate:

• Occasionally the board will get through a few hundred tests without a single error
• It always goes wrong (50% bad values) when timing pin8, a clean squarewave motor encoder signal, while the motor is being controlled by PWM on pin15
• when the problem is occurring, unplugging the board does not solve the problem (so it is again powered by USB, nothing connected but the crocodile lead from pin 0 to pin 2)
• with the problem triggered, board alone except for the crocodile lead, stays in this state even if I turn off the output PWM (pin15.read_digital()).
• The same problem happens using pin1 for input, and when using pin2 for output instead of pin0
• The same problem happens with an external 500 us pulse train, so no output PWM is ever configured. Display never used.

This particular problem doesn't seem to happen on the v1 Microbit (MicroPython v1.9.2-34-gd64154c73 on 2017-09-01; micro:bit v1.1.1 with nRF51822)

Code of Conduct

Yes, I agree