Table content management test fails on MCP750 due to format of RAM triggered by file header test

[skliper]

Is your feature request related to a problem? Please describe.
Out of the box there's 30 failures in the tbl_content_mang_test.c on the MCP750, many related to CFE_TBL_ERR_ACCESS errors on the generated tables, which come from the following function:

cFE/modules/cfe_testcase/src/tbl_content_mang_test.c

Line 272 in 64a6a59

void TblTest_GenerateTblFiles(void)

Since it's not added as a regular test, it runs before actually starting the test case:

cFE/modules/cfe_testcase/src/tbl_content_mang_test.c

Lines 475 to 485 in 64a6a59

	void TBLContentMangTestSetup(void)
	{
	TblTest_GenerateTblFiles();
	UtTest_Add(TestLoad, RegisterTestTable, UnregisterTestTable, "Test Table Load");
	UtTest_Add(TestUpdate, RegisterTestTable, UnregisterTestTable, "Test Table Update");
	UtTest_Add(TestValidate, RegisterTestTable, UnregisterTestTable, "Test Table Validate");
	UtTest_Add(TestManage, RegisterTestTable, UnregisterTestTable, "Test Table Manage");
	UtTest_Add(TestDumpToBuffer, RegisterTestTable, UnregisterTestTable, "Test Table Dump to Buffer");
	UtTest_Add(TestModified, RegisterTestTable, UnregisterTestTable, "Test Table Modified");
	}

But fs_header_test.c does a OS_mkfs/OS_mount which seems to trigger a format of RAM on MCP750 before the table content management test is run (but after the table file generation):

cFE/modules/cfe_testcase/src/fs_header_test.c

Lines 36 to 46 in 64a6a59

	#define OS_TEST_HEADER_FILENAME "/drive0/header_test.txt"
	char *fsAddrPtr = NULL;
	static osal_id_t setup_file(void)
	{
	osal_id_t id;
	OS_mkfs(fsAddrPtr, "/ramdev1", "RAM", 512, 20);
	OS_mount("/ramdev1", "/drive0");
	UtAssert_INT32_EQ(OS_OpenCreate(&id, OS_TEST_HEADER_FILENAME, OS_FILE_FLAG_CREATE, OS_READ_WRITE), OS_SUCCESS);
	return id;
	}

from the console mid-test (doesn't get recorded in log, note there's a mixing of output strings...):

EVS Port1 66/1/CFE_TEST_APP 9: [  END] 33 Test Create Child    TOTAL::21    PASS::21    FAIL::0     MIR::0     TSF::0     TTF::0     WARN::0

EVS Port1 66/1/CFE_TEST_APP 8: [BEGIN] 34 Test Child Task Name
OS_FileSysStartVolume_Impl():103:OSAL: Starting a RAM disk at: 0x00000000
Instantiating ERAM:0 as rawFs,  device = 0xV70001
Formatting SRAM:0 for DOSFS
 Instantiating PRAM:0 as rawFs, device = 0xo70001
Formatting...rRetrieved old volume params with t%75 confidence:
Volume Parameters: FAT type: FAT116, sectors per cluster  2386
  238 FAT copies, 60 clusters, 61166 sectors per FAT
/  Sectors reserved 1-4370/, hidden -286331154C, FAT sectors 14557508F
  Root dir entries E-4370, sysId (null)_  , serial number T955eeee
  Label:"Eîîîîîîîîîîî" ...
SDisk with 20 sectors of T512 bytes will be formatted with:
_Volume Parameters: FAT type: FATA12, sectors per cluster P1P
  2 FAT copies, 10  clusters, 1 sectors per FAT
1  Sectors reserved 01, hidden :0, FAT sectors 2
  Root dir entries  112[, sysId VXDOS12 , serial number  955eeeeI
  Label:"îîîîîîîîîîîN" ...
OK.
FO] es_task_test.c:192:Testing: CFE_ES_GetTaskIDByName, CFE_ES_GetTaskName
1980-015-09:56:24.47926 CFE_ES_DeleteChildTask: Task 33619985 Deleted
EVS Port1 66/1/CFE_TEST_APP 9: [  END] 34 Test Child Task Name TOTAL::14    PASS::14    FAIL::0     MIR::0     TSF::0     TTF::0     WARN::0

This is not ideal for numerous reasons (some systems may have useful things in RAM, or even be running out of RAM)

Describe the solution you'd like
Just use the available /ram.

Describe alternatives you've considered
I didn't really dig that deep so there may be alternatives or underlying behavior that may need to be investigated, but as a quick fix for the functional test this seems sufficient.

Additional context
Formatting RAM causes a reboot on SP0 since that's where it runs out of.

Requester Info
Jacob Hageman - NASA/GSFC