TMS320F280040-Q1: fail to flash the program

Crane,

Does this occur on a fresh device from TI, or on a previously programmed device?

Best,
Matthew

Hi Matthew, 

This happens on a previously programmed device.

And it is find to flash using uniflash tool.

Regards,

Crane

Crane,

Is is possible for you to change the boot mode to "wait boot" GPIO24 = 0 and GPIO32 = 1, power cycle the device and try to connect/program again?  Sometimes if the device is in a secure memory region when the emulator attempts to connect it will get blocked.  If this works, it would indicate that is the issue.

Best,

Matthew

Hi Matthew,

Tried wait boot and the result is the same.

Regards,

Crane

Crane,

Is this a standalone install of Uniflash or the cloud based version?  Also, are you using the GUI to initiate the programming or command line?  I'm not sure why the Uniflash would not connect before attempting the flash programming, I'm not sure this is possible in the GUI side.

Best

Matthew

Hi Matthew,

This is a standalone Uniflash. 

Yes, I am using CCS GUI to initiate the programming as I always did.

I mean Uniflsh is working to flash. But CCS is not working to flash.

Thanks!

Crane

Crane Shao said:

Hi Matthew,

Tried wait boot and the result is the same.

Regards,

Crane

Hi Matthew,

To correct the reply, the way I tried wait boot mode is actually probably not really is. It probably still boots from FLASH (both pin are connected to 1 at the moment the power is applied.)

It will be very hard to try wait boot as I need to modify the PCB. Would it really locate the issue as it worked to flash this project before and even still works to flash other project on the same board?

Thanks!

Crane

Hi Matthew,

One question is where in my code to put the password match flow. I tried to put it before and after the device init function. In both tries, I got the same result as before.

MatthewPate said:

it is dependent on where your code is executing from when the debugger attempts to connect.

If it is like that, what might affect where the code is executing so that I can make the change to see the difference?

As it worked before for this project, still works for other project, I suspect it should be something that is specific to this project and can be modified in CCS.

Thanks!

Crane

Crane,

Thanks for trying this out, I should have added if you do not have any passwords programmed, you can comment out the *CSM++ = lines of code, since the for loop will unlock.  

Can you confirm if you are using the CSM passwords in your application?  If not, can you comment out those later lines and try it again?  I think the key would be to unlock as early as possible in your code.

I suppose all of this assumes the CSM blocking the debugger connection is the issue, if you are able to add some debug code to your project you could force the execution to be in an unsecure memory, like GSx RAM(maybe just looping forever) and see if CCS ever gives an error connecting; if there is still some issue I'll need to think why this would be.

Best,

Matthew

Hi Matthew,

I don't think I am using the CSM passwords as I don't know how to use it.

I tried using the code below and the result remains the same.

void deviceUnlock(void)
{
    volatile long int *CSM = (volatile long int *)0x5F010; //CSM register file
    volatile long int *CSMPWL = (volatile long int *)0x78028; //CSM Password location (assuming default Zone select block)
    volatile int tmp;
    int I;
    // Read the 128-bits of the CSM password locations (PWL)
    //
    for (I=0;I<4; I++) tmp = *CSMPWL++;
    // If the password locations (CSMPWL) are all = ones (0xFFFF),
    // then the zone will now be unsecure. If the password
    // is not all ones (0xFFFF), then the code below is required
    // to unsecure the CSM.
    // Write the 128-bit password to the CSMKEY registers
    // If this password matches that stored in the
    // CSLPWL then the CSM will become unsecure. If it does not
    // match, then the zone will remain secure.
    // An example password of:
    // 0x11112222333344445555666677778888 is used.
//    *CSM++ = 0x22221111; // Register Z1_CSMKEY0 at 0x5F010
//    *CSM++ = 0x44443333; // Register Z1_CSMKEY1 at 0x5F012
//    *CSM++ = 0x66665555; // Register Z1_CSMKEY2 at 0x5F014
//    *CSM++ = 0x88887777; // Register Z1_CSMKEY3 at 0x5F016
}

void boardInit(void)
{
    // unlock the device to avoid flashing error
    deviceUnlock();

    // Initialize device clock and peripherals
    Device_init();

    // Disable pin locks and enable internal pullups.
    Device_initGPIO();

    // Initialize PIE and clear PIE registers. Disable CPU interrupts.
    Interrupt_initModule();

    // Initialize the PIE vector table with pointers to the shell Interrupt Service Routines (ISR)
    Interrupt_initVectorTable();

    // Board Initialization
    DEVICE_DELAY_US(1000000);
    Board_init();

    // initialize CPU timer
    cpuTimerInit();
}

Since the error is "Texas Instruments XDS2xx USB Debug Probe_0/C28xx_CPU1 : Target must be connected before loading program.", which means the program isn't flashed yet. This way, would the code get the chance to run?

Thanks!

Crane

Crane, please give me another day to look into this.

Hi Matthew,

One update: I found from other projects that the copied project not working while the original project works fine to be programmed.  The issues are the same. Any thought on that?

Thanks!

Crane