Need a way to automate tests with sleep mode enabled

[ChrisAtSamraksh]

Currently we are unable to automate tests with sleep mode enabled because it locks out the JTAG and we can not reprogram a test.

There might be a way to send Visual Studios debug messages from the TestRig, putting the device in debug mode and then no longer sleeping. Perhaps we can then connect over JTAG and reprogram the next test.

[MichaelAtSamraksh]

Please cite affected branch, commit hash, platform, and build flavor.

[MichaelAtSamraksh]

Specifically, Release flavor does not apply to commit 34004127d48bb2ea2cf9748a5db466ef8b34a458 ".NOW PWR: force JTAG clock only when debugger is attached" Is there already a preprocessor symbol to indicate the test system is running? Options:

• Add a preprocessor symbol named SAM_TEST to indicate the TestSystem.
• Always check for JTAG and base enable/disable JTAG clock on the JTAG check.
• Power the board over the ARM-USB-OCD-H to enable POR JTAG attachment. We should probably always check for JTAG.

[Nathan-Stohs]

• Problem is that Chris still needs to have sleep for testing, so cannot just disable it statically.
• However the POR solution you mention might be more what he needs, which I think is just to get it into a known state where the JTAG is happy.
• Just enabling the JTAG clock at the right times probably isn't sufficient because I would question the quality / accuracy of the test especially in advanced sleep modes (STOP/STANDY) if that works at all.

[MichaelAtSamraksh]

Summary: we probably want power-reset capability with the TestSystem, with CLR startup code that sets the boot loader config flag for TestSystem builds.

• see 45ae9411eaa498e974b5e1ee679e8ccbd50ba787 ".NOW PWR support JTAG in Release flavor". I committed it before Nathan's insight. It is a quick fix for now, with the drawbacks of tests not being true to what non-JTAG users would experience.
• POR seems like best choice.
• Also, just write the boot loader flag into flash config before starting the test (either via Debugger, or a custom CONFIG_FLASH setting for the TestRig. Then a reset will cause the device to stay in the boot loader mode. This would almost be fool-proof, but would either require a command to jump into the CLR from the Bootloader with the boot loader flag set, or it would require building a TinyCLR image that always sets the boot loader flag during startup (which gets back to requiring a SAM_TEST preprocessor symbol.)
• If you want a Debugger message that turns on/off sleep, that is very doable but more complicated than the above. If we create a new custom message, we would need a custom Microsoft.SPOT.Debugger.dll to access it. Or, it might be possible to piggy-back on the Monitor_Ping message by inserting a custom WP_Flag that we check for in the Monitor_Ping handler, although one would still need a custom Microsoft.SPOT.Debugger.dll to access it. But this would assume the system would be responsive to Debugger messages at the end of all tests, so the safe bet is to instead use the boot loader flag with power cycle. (Yes, I conflated POR and power cycle in this entire thread.)

[ChrisAtSamraksh]

I think if we can issue a POR to the device and just keep sleep from being enabled for the first few seconds that would be enough time to issue a "reset init" command to halt the processor and allow programming. That would allow us to reprogram via the JTAG, have sleep be enabled from now on, and allow us to test the final code in an automated way.

[ChrisAtSamraksh]

I added Nathan's wakelock for five seconds on boot-up. This seems to keep us out of sleep the first five seconds.

The problem of automating test is not fully solved though. If I run openOCD and power cycle the board I can connect for five seconds (this is the wakelock) and then the connection drops. However, sometimes if I push the reset button on the .NOW it will actually stay connected after the wakelock expires....not always though. Power cycles never allow me to stay connected after wakelock.

If I get in the state where the openOCD is connected after wakelock then I can run all of my tests with no problems even with sleep enabled.

Another way to reliably get in this state is to reset the .NOW, quickly open GDB, connect with the device and reset it with GDB.

So the question is, is there a way to reliably get into this state where openOCD stays connected after wakelock after a simple power cycle or reset?

My test code is at 09ce3f87b47382b9157a2072a442b66c237f76da

[MichaelAtSamraksh]

Ideas:

Is the OpenOCD server set to poll every 6 seconds? Making that less than 5 seconds should allow the already-running OpenOCD server to catch and attach to the device during the 5 seconds.

About dying after the wake lock expires, can we modify the OpenOCD monitor to change the clock settings to support JTAG, (or... execute a function that modifies the settings)? Or make it so that the PWR driver is re-initialized after the wake lock (which would recognize the JTAG and modify the clock settings to support the JTAG)?

[AnanthAtSamraksh]

• I remember Mike doing something similar for Adapt, where there is a window of 20 seconds during which a user could attach the JTAG and reset the device. Why can't wakelock be increased to say 20 seconds?
• Also, why not check if JTAG is attached during startup, after initialization is complete and before wakelock starts?

[ChrisAtSamraksh]

The wakelock does allow us to program the .NOW initially, however in the current implementation of wakelock we get the original problem of the CLR iterating through a tight cycle attempting to put us to sleep and banging on the global_lock. This causes all sorts of problems during the wakelock with a simple demonstration of the problem being that a realtime timer set to 25Hz can only achieve 33Hz.

Ideally we just cycle within the wakelock waiting for an interrupt to occur and then exiting if we see an interrupt. This keeps us out of the CLR cycle that bangs on global_lock. If we are able to identify when interrupts occur and exit at that time then we can use wakelocks whenever we need to. However, as they currently are wakelocks can not be used beyond the initial startup as they hurt performance.

[MichaelAtSamraksh]

If we never sleep in TinyBooter, then we might as well always turn the JTAG clock on in TinyBooter. Then, in TinyCLR, you could write the "Reboot and Stop" flag in the flash Config Sector, so on the next boot, the device will stop and wait in TinyBooter. That would handle both types of boots, hard and soft reset. For one possible implementation, see my commit in a temporary branch: git cherry-pick 9a18a76429a74dc8b72b6a4bb128ccb4336795b9 That commit does not have a convenience function for writing the boot loader flag. Another thing to do would be to force on the JTAG clock when we enter a non-returning fault handler. (I suggest that because we do not currently implement the watchdog.)