Microphone raw output sometimes contains large blocks with value -30584 (0x8888)

[microbit-carlos]

And the ADC buffer is pre-filled with value 0x88 in codal-nrf52/source/NRF52ADC.cpp#L436-L446:

    // Fill the buffer with values unused by the ADC hardware. We can use this to perform demuxing 
    // of a live DMA buffer as it is being filled. :)
    // We choose 0x88 as a 16 bit signed 0x8888 is an invalid 14 bit sample (either +ve or -ve)
    b.fill(0x88);

This has been reported by the team working on the factory test programme, and I've struggled a bit to recreate it in a simple/short programme, but managed to make it easier to trigger when the compiler optimisation level is set to -O0 (or whatever is the default in gcc, as the CMAKE Debug build type doesn't set that flag).

The full example can be found here, as it needs changes to build.py to change the build type:

• branch: https://github.com/lancaster-university/microbit-v2-samples/compare/adc-issue?expand=1
• or commit: lancaster-university/microbit-v2-samples@efec857

The example contains the following:

• Changes the CMAKE build type to Debug, so that optimisations are turned off
• There is a new DataSink connected to the microphone raw output
  • This DataSink simply checks for value -30584 (0x8888) in its pullRequest() and if finds it, it dumps the upstream buffer to serial
• For the issue to trigger, apart from creating an instance of this DataSink, we also have to set the virtual pin PWM output AND execute the getAnalogValue() from a pin.

On a typical run the serial output continuously prints buffers like this:

pullRequest() number 22111:
pullRequest() number 21799:
6289    6301    6296    6306    6305    6284    6290    6275    6289    6320    6300    6294    6308    6306    6287    6285    
-30584  -30584  -30584  -30584  -30584  -30584  -30584  -30584  -30584  -30584  -30584  -30584  -30584  -30584  -30584  -30584  
6294    6299    6309    6273    6284    6311    6308    6303    6315    6306    6290    6308    6284    6285    6302    6312    
6308    6294    6297    6302    6298    6291    6303    6300    6310    6299    6299    6308    6313    6312    6312    6308    

[martinwork]

@microbit-carlos I have experimented with this...

• It still happens with current master
• The 0x8888 values appear in pin data as well as the mic.
• I haven't seen it happen without changing CMAKE build type to Debug
• With CMAKE build type Debug, a panic displays in super slow motion.

This hex debug.zip, was built with GCC 10.2.1 and build type Debug, from this code:

#include "MicroBit.h"
MicroBit uBit;
int main()
{
    uBit.init();
    uBit.panic(123);
    release_fiber();
}