Project

General

Profile

Spurious Reboot Debug

Added by Michael Karasoff over 9 years ago

Hi,

I am having an intermittant issue with the MityARM on some (not all) of our custom carrier boards - The processor has spurious reboots. The processor will boot and run Linux fine, then it reboots on its own, starting at the bootloader. We have several carriers that work fine with the same modules as software, so I think this has something to do with our carrier board design.

So far, I've scoped the 4.8v power rail we are using to power the SOM, and the SOM reset button pin. The power rail holds at 4.8v +/- 50mV, and the reset line stays inactive. Is there anything else, besides power and reset, that I should look for?

Thanks,
Mikes


Replies (4)

RE: Spurious Reboot Debug - Added by Michael Williamson over 9 years ago

Hi Mr. Karasoff,

Are these MityARM-3359s? What is the model number? Do you also have a couple of serial numbers of the modules that are exhibiting the problem?

Does the reboot issue track the SOM or the Carrier board? E.g., if you swap SOMs between a "good" combo and a "rebooting" combo, does the problem track the SOM or the carrier card?

Are you using the watchdog on the SOM? Are you running any application code when the reset occurs? Linux kernel version?

Sorry for the 100 questions, just trying to sort out where you are at. Also, have you checked the SOM errata for any potential issues?

-Mike

RE: Spurious Reboot Debug - Added by Michael Karasoff over 9 years ago

Michael,

Thanks for the replay. No problem with the many questions.. I'm kind of at a loss tracking down the issue, so any tips can help.

Are these MityARM-3359s? What is the model number? Do you also have a couple of serial numbers of the modules that are exhibiting the problem?

The part number is 3354-HX-X38-RI. This has happened with all of the modules I've tried. The latest module S/N is 1310345.

Does the reboot issue track the SOM or the Carrier board? E.g., if you swap SOMs between a "good" combo and a "rebooting" combo, does the problem track the SOM or the carrier card?

The issue appears to be with the carrier board. We have installed SOMs that have reset on the suspect carrier to other carrier boards where the SOMs have not had a problem.

Are you using the watchdog on the SOM? Are you running any application code when the reset occurs? Linux kernel version?

I don't think I'm using the the watchdog. Could an unused yet uninitialized watchdog cause problems? We haven't added applications that would reset the processor. Kernel version is 3.2. FWIW, I've seen this behavior when the SOM is running u-boot, so I've got to wonder if the Kernel or application code is even part of the equation.

The behavior seems to come in fits and spurts. The system will usually boot and run for an indeterminate amount of time and then start rebooting. Often, but not always, the SOM will then get stuck in a cycle of reboots while u-boot is running. If I turn the system off for a while, then back on it will boot normally and run once again until it starts the reboot process again. I would say this is a temperature, but I've looked at this with a Flir and nothing on our SOM or carrier appears to get much above 40C.

I will certainly take a look at the errata. Any other hints or places where you think I should look would be helpful.

Thanks again,
Mike

RE: Spurious Reboot Debug - Added by Michael Williamson over 9 years ago

Would you be willing to share (privately, not on the forum) your baseboard schematic?

-Mike

RE: Spurious Reboot Debug - Added by Michael Karasoff over 9 years ago

Yes. Where do I send it?

    (1-4/4)
    Go to top
    Add picture from clipboard (Maximum size: 1 GB)