'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.
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.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Sun 2020.03.15
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.
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?