Awesome @@BigG you solved the mystery of the "Open operation failed"!
I'll see if I can put something in the CC3200 utility that on user command removes all HTLM files from the file system. Or maybe even better, a Sketch that allows you to selectively remove files using the serial monitor.
Thanks @@BigG! That is very helpful. You last experiment, was this after you formatted the FLASH or is the FLASH still like it was previously?
I will try to reproduce it here again. Do you remember which projects you downloaded when using CCS? Were there any projects that stored files in flash such as HTML and images?
Ok problem has been resolved by reformatting and reloading my service pack. The experiments above were done pre-formatting.
I know when I originally received my launchpad I had problems uploading some files using CCS. This was resolved by reformatting and clearing out the OOB (out of box) demo, which would have had html files preloaded. I had subsequently uploaded other html files / images onto the launchpad but never removed them so I thought it could be linked and it proved to be the case.
Hence in my case it appears this "Open operation failed" message was triggered when the Energia compiler ran out of free space on my flash.
Depending on what you interface to, if you add a little time between characters sent to a Software Serial emulator, you can get more reliable communications at higher baud rates. Long bursts of continuous data can cause differences in the clock rates of the two devices (especially using RC oscillators) to get the software UART out of sync with the data. At low baud rates, the problem is not very significant, but at higher rates it comes into play. Simply using 2 stop bits in the communications setup instead of 1 stop bit can make a lot of difference.
Zip of current code: SLFS.zip
Unzip that in ~/Documents/Energia/libraries or wherever.
Be sure you have an updated copy of the WiFi library, as it needs WiFi.init() to be a public method.
My latest copy is here: simplelink_wifi_library_latest_10142014.zip - unzip that from within your Energia install's toplevel directory (e.g. from within C:\energia-0101E0013).
(that actually has one change ahead of Energia's current github master; it moves the various WiFi buffers to .text section on FRAM chips so they will fit on the Wolverine FR5969 LaunchPad w/ CC3100)
The SLFS library declares an instance right away called "SerFlash", so SerFlash.open(), SerFlash.close(), SerFlash.write(), SerFlash.print(), SerFlash.println(), etc...
You can delete files using SerFlash.del()
You cannot list the directory contents or know what files are on the flash. I did not find any API calls in the SimpleLink API that support such a feature. I'm assuming it's been left out for security reasons or similar.
The open() system call is given options based on the sl_FsOpen() SimpleLink API call, so... looking at documentation here- http://software-dl.ti.com/ecs/cc31xx/APIs/public/cc31xx_simplelink/latest/html/index.html ... look at "File System" and then "sl_FsOpen":
open file for read or write from/to storage device
[in] pFileName File Name buffer pointer
[in] AccessModeAndMaxSize Options: As described below
[in] pToken Reserved for future use. Use NULL for this field
[out] pFileHandle Pointing on the file and used for read and write commands to the file
AccessModeAndMaxSize possible input
FS_MODE_OPEN_READ - Read a file
FS_MODE_OPEN_WRITE - Open for write for an existing file
FS_MODE_OPEN_CREATE(maxSizeInBytes,accessModeFlags) - Open for creating a new file. Max file size is defined in bytes.
For optimal FS size, use max size in 4K-512 bytes steps (e.g. 3584,7680,117760)
Several access modes bits can be combined together from SlFileOpenFlags_e enum
The syntax for SerFlash.open() therefore is something like this:
SerFlash.open("myfile.txt", FS_MODE_OPEN_READ); // Open file for reading
SerFlash.open("myfile.txt", FS_MODE_OPEN_CREATE(1024, _FS_FILE_OPEN_FLAG_COMMIT)); // Create new file, allocated 1024 bytes to contain it
SerFlash.open("myfile.txt", FS_MODE_OPEN_WRITE); // Open file for re-writing
From what I've been able to gather, you can't open an existing file and write pieces of it piecemeal; opening the file and writing forces the serial flash to erase the entire block, so what you write replaces the prior contents entirely. So for updating configuration info, you would need to read it into memory, make your changes and then re-write the entire file. Also, there's a maximum # of files you can store ... something like 128 I believe, and that includes a number of system files in that count which are already there. It's not meant to be a huge filesystem. But it should do the trick for a lot of uses.
Also, in general the UART lines should have a pullup resistor enabled on the RX side port, and it looks like SoftwareSerial does not do this; it only enables INPUT mode but doesn't enable the PxREN register.
For complete giggles, try doing this before the SoftwareSerial object's .begin() statement:
pinMode(<rxpin>, INPUT_PULLUP); where <rxpin> is replaced with whichever pin you're using for receive-mode.