MKRZERO USB only working intermittently

[ryancog]

Hi, I've got an MKRZERO board that I've started using recently after replacing its SAMD21 and burning the bootloader, but now I've got another issue... the board hardly ever shows up on the computer. It seems incredibly inconsistent, but whenever the USB connects, I can open up the Serial Monitor and see everything working fine... so... once it connects it's fine, but actually getting it to connect is the struggle.

Whenever plugging in the MKRZERO, whether I leave it be and run the current uploaded sketch, or double tap the reset button to cycle it into bootloader mode (yes, the light pulses) I hear Windows' device connect chime, but it's immediately followed up by a message that reads: "USB device not recognized" and "The last USB device you connected to this computer malfunctioned, and Windows does not recognize it."

On the few occasions it does connect, it seems to work fine both in the normal sketch and in bootloader mode (as in, I've gotten it to work on both), and have been able to upload sketches to it.

I've tried multiple different cables, I don't think that's the issue, especially given that my Arduino Zero and Uno work fine with those cables (Arduino Zero works both on programming port and native USB port)

I'm at a loss as to why this might be, since I can tell the programs are running perfectly fine on the chip itself. My sketch runs with visible output (it drives and OLED module) and as stated earlier the LED pulses in bootloader mode, it just won't connect to USB most of the time.

Oftentimes, I'll try to upload a sketch once I finally do get it to connect, only for it to cycle and not connect again.

Any help would be appreciated.

[Dozie]

Contact Arduino Support via Contact Arduino, they will assist you resolve the issue.

[ryancog]

Sounds good, thank you!

[ryancog]

Well, Arduino support just said that the board was beyond recovery and to just contact DigiKey for a replacement, but given it's been longer than 30 days, I can't seem to figure out how to navigate their website, but that's besides the point.

I've a new lead on why this might be. Something strange I've noticed as I'm writing my program is that I seemed to get wildly different frame rates running the same program on the same screen with the same animation (there's no difference in the number of pixels being drawn each frame, so it's not because of that) with the only difference being that I reset the microcontroller in between runs. Sometimes it'll run faster, sometimes slower, and it remains running faster or slower overall until the mcu is reset again.

This has become far more apparent now that I've moved on to sound. I've a very simple implementation where, after setting the resolution and pin mode for an analog pin, the loop() function contains nothing but a for loop inside of which I have an analogWrite which writes the respective value from an int array to the pin, and then a delayMicroseconds to get the frequencies right (values were ripped from a wav file).

Here is the code (removed most of the array since it's giant):

const uint8_t audioData[26521] = {0x80, 0x80, 0x80, 0x82, 0x83, 0x82, 0x81...

void setup() {
  analogWriteResolution(8);
  pinMode(A0, OUTPUT);
}

void loop() {
    for (int lp = 0; lp < 26521; lp++) {
      analogWrite(A0, audioData[lp]);
      delayMicroseconds((22) - 3);
    }
}

I subtract 3 microseconds as that's the delay I saw on my scope between analog writes when switching from 0 to 255 continuously. (this way the total delay is the 22 microseconds I want)

However, running this code, similarly to my varying frame rates, plays back a sound that typically has a much slower frequency than what it should be, and only sometimes (or at least very close... it's hard to tell) does it play back and normal speed.

I'd like to figure out what's causing this so that A) my framerate is steady, and my audio recreation is consistent, and B) I've a hypothesis that because of this, the USB code is potentially running slower than it should also. I'm not sure how it works, but if it relies on the microcontroller's clock speed, as I'm fairly certain it does, then the USB timings would be almost always wrong, making a connection impossible in most cases, and leading to the behavior I'm seeing.

Right this second I have an encoder, two buttons, my OLED, and the audio amp connected up to the board, and am powering it via the USB port. I'm going to remove everything but the audio amp from the board to see if it makes a difference to give me another potential lead, and if so I'll post more detailed information about those connected components.

[ryancog]

UPDATE: Removing everything but the audio amp and still seeing varying delays -> supposedly varying clock speeds. The fact that this happened with the display also makes me think I've got another issue on my hands.

[ryancog]

It's also just occurred to me that this could be going the other way around... perhaps whatever's broken with USB is what's causing the mcu to spend more clock cycles on the USB CDC code.