nrf: sd_flash_operation_status should be volatile

[dhalbert]

A flag variable, sd_flash_operation_status, used to check when an internal flash operation was done was not volatile, so it could not reliably be checked.

STATIC sd_flash_operation_status_t sd_flash_operation_wait_until_done(void) {
    while (sd_flash_operation_status == SD_FLASH_OPERATION_IN_PROGRESS) {
        sd_app_evt_wait();
    }
    return sd_flash_operation_status;
}

Fixes #2339, I believe.

I think maybe this broke with better inlining and inter-routine optimization after the switch to gcc9. I looked at the assembly code and the loop above doesn't even bother to check to flag variable in the optimized code. Also, it worked fine when compiled without optimization.

[dhalbert]

By the way, the underlying routine doing the writing raises Python exceptions when it encounters errors, but it could hit errors when Python code is not running (when CIRCUITPY is being mounted, for instance, I think). So what would happen to those raises? @tannewt, do you know? Maybe it will fault and go into safe mode? Not sure how to handle the non-Python errors. (It's too late for me to check up on this further.)

[jerryneedell]

@danh#1614 tried the pca10059-volatile-file.uf2 from discord -- its is "better" but still has issues -- I was able to do a storage.erase_filesystem() but it still has some odd behaviors -- If I run my "blinky" code then control-C to stop then do control-D to soft reboot, it terminates the screen session and appears to reset. More troublesome is that after a few attempts at soft reboots, it "hung" my linux box as before -- had to reboot the linux box to get it back! However, the PCA10059 survived intact. It was there when I rebooted. So it still appears to be doing something kind to the USB port...

Note that a Control-D at the REPL without having run a previous program dos a normal soft reboot. Even Control-C then Control-D is OK -- the RESET only happens if another program was run.

Hmmm -- it seems like what triggers the RESET on soft reboot is if an exception has been thrown.
If I Reboot then run a simple program like the default code.py (prints Hello World!)
it works and I can do a soft reboot normally.

However is I just type gibberish at the REPL and trigger an error , then try a Control-D, it does a hard RESET. In the earlier cases, the Control-C cause and exception in the running program so perhaps it is the exception that is setting up the issue with the soft reboot....

After rebooting the linux box, I loaded the BLE library to the pca10059 and have been trying a fe demos -- simpletest and current_time_service work OK -- the only problem I ham having is that it always does a full RESET on soft reboot -- that is Control -D causes it to drop the USB connection and it appears to RESET. I have not reproduced the linux box hangup, yet.

I have repeated the storage.erase_filesystem() and reloaded code.
It still does a hard RESET instead of soft reboot following any exception....

[tannewt]

@dhalbert Raising an exception when the VM isn't running causes an ALLOC_OUTSIDE_VM (iirc) safe mode.

For @jerryneedell's problem we have #2378 now.

[tannewt]

Woo! Thank you!