tms320f28377s bootloader issues

Jan,

What are the errors that you are getting from Flash API?
What is the API that you are using? Can you tell the path in the ControlSuite?

Thanks and regards,
Vamsi

I can't get the exact messages because when i'm using the debugger everything looks fine... The API is an old one however (V170) and its refering to the tms320f28377D most of the time.
But i don't get why it's working with the debugger attached and not without ....

* So i plug in the debugger (xds100) -> connect,debug -> everything is erased
* then program the bootloader
*now my own bootloader is working, i can erase, flash again with it
* i power cycle the unit with debugger unplugged
*the bootloader starts (i can communicate and check this by a blinking led sequence)
*but the exact same programming sequence that worked previously is now giving nacks (which means the api has returned a bad value, but i can't see it directly)

Regards,
Jan

Jan,

Do you have EALLOW before calling Flash API functions?

Thanks and regards,
Vamsi

It sounds like something in the bootloader is mistakenly linked to RAM instead of flash. CCS puts it in RAM, but when you power-cycle, it is gone.

Regards,
David

Hi,
thanks for the reply. EALLOW is present. Like i said, it worked correct on the previous batch... Is there a lot of difference in flashing for TMX vs TMS processors ?

I'll look further into is in a couple of days, something has come up.

Thanks in advance
Regards
Jan

Jan,

Please use F021_API_F2837xS_FPU32.lib Flash API library for F2837xS and not F2837xD API.

Did you map the functions in Fapi_UserDefinedFunctions.c file to RAM or not?

Do you secure the device?  If yes, do you map Flash API to the same zone as that of the Flash sectors that are going to erase/program?

Also, as David suggested, please make sure that all the code is mapped to Flash and moved to RAM as needed at run time.

Thanks and regards,
Vamsi 

Hi,
sorry for the delay. I started working on the bootloader again today...
I updated the code so everything uses v200 framework at the moment and refers to f28377s api instead off f28377d but the problem remains...

* all flash related code is mapped to ramfuncs
* all flash and ram is linked to security zone 1 (and bootloader is flashed to sectorA, ramfuncs run in RAMLS3)

strange behaviour remains:
*i flash the bootloader with ccs: (erase - program - verify) -> al runs well
*after this i can communicate with my bootloader, and perform the wanted erase and flash actions (i suppose at this stage the bootloader is running and using the flash_api i compiled into my code ?)
*power cycling and it doesn't work anymore...

i've updated my bootloader to get some error codes and memory dumps and it appears that the Fapi_issueProgrammingCommand() return succes but verifying afterwards is failing. And the memory dump shows nothing has been programmed (all 0xFFFF's)...

any ideas ?
Is CCS doing some settings that ive overlooked ?

Regards
Jan

Jan,

1) How about the PLL configuration and the wait-state configuration?  When using CCS Flash Plugin to program your boot loader, CCS Plugin will configure the PLL and wait-states correctly.  Are you configuring these correctly in your application?  When debugger is connected, your application might be using the configs done by CCS Plugin and hence not failing.

2) Make sure to pass the correct system frequency (frequency at which CPU is operating) to Fapi_initializeAPI( ) function.

3) Make sure you have EALLOW before the program call.

4) Do you check the status of the Flash operation using Fapi_checkFsmForReady() before starting the next Flash operation to know whether the FSM is still busy with prior command or not?

5) Do you check the FMSTAT register using Fapi_getFsmStatus() to know if FSM operation has resulted in any of the failures?  What is the FMSTAT value after the program operation?

Thanks and regards,

Vamsi

 

Hi Vamsi,

thanks for the help

1. i run a hardware init which calls InitPLL and sets it to operate at 200MHz (20MHz crystal*20*1/2). I think this should be correct. I have a led blinking at a steady 1Hz interval so timing should be ok. After this i call InitFlash_Bank0 and InitFlash_Bank1 (copied from flash_programming_cpu01 example) and this sets the wait states to 0x03. So that looks ok to me ?

2. i have a communication handler, when i get a command to erase or flash a program block first i check its adres range and the current state of the flash and do the initialisation if needed. (FlashBank is a global variable to store the current state)

enum {bank_NotInitialized,Fbank0,Fbank1} FlashBank = bank_NotInitialized;

int SelectFlashBank(Uint32 adres)						//check en switch flash bank navenant adres
{
	uint16 range;
	if(adres < 0x80000) range = 0;
	else if (adres < 0x0C0000) range = 1;
	else if (adres <= 0x0FFFFF) range = 2;
	else range = 0;
	EALLOW;
	switch(range)
	{
	default:
	case 0: return 1;									//adres niet geldig
	case 1:
		if(FlashBank != Fbank0)							//als flash bank 0 nog niet geselecteerd was -> selecteren
		{
			ReleaseFlashPump();
			SeizeFlashPump_Bank0();
		    oReturnCheck = Fapi_initializeAPI(F021_CPU0_W0_BASE_ADDRESS, 200);
		    if(oReturnCheck != Fapi_Status_Success)	return 2;						//stoppen als geen succes
			oReturnCheck = Fapi_setActiveFlashBank(Fapi_FlashBank0);
		    if(oReturnCheck != Fapi_Status_Success)	return 3;						//stoppen als geen succes
		    FlashBank = Fbank0;
		}
		break;
	case 2:
		if(FlashBank != Fbank1)							//als flash bank 1 nog niet geselecteerd was -> selecteren
		{
			ReleaseFlashPump();
			SeizeFlashPump_Bank1();
		    oReturnCheck = Fapi_initializeAPI(F021_CPU0_W1_BASE_ADDRESS, 200);
		    if(oReturnCheck != Fapi_Status_Success)	return 2;						//stoppen als geen succes
			oReturnCheck = Fapi_setActiveFlashBank(Fapi_FlashBank1);
		    if(oReturnCheck != Fapi_Status_Success)	return 3;						//stoppen als geen succes

FlashBank = Fbank1;
		}
		break;
	}
	return 0; 											//Success
}

3. EALLOW is set

4. this is my code to erase a sector after the startadres is verified and flash sector selected:

    // Erase Sector
    oReturnCheck = Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector,startadrespointer);
    // Wait until FSM is done with erase sector operation
    while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady);
    // Verify that Sector 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(startadrespointer,lengte,&oFlashStatusWord);
    if(oReturnCheck != Fapi_Status_Success)
    	{
    	*errorcode = 4;
    	return 1;
    	}
    //hier gekomen erase = succes
    *errorcode = 0;
    return 0;

5. i don't use the FMSTAT yet, i'll try to see wath it reports

this is my code to flash a program block

    oReturnCheck = Fapi_issueProgrammingCommand((uint32 *)adres,progdata,4,0,0,Fapi_AutoEccGeneration);
    //wachten tot klaar
    while(Fapi_checkFsmForReady() == Fapi_Status_FsmBusy);
    //checken
    if(oReturnCheck != Fapi_Status_Success)
    	{
    	*errorcode = 5;
    	return 1;
    	}
    //data verifieren
    oReturnCheck = Fapi_doVerify((uint32 *)adres,2,verifydata,&oStatusWord);
    //checken
    if(oReturnCheck != Fapi_Status_Success)
    	{
    	*errorcode = 6;
    	return 1;
    	}
    *errorcode = 0;
    return 0;

This code returns with error code 6 when its failing: so it appears the flash has succeeded but the verify didn't

Also i noticed that erasing a blank sector reports succes but erasing a written sector is resulting in a timeout of my command (1000millisec timeout)....

FMSTAT reads 0x00001010 after a failed program. according to the literature this means CSTAT and PGV bit set. So program verify error...

i'm going to try to use an unlocked board to see if it has anything to do with the DCSM...
Jan

Hi,

i traced it a bit further and the issue is related with the dcsm module. So an unlocked unit has no problems with the bootloader. A locked unit can't flash or erase. with the debugger connected, the unit is unlocked, so then al works as planned.

i mapped al flash and ram to zone1 by programming
.long 0xDFFF5555 ;Z1-GRABRAM -> ram to zone1
.long 0x15555555 ;Z1-GRABSECT -> flash to zone1

i made a command to dump the SECTSTAT en RAMSTAT registers so on the locked unit this reads 0x15555555 and 0xD0005555 respectively.
This seems ok ? All ram and all flash is assigned to zone1

The linker and .map file show all flash related routines have a run adress starting from 0x8000 (i took LS0,LS1,LS2 and LS3 together as secure RAM for ramfuncs).

So what could possibly be wrong ?...

Thanks for your help

regards
Jan

Jan,

Based on your replies, looks like the PLL configuration, wait-state configuration and the API initialization are correct.

FMSTAT clearly tells that the program operation did not succeed.

I don't see any issue with your code that you posted.

I will ask our security expert to take a look in to this.

Thanks and regards,
Vamsi

Hi Vivek and Vamsi,
thanks a lot for the help. This last post solved the issue.

May i suggest updating the code examples in controlsuite ?
Because the blinky_with_dcsm example doesn't refer to this register because it doesn't handle flashing while in secure zone.
And the flash_programming_cpu01 example doesn't refer to it either because it hasn't got dcsm setup.

Also, reading the technical reference suggests this register is reset at value 0 which means "00 : C28X Flash Wrapper registers can be written by code runningfrom anywhere without any restriction" . So i wouldn't expect any problems with this...

Thanks again for the help. I wouldn't have solved this one without you.

Regards
Jan

Jan,

Thank you for your feedback. We'll update the document to make it more clear.

Regards,

Vivek Singh