TMS320F28377D: FlashAPI doesn't work with DCSM on TMS320F28377D

Hi Oliver,

When you call the API function to program/verify, you don't get error status? If flash is not getting programmed then verify should definitely fail.

Regards,
Vivek Singh

Hi Vivek,

with the FlashAPI Verify I'll get an error. But to save massiv time on a firmware update I do the verification by a CRC and that is of course incorrect, too. 

My question is why the program routine dont write my value into the flash and why there is no error from the API.

CPU_1.Status.Process.Fapi_Status = Fapi_issueProgrammingCommand ( (Uint32 *) ( CPU_1.Status.Process.Actual_Flash_Address + (Uint32) FIRMWARE_START_ADDRESS ),
						(Uint16 *) l_Buffer, 8, 0, 0, Fapi_AutoEccGeneration );

while ( Fapi_checkFsmForReady () == Fapi_Status_FsmBusy )
	;

// Check FlashAPI status for errors
if ( CPU_1.Status.Process.Fapi_Status != Fapi_Status_Success )
{
	CPU_1.Status.Process.State = 90;
	CPU_1.Status.Error.Code = ERROR_UPDATE_PROGRAM_FAIL_CPU1;
	return;
}

On a TMX variant of the 28377D it will work fine.

Oliver,

Flash programming command checks whether 

(i) the data/ECC buffer size used by the application is within the 128-bit alignment requirement or not

(ii) the data buffer size and ECC buffer size are in sync with each other or not

If above requirements are not met, it will issue the corresponding error.  If above are correct, then the program command just issues the command and returns back.  It does not wait until the program operation is over to know the status of the program operation.  That is why you added code to wait for the FSM to complete the program operation (Fapi_checkFsmForReady).

When FSM is done with the program operation, you need to check the status of the program operation by reading the FMSTAT register.  You can use Fapi_getFsmStatus() function for this.  Try using this and check the value of FMSTAT register.  Details of FMSTAT register are provided in the description of this function in section 3.2.1 Fapi_getFsmStatus() at http://www.ti.com/lit/ug/spnu595/spnu595.pdf.

Thanks and regards,
Vamsi

Oliver,

Did you figure out the reason for the program failure in your application?

Thanks and regards,
Vamsi

Hi Vamsi,

I have to set my focus to an other project and will check your hints very soon. I will reply as fast as possible :-)

Regards

Oliver

Oliver,

I am closing this thread for now.  You can reopen it when you work on this.

Thanks and regards,
Vamsi

Hello Vamsi,

now I'm back to my problem with the flash programming compared with the activated DCSM. The FMSTAT register has set following flags:

Bit 12 - PVG -  Program verify When set, indicates that a word is not successfully programmed after the maximum allowed number of program pulses are given for program operation

Bit 4 - CSTAT - Command Status. Once the FSM starts any failure will set this bit. When set, this bit informs the host that the program, erase, or validate sector command failed and the command was stopped.  This bit is cleared by the Clear Status command. For some errors, this will be the only indication of an FSM error because the cause does not fall within the other error bit types.

Bit 4 is set because of Bit 12. But why does Bit 12 is set on the TMS variant of the DSP an not set on the TMX variant?

When I read a value from an erased flash address it shows me "0x0000" instead of "0xFFFF". I think the locked DCSM blockade the real value. But why is this working on TMX variant?

Is there something wrong with my GABSECT or GRABRAM? 

The FlashAPI is running from RAM L and the Buffer_Data for the program routine is stored in RAM Gx. All should be set to DCSM_Z1.

Regards,

Oliver

Hi Vivek,

This is it!

DcsmCommonRegs.FLSEM.all = 0xA501; // Flash semaphore DCSM Z1

This line solved the problem. Many thanks for your great support Vivek and Vamsi.

Regards,

Oliver

Glad to know issue is resolved.