TMS320F28377D: When using the XDS560V2 emulator to debug, calling the FlashAPI the program will runaway

Hi Cherry,

Just to make sure that I am understanding the problem correctly, the user is unable to erase the N sector of the flash with the xds560v2?  They are able to successfully erase the sector with the xds100v3? Also the program runs fine when no JTAG debug probe is connected?

Best Regards,

Ben Collier

Hello Ben,

Thanks for your support and please let me specify the case here:

Using the xds560 erase is a program that calls flashapi to read and write internal flash, but the emulator used by debug is xds560. When an SCI command is issued externally, there is a high chance that an error will be reported on a particular call during the lower computer program call flashapi to read and write.

However, when doing the same with xds100v3, no error is reported. The lower computer program is running in BCDEF, not in N sector. 

Debug via the xds560, send commands to DSP over the serial interface and DSP calls flashapi for data erase and write. The purpose of connecting the emulator is to see if the data was written correctly, but during this process, However, in this process, CCS errors and direct reset of DSP will occur randomly and occasionally.  But before that, the data can be written correctly.

With the same procedure, debugging with emulator xds100v3 does not have the same issue.

And please be noted that the program works fine offline regardless of which emulator is used. 

Please let me know if anything unclear. 

Thanks and Regards,

Cherry

Hi Cherry,

So there is something in their program so that the F28377D does a flash erase when it receives a certain command over SCI? 

Could you show me how the the customer is using the flash API? Are you able to share code here, or can you send that section of their program in a private message? 

Best Regards,

Ben Collier

Hi Ben,

Benjamin Collier said:

Could you show me how the the customer is using the flash API? Are you able to share code here, or can you send that section of their program in a private message? 

Please see the code:

void Flash_Write(Uint32 address,Uint16* Buffer,Uint16 length,uint16_t Status)
{
Uint32* Buffer32 = (Uint32*)Buffer;
Uint32 u32Index = 0;
Uint16 i = 0;

// Disable ECC. ECC does not have to be disabled to do FSM operations like
// program and erase.
// However, on Sonata Rev. 0 silicon, due to an OTP ECC errata,
// disable ECC to avoid ECC errors while using Flash API functions that
// read TI-OTP
EALLOW;
Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0x0;
EDIS;

EALLOW;

// Before performing FSM operations, set the waitstates for FSM operations
// calculated using RWAIT = (SYSCLK/50MHz)-1
// If RWAIT results in a fractional value, round it up to the nearest
// integer.
// Please note that RWAIT for read operation should be calculated
// differently. See Internal Memory guide section in TRM for more details.

#if CPU_FRQ_200MHZ
Flash0CtrlRegs.FRDCNTL.bit.RWAIT = 0x3;
#endif

// This function is required to initialize the Flash API based on System
// frequency before any other Flash API operation can be performed
#if CPU_FRQ_200MHZ
oReturnCheck = Fapi_initializeAPI(F021_CPU0_BASE_ADDRESS, 200);
#endif


if(oReturnCheck |= Fapi_Status_Success)
{
// Check Flash API documentation for possible errors
Example_Error(oReturnCheck);
}

// Fapi_getLibraryInfo function can be used to get the information specific
// to the compiled version of the API library
//oLibInfo = Fapi_getLibraryInfo();


// Fapi_setActiveFlashBank function sets the Flash bank and FMC for further
// Flash operations to be performed on the bank
oReturnCheck = Fapi_setActiveFlashBank(Fapi_FlashBank0);
if(oReturnCheck |= Fapi_Status_Success)
{
// Check Falsh API documentation for possible errors
Example_Error(oReturnCheck);
}

// Fapi_getBankSectors function returns the bank starting address, number of
// sectors, sector sizes, and bank technology type
// Above information is returned in a structure oFlashBankSectors of type
// Fapi_FlashBankSectorsType
/* oReturnCheck = Fapi_getBankSectors(Fapi_FlashBank0,&oFlashBankSectors);
if(oReturnCheck |= Fapi_Status_Success)
{
//Check Falsh API documentation for possible errors
Example_Error(oReturnCheck);
}
*/
if(Status==0)
{
// Erase Sector N
// Sectors A and D have the example code so leave them programmed
oReturnCheck = Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector,
(uint32 *)address);

// Wait until FSM is done with erase sector operation
while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady){}

// Verify that SectorL is erased. The Erase step itself does a
// verify as it goes. This verify is a 2nd verification that can be done.
oReturnCheck = Fapi_doBlankCheck((uint32 *)address,
Bzero_16KSector_u32length,
&oFlashStatusWord);

if(oReturnCheck |= Fapi_Status_Success)
{
// Check Falsh API documentation for possible errors
// If Erase command fails, use Fapi_getFsmStatus() function to get the
// FMSTAT register contents to see if any of the EV bit, ESUSP bit,
// CSTAT bit or VOLTSTAT bit is set (Refer to API documentation for
// more details)
Example_Error(oReturnCheck);
}
}
// A data buffer of max 8 words can be supplied to the program function.
// Each word is programmed until the whole buffer is programmed or a
// problem is found. However to program a buffer that has more than 8
// words, program function can be called in a loop to program 8 words for
// each loop iteration until the whole buffer is programmed


// Example: Program 0xFF bytes in Flash Sector C along with auto-
// generated ECC

// In this case just fill a buffer with data to program into the flash.
/* for(i=0;i<=WORDS_IN_FLASH_BUFFER;i++)
{
Buffer[i] = i+20;
}
*/

for(i=0, u32Index = address ;
(u32Index < (address + length))
&& (oReturnCheck == Fapi_Status_Success); i+= 4, u32Index+= 4)
{
oReturnCheck = Fapi_issueProgrammingCommand((uint32 *)u32Index,Buffer+i,
4,
0,
0,
Fapi_AutoEccGeneration);

while(Fapi_checkFsmForReady() == Fapi_Status_FsmBusy);

if(oReturnCheck |= Fapi_Status_Success)
{
// Check Flash API documentation for possible errors
Example_Error(oReturnCheck);
}

// Read FMSTAT register contents to know the status of FSM after
// program command for any debug
oFlashStatus = Fapi_getFsmStatus();

// Verify the values programmed. The Program step itself does a verify
// as it goes. This verify is a 2nd verification that can be done.
oReturnCheck = Fapi_doVerify((uint32 *)u32Index,
2,
Buffer32+i/2,
&oFlashStatusWord);
if(oReturnCheck |= Fapi_Status_Success)
{
// Check Flash API documentation for possible errors
Example_Error(oReturnCheck);
}
}

// Fapi_doMarginRead((Uint32 *)Bzero_SectorM_start,Buffer_read32,2,Fapi_NormalRead);

// Enable ECC
Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0xA;

EDIS;

//Fapi_doMarginRead((Uint32 *)Bzero_SectorM_start,Buffer_read32,5,Fapi_NormalRead);
// Leave control over flash pump
// ReleaseFlashPump();

// Example is done here
Example_Done();

}

uint16_t Data_r[150];
float_to_Byte(Location_PID_Data1[0].KP, &Data_r[0]);
float_to_Byte(Location_PID_Data1[0].KI, &Data_r[4*1]);
float_to_Byte(Location_PID_Data1[0].KD, &Data_r[4*2]);
float_to_Byte(Location_PID_Data1[0].MAX_Integration, &Data_r[4*3]);
float_to_Byte(Location_PID_Data1[0].MIN_Integration, &Data_r[4*4]);
float_to_Byte(Location_PID_Data1[0].Offect_Num, &Data_r[4*5]);

Flash_Write(Bzero_SectorM_start, Data_r, 136, 0);

Thanks and Regards,

Cherry

Hi Cherry, 

The xds100v3 and the XDS560V2 use separate software for generating the bits that they send to the device. It is possible that this problem is caused by some issue in the software of the XDS560V2, and this would be a very specific and difficult bug to find. Is this a critical issue for your customer, or are they satisfied with using the xds100v3 since it does not have this issue? 

Best Regards,

Ben Collier

Hi Ben,

Benjamin Collier said:

Is this a critical issue for your customer, or are they satisfied with using the xds100v3 since it does not have this issue? 

Although it is okay to debug with xds100v3, the download speed is slower than expected and the xda560 is now used for faster debugging. It would be great to find the cause.

Thanks and regards,

Cherry

Hi Cherry,

I agree that it would be great to find the cause, but this is likely not an issue with the C2000 device, but rather the XDS560 debug probe. I have asked one of the owners of the software for the XDS560 if they know what could cause this issue, but they said that they have not heard of this issue before, and they do not have time to look into the specific code, unless this is a critical issue.

Would your cusomter be open to trying a different JTAG debug probe? The XDS110 would be faster at debugging than the XDS100, with the option to set TCK frequency as high as 14MHz. The XDS200 debug probe can be set to run at 20MHz.

Best Regards,

Ben Collier