A CySoftwareReset() clears most software-related items, but I think there are some hardware function that it does NOT reset. That shouldn't be an issue for the BLE radio however; You could try calling CyBle_Stop() before resetting the unit if you want to test it.
There are functions that will store connection data permanently into the flash, but you have to explicitly call the flash write functions for them to run/save the data to flash. Iirc, the CYBLE stack only queues connection-related data to be stored in flash if you set the unit to use bonding. It shouldn't be doing flash writes without your code interacting with it on purpose.
When you say the master "reconnects", is this:
After ten minutes?
After it had already connected to the slave once?
After failing to connect to the slave?
I would assume you have tried using the debugger to catch it's stack/state when it crashes/fails?
If not, then it could be your code is merely out of control :)
Double check that you aren't scanning/advertising when attempting to connect to the slave;
Double check your BLE radio states, as a lot of the functions have "prerequisites" before you can call them.
The CySoftwareReset() API resets the chip under software control, thus the name. It does not only clear the software components, it does a complete re-initialization of the chip.
Sorry @Bob, I didn't mean to imply that it skipped reinitialization; I meant that there is some hardware functionality that can't be reset through the use of CySoftwareReset(); (I believe I read this in the documentation for the function itself), but for most functionality it should reset just fine.
Using CyBle_stop seems to have fixed the issue, it still takes a number of attempts to re establish a proper connection but I still get all my data from the slave device so I'm happy with the fix thank you very much Jack