Use memory fence when disabling cache to avoid -O2 problems

[dhalbert]

Fixes #7279.

Disabling the cache on SAMx5x caused problems when compiling with -O2, apparently due to inlining the microcontroller cache control routines.. Access to the external flash chip did not work.

Changes made:

• Add memory fences when disabling cache samd-peripherals#43 adds a memory fence before and after disabling the cache.
• external_flash.c tries a little harder to make sure the flash chip is ready, by retrying fetching the JEDEC ID if necessary. Without this, if the chip was not actually ready, the ID would not be read, and flash_device ended up being NULL.
• A check was added to make sure flash_device was not NULL when asking for the device size. Previously, this could have returned a garbage value. I saw this cause incorrect data to be returned for MSC queries.
• A memory fence was also added for nRF, which potentially has similar problems, though they don't seem to be as obvious.

Right now we don't actually compile any SAMx5x builds with -O2, so this change doesn't fix any presentlybroken builds. The nRF builds are -O2 -fno-inline-functions, which may not provoke the optimization problems seen in SAMx5x. I did not remove -fno-inline-functions in nRF, because it makes the -O2 builds smaller. (A while ago, -fno-inline-functions was also used with -O2 in SAMx5x builds, before they got too big, and started needing -Os.)

Cortex-M0 doesn't have a cache, so this is not a problem at all for M0 builds. I looked at cache routines in broadcom, and they include fencing, though not as much. (Maybe worth exploring later.)

[jepler]

Thanks, looks good. didn't test.

[tannewt]

Thanks for this! I've seen something very similar on the nrf bangle.js 2. Will need to update and test it when I'm back to my proper desk.