Tool/software:
Hello anyone,
We started to test FAPI some time ago and had issues with data buffer pointer halting when struct member data types changed in the input buffer used to write 256KB flash blocks of 4096 sectors.
After adding WA calls to stop Fapi initialize random faulting CPU and granted Fapi DCSM bank 1 flash access for flash bank 1 writes. Now Fapi refuses to write data to the sector address from the very same code that sort of worked but acted very kludgy at best.
Has there been any debug fixes to Fapi API v1.56 so it handles actual struct member data without having to for loop feed data addresses input read data buffer? Note two captures below.
Seemingly the start address given to Fapi write address should automatically increment pointer to the user data buffer without need of a for loop index handler if writes four 16bit words 64 bits sections set to align 4. As we found out flash write ability was acting badly to handle varying data types buffered as struct members passed into the write flash function header. Or buffer placed within a function to write Fapi address data to 256kB flash blocks at the given start address.
Some issues seem related to C2000 compiler refusing to link struct member data types (parameter data) into a buffer with fixed type pointer, e.g. { ((uint16 *)&userParams) }. When it does link copy buffer cells, e.g. { ((uint16 *)ReadBuffer[144] ) } Fapi data buffer pointer, CCS v12.8.1 debug shows buffers contents are just address in each cell rather than struct member data. The raw user data copied from the struct member data pointer buffered name &userParams.
Perhaps a simple task for a compiler to handle. Yet it refuses to copy struct member data of various data types into fixed pointer to a buffer of many array cells, all end up as integers. Or sequence the write address for the buffer length being provided to Fapi write address data. What is the point of providing the buffer length if Fapi chokes on the varying datatypes? Perhaps FAPI is not intended to be used to store user data into flash memory sectors and was mostly tested for firmware updates?
That being said why has TI not developed some way for C2000 MCU class to write user data into flash memory of struct member data pointers being used in all the examples? Fixed data pointers to buffers seem to fail no matter what version of CCS, v7.2, v9.3, or C2000 compiler. The data being copied into a user defined buffer pointed to by a fixed data type is useless for storing struct member data.
// USER_Params float32_t sizeof = 286/2=144 (32bit) variables
// Note: Since the TMS320C28x float is 32bits,
// (to make it separately addressable), a byte is also 16 bits.
// This yields results one may not expect.
uint16_t ui16NumParameters = (sizeof(USER_Params));
float32_t * FapiUserParams[145]; //FAPI_FLASH_BUFFER
// Get a pointer to the latest parameter block in flash.
//
pucBuffer = FlashPBGet();
//
// See if a parameter block was found in flash.
//
if(pucBuffer || pucBuffer == NULL)
{
//
// Loop through stored words of Fapi parameter block to copy its contents
// from flash to SRAM. Roughly 144 parameters
//
for(ulIdx = 0; ulIdx < ui16NumParameters / 2; ulIdx++)
{
if(!bGetFapiReadData)
{
/* buffer stuct member user data */
*FapiUserParams[ulIdx] =
((float32_t *)&userParams_M1)[ulIdx];
}
/* Get Fapi flash block data */
if(bGetFapiReadData)
{
((uint8_t *)&userParams_M1)[ulIdx] =
((uint8_t *)pucBuffer)[ulIdx];
}
}
}
