Tutorial example output anomaly using low level access PPI on MDBT42Q breakout board

Sun 2020.03.15

'If the output is getting cropped to ~1V peak to peak then chances are you're trying to write to a pin that is already set to an output though'

The truly bizarre! Things that changed: Last week, I powered off the circuit and scope, Google Chrome locked up Windows, so I had to warm reboot. Yesterday I powered on the scope and applied power to the circuit and played with an external setWatch file for a sanity check. I loaded the file from post #6 and to my amazement it ran this time as expected. Floored!! Was it the newly introduced setWatch as it was indicated in post #9 that setWatch uses gpiote? Was it that last week after using ppi.disable that when re-uploading code PPI doesn't get set correctly? So I tinkered with the code a bit, both from the console and the editor side, ending up hosing something. So I uploaded the original file again, but this time no luck, even after re-applying power to the circuit. So, possibly a timing thing setting up PPI, perhaps?
incidentally, using the Native IDE 0.70.6 - so Chrome and reboot shouldn't have had an effect


Discovered another anomaly, but might be more of correct proceedural thing.

Steps: Uploaded code which starts the PPI rtc. Played with rtc.prescaler and re-uploaded. Even with WebIDE Setting 'Reset before Send' set, the new prescaler value doesn't take effect. That said, a hard poke32(rtc.tStop,1) stop of the counter, then re-uploading does work.

That sort of makes sense as we are only to poke a value, and the counter doesn't need to peek at it a second time as it is already doing it's work. But, in the process of re-uploading code, the counter is restarted, so it is reset(1) that may be the culprit.

EDIT:
' Writing to the PRESCALER register when the RTC is started has no effect'
p.241   https://infocenter.nordicsemi.com/pdf/nR­F52832_PS_v1.1.pdf

Note that the register value does change though, and is read on subsequent uploads. It just doesn't change the RTC after it has been started.

So, should a reset(1) also control the stopping and resetting of what ever PPI peripherals (intuitive as reset means reset - implying all parts of chip) are running, or is this a procedural thing where the user must follow a strict path in reverse order of setup, before they upload code, meaning reset(1) only applies to Espruino in RAM?

EDIT:    three hours later
Attempting to make changes to PPI using the L-hand console, it is possible to place the peripherals in a state that is not recoverable or (yet to be discovered maybe) re-configurable when attempting to add a setWatch, in my case on an unrelated PPI external (D15) pin. Yanking the power is the only way to recover.