I’ve designed a custom board incorporating a G400-S.
There’s some code running in a loop, where the normal execution time per cycle is 17ms. A problem consistently appears when the board is first powered: the processor runs about 6X slower than normal, i.e., the cycle time is now 100ms with the same program. Note that in all cases the program is not being debugged via Visual Studio – these are the execution times when the program is running completely untethered in its deployed configuration.
If I subsequently reset the board using any method – by grounding the G400 reset pin or by issuing a RebootDevice() from within my NETMF program or by issuing a Reboot CLR command using FEZConfig – the execution speed returns to normal.
To troubleshoot the issue, the program has been pared down to a naked for-loop, and there is still a difference in execution speed between when the board is first powered vs. when it has been reset. For this barebones test program, the difference is not as dramatic, say 20%, but the difference is still repeatable.
In summary:
If the board has been unpowered for a long time, the execution speed is slow on the first powerup. A reset is required to make execution speed return to normal.
When the board is currently powered and power is removed for less than 4 seconds, if power is restored within that time period, execution speed is normal. If power has been cut for longer than 4 seconds, execution speed is slow on the next powerup.
I’ve run the same test on the FEZ Raptor and the G400D Breakout Board – execution times are normal on the stock boards with no anomalies. Something’s clearly different about my custom board, and I’m looking for ideas on where to start looking.
What are the factors that would make the G400 run slow on powerup and stay that way until reset? Some clock or memory component not being initialized/powered up properly?
I have the same issue with 2 raptors. I replaced the reset capacitor from 18pF to 1uF but that did not changed the behaviour. I am suspecting the power supply power up condition but had not enough time to investigate. I had to deliver the device to a customer. I temporary solved the problem with the following snippet of code as first code in Main() …
long counter = 0;
DateTime endTime = DateTime.Now.AddSeconds(1);
do
{
counter++;
} while (DateTime.Now < endTime);
#if DEBUG
if (counter < 8000)
#else
if (counter < 30000)
#endif
{
PowerState.RebootDevice(false);
}
@ RobvanSchelven @ Skewworks – To clarify, you guys also see this phenomenon on stock Raptor boards? I ask because I also tried 2 stock boards and didn’t see the anomaly, so I naturally blamed my custom design. Have you seen it manifest on some boards and not others?
@ John - The board i have showing this behavior is at a client. (in Europe) Not sure if Skewworks is located in the USA. If so maybe you could swap boards and investigate his board.
@ All - For a board that shows the issue, does it happen every time consistently or is it random among all boards? We have so far been unable to reproduce it.
@ All - We’ve been unable to reproduce it. If you have a board that consistently shows the issue every time and want to send it to us, we can take a look.
My raptor shows this same issue as well… a dramatic difference in speed going from the first power up to the second. I can take a quick video on my phone tomorrow morning to show the issue and maybe help you replicate it.
This is with the program deployed in ‘debug’ mode, I haven’t tried to deploy in ‘release’ mode yet. There is a huge difference in performing some simple math and drawing the table data and graph. I can repeat this issue 100% of the time. The 2nd power up draws the table and graph near instantly compared to first power up where it very slowly performs the same action.