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

Tue 2020.03.10

'and see if that helps'

Well, I have given it the good ol' college try, but am now out of ideas, and faced with a new anomaly.

I thought I saw the same possible 'Stepped On' pin issue, from your explanation in post #7, and changed that to a separate adjacent pin, but the setWatch never triggers with that change either.

I noticed the following over the weekend, but dismissed it, that is until this evening. I powered down the setup, and shut off the PC. Tonight, I powered up the setup and the PC.

New anomaly.

For a sanity check, I uploaded the code file I submitted in post #6 but this time, the output square wave was crunched to 1Vp-p. Odd, as this all worked when I posted. I made several attempts with other code I had, and the output now swings to the rails, 0-3v3. I chose to retest, and now have a repeatable scenario. The first upload seems to always crunch the output, and the second upload seems to always allow full range of output swing. No ideas, but the PPI setup isn't allowing the pin output. I'll continue to try settings pin modes and playing with the start interval etc.

A more perplexing issue is what I stated in post #6. I didn't want to start a new related thread so as not to draw attention. Entering cw() or clearWatch() will also inadvertently kill the PPI setup.

Reviewing ' If no parameter is supplied, all watches will be removed'

http://www.espruino.com/Reference#l__global_clearWatch

I tried with both a no argument and also passing the setWatch ID in cwi() but both exhibit the same output killing result on Pin D22. As clearWatch is meant to do just that, then why is PPI getting clobbered? No idea here either.

I'll continue to test, and this weekend, I'll try these examples with STM32 to see if more satisfactory resulsts can be obtained.

1 Attachment

• codeNRF52LLTestExtLEDFlashFORUM20200310.js