TMS320F2812: ms320f2812ghha issue

Aosker,

Are you saying that the Uniflash is not able to connect to the device successfully?  How are the boot mode pins configured?  Hope you are using wait or serial boot.

Which version of Uniflash and CCS are you using?  Which emulator are you using?  Hope you checked for updates and installed them if any.  Please confirm.

Thanks and regards,

Vamsi

customer reply:

We are using the TMS320 with boot mode “Jump to flash address” since we have the GPIOF4 connected to the driver input of a ISL3298EFRTZ-T (rs-422 transmitter) and the datasheet of the TMS320 says that pin (GPIOF4) has an internal pullup so the other three pins should be ignored.

Both uniflash (v6.1) and ccs as I try to program the device say that it's locked or not connected but the fun fact is that with the memory browser of ccs I can still read all the registers and also verify the Jtag chain correctly (maybe I'll try the --mode memory option of uniflash)

For some reason could the dps enter the boot mode with psw?

Another hint that came in my mind is that the pin n D6 (nXRS) is connected to a watchdog that resets the dsp; this process can be stopped only after programming the fpga.

I checked this signal and everything is ok but I was wondering if a disturb on this pin during the programming could lock the device is such strange mode.

ps: it doesn't always happen because I worked with a lot of boards, but only on 3/10 board; it's too expensive changing always the tms to make it work.
I need to find out what is going on.

Aosker,

On the devices where you are not able to program, when you open the flash space in the CCS memory window, what values do you see?  All 0s?

When connected to CCS, can you check if the passwords are programmed in to CSM password space?

Regarding the XRSn:  Please make sure a reset does not happen during flash operations - it can potentially lock up the device.

Thanks and regards,

Vamsi

Hi Vamsi,

I tried to open the memory window and I couldn't all the registers, the one's that are secure blocked are all 0s.

All addresses between 0x3F 7F80 and 0x3F 7FF5 are 0s and also from 0x3F 7FF8 to 0x3F 7FFF.

The thing I would like to undestrand is why should this device enter the psw locked boot if GPIOF4 is at logic level high? 

Hi Vamsi,

As we don't use the pass, I think the second scenario is more likely to occur but I wanted to ask one last thing: In a device with a corrupted flash, can I run a code in RAM? Because even if I try to load something in ram (in the debug option load ram) it says that it's locked...why is it stopping me from loading in ram too? do I have to change the boot mode in saram or something else?

Thank you very much for the support.

Hi Matteo,

You can load in to unsecured RAM.  Maybe you are trying to load to secured RAM - please check.

Thanks and regards,
Vamsi

Hi Vamsi,

yes I am, here it is the boot rom linker file:

/*************************************************
 F2812 Boot Rom Linker File
**************************************************/

MEMORY
{
PAGE 0 : 
	M0SARAM		  : origin = 0x000040, length = 0x0003C0
    L0SARAM       : origin = 0x009000, length = 0x001000     /* 4Kw L1 On-Chip SARAM */
    VERSION       : origin = 0x3F6000, length = 0x000002
	FLASHA_ON_CHIP: origin = 0x3F8000, length = 0x001C00     /* FLASHA_ON_CHIP is H0SARAM */    
	CSM_RSVD	  : origin = 0x3F7F80, length = 0x000076
	ENTRY_POINT	  : origin = 0x3F7FF6, length = 0x000002
	PASSWORD	  : origin = 0x3F7FF8, length = 0x000008
    RESET         : origin = 0x3FFFC0, length = 0x000002     /* part of Boot ROM (MP/MCn=0) or XINTF zone 7 (MP/MCn=1) */
    EXT_FLASH     : origin = 0x100000, length = 0x080000    /* external flash memory */

PAGE 1 :
	STACK		  : origin = 0x000400, length = 0x000400
    DEV_EMU       : origin = 0x000880, length = 0x000180    /* device emulation registers */
    FLASH_REGS    : origin = 0x000A80, length = 0x000060    /* FLASH registers */
    PIE_CTRL      : origin = 0x000CE0, length = 0x000020    /* PIE control registers */
    XINTF         : origin = 0x000B20, length = 0x000020    /* external interface registers */
    PIE_VECT      : origin = 0x000D00, length = 0x000100    /* PIE Vector Table */
    SYSTEM 		  : origin = 0x007010, length = 0x000020
    SPIA          : origin = 0x007040, length = 0x000010    /* SPI registers */
    SCIA          : origin = 0x007050, length = 0x000010    /* SCI-A registers */
    GPIOMUX       : origin = 0x0070C0, length = 0x000020    /* GPIO mux registers */
    GPIODAT       : origin = 0x0070E0, length = 0x000020    /* GPIO data registers */
	EXT_RAM		  : origin = 0x080000, length = 0x020000    /* 128Kw external RAM in Xintf2 */
	H0DSARAM	  : origin = 0x3F9C00, length = 0x000400
    IRQ_PBUS_ARINC: origin = 0x0030D0, length = 0x000001    /* Pbus and Arinc interrupt on FPGA */
/*	FLASH_PAGE	  : origin = 0x003120, length = 0x000001	/* Flash Page selection register */
	FLASH_PAGE	  : origin = 0x0029B0, length = 0x000001	/* Flash Page selection register */

}
 
SECTIONS
{
   .text        	: > FLASHA_ON_CHIP,	PAGE = 0
   .reset       	: > RESET,          PAGE = 0, TYPE = DSECT  /* We are not using the .reset section */
   .cinit       	: > FLASHA_ON_CHIP,  PAGE = 0
   .econst          : > FLASHA_ON_CHIP,  PAGE = 0      
   .Version     	: > VERSION, 		PAGE = 0
   .InitBoot    	: > L0SARAM,		PAGE = 0
   codestart		: > ENTRY_POINT,    PAGE = 0
   passwords		: > PASSWORD,		PAGE = 0
   csm_rsvd			: > CSM_RSVD,		PAGE = 0
   internalMemFuncs : > L0SARAM,  PAGE = 0            /* Used by file Xintf.c.  Link to internal memory. */

   copysection		: > M0SARAM,		PAGE = 0

   .bss             : > H0DSARAM,        PAGE = 1
   .ebss        	: > H0DSARAM,        PAGE = 1
   .switch        	: > L0SARAM,        PAGE = 0
   .stack			: > STACK,			PAGE = 1

   FlashRegsFile    : > FLASH_REGS,  	PAGE = 1
   PieCtrlRegsFile  : > PIE_CTRL,    	PAGE = 1      
   XintfRegsFile    : > XINTF,       	PAGE = 1
   DevEmuRegsFile   : > DEV_EMU,     	PAGE = 1
   SysCtrlRegsFile  : > SYSTEM,      	PAGE = 1
   SpiaRegsFile     : > SPIA,           PAGE = 1
   GpioMuxRegsFile  : > GPIOMUX,     	PAGE = 1
   GpioDataRegsFile : > GPIODAT,        PAGE = 1
   BufferCopyFile   : > EXT_RAM,		PAGE = 1
   SCIARegsFile     : > SCIA,           PAGE = 1
   IrqPbusArincFile : > IRQ_PBUS_ARINC, PAGE = 1
   FlashPageRegFile : > FLASH_PAGE,		PAGE = 1
   PieVectTableFile : > PIE_VECT,   PAGE = 1

   
   Flash28_API:
   {
		-lFlash2812_API_V210.lib(.econst)
		-lFlash2812_API_V210.lib(.text)
   }	LOAD = L0SARAM,
		RUN = L0SARAM,
		LOAD_START(_Flash28_API_LoadStart),
		LOAD_END(_Flash28_API_LoadEnd),
		RUN_START(_Flash28_API_RunStart),
		PAGE = 0


   FlashFuncs    	:    LOAD = FLASHA_ON_CHIP, PAGE = 0
                         RUN = L0SARAM,        PAGE = 0 
                         LOAD_START(_FlashFuncs_loadStart),
                         LOAD_END(_FlashFuncs_loadEnd),
                         RUN_START(_FlashFuncs_runStart)


	ramfuncs		:  	 LOAD = FLASHA_ON_CHIP, PAGE = 0
						 RUN  = L0SARAM, 		PAGE = 0
                         LOAD_START(_ramfuncs_loadStart),
                         LOAD_END(_ramfuncs_loadEnd),
                         RUN_START(_ramfuncs_runStart)

}

Hi Matteo,

If the device is locked, you will not be able to load to secure RAM without unlocking it with the password.

Thanks and regards,

Vamsi

Hi Vamsi,

I see, I'm sorry if I bothered you but I must find a solution to avoid this.

I would be grateful If you could assign my case to a security expert as you said before.

Thank you very much Vamsi for your support,

Matteo

Hi Matteo,

No, you did not bother me at all.  

I assigned this to our security expert. 

Thanks and regards,
Vamsi

Matteo,

I want to go back a few posts, where you mentioned an external watchdog that can pull XRSn.  As Vamsi mentioned, if this occurs during flash programmation or erase operations there is a chance that the CSM password(in the last 8 words of sector A) get set to a non 0xFFFF state.

Is it possible to ensure this external watchdog doesn't interrupt the flash process(which likely takes longer than the typical time out window you would use during normal running).

There are other scenarios like power loss that will also cause this, if they happen during the flash programming.

Some other recommendations to limit the chance of this writing to the CSM, would be to not update sector A and H as much as possible.  So that if you have FW that will be updated, put it in the other 6 sectors if possible.

Will look for your feedback on the above and we can debug some more.

Best,

Matthew

Hi Matthew,

thanks for answering, there's anything I can do to save the device? Maybe mass erasing or something?

Matthew, Vamsi,

I see, thank you very much for the support.

Have a good day!

Matteo