This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TMS320F28075: Z1/Z2-BOOTCTRL programming

Part Number: TMS320F28075

Tool/software: Code Composer Studio

I have programmed the Z1 and Z2 BOOTCTRL registers. The Z1 register is 0x5555FF5A.

I wish to change the value to 0x55550B5A.

So I need to zero bits, not set them but CCS will not let me do this.

Is there a way to do this. I guess CCS refuses as the register start value is not 0xFFFFFFFF.

Could I write my own software to do this - can you direct me to some example code ?

Thanks!

Peter Walker.

  • Hi Peter,

    Please take a look at the literature related to the device you are using here:
    www.ti.com/.../spruhm9e.pdf

    Please see Section 4.3 entitled Device Boot Modes. Also see the Default boot modes described Table 4-3 and the related GPIO72 and GPIO84 configurations.

    Hope that helps you debug the issue. If it does not please describe the target configuration in detail so that we can help you further.

    Regards,
    Krishna
  • Hi Krishna,
    Thank you for the reply. Our TMS320F28075 will not boot from flash in its default configuration. When Z1 and Z2 BOOTCTRL registers are left at factory default, then the processor does not boot from flash. The boot mode pins are the default GPIO72 and GPIO84.
    If we plug in the XDS200 emulator connection after trying to start it standalone and use the Code Composer debugger to connect and then disconnect (no software load) then the processor starts to execute the code (a debug led starts to flash).
    We are using 10K pull up resistors on the boot pins GPIO72 and GPIO84. Do these need to be lower ?
    Any suggestions as to how to fix this are welcome - we just need it to boot from flash by any means possible.
    Thanks!
    PW.
  • Hi Peter, Thanks for additional details. Looks like the state of the boot mode pins is not getting recognized. Please confirm that both pins are high. It is possible that the 10K value is too high. I will confirm but in the mean time you may try a much smaller value.
    Cheers!
    Krishna
  • Hi Krishna,

    We have tried the Texas Blinky example program. This will boot standalone on our hardware. So it seems it is some form of hardware configuration when the device is programmed. The Blinky map shows a .reset section at 0x003FFFC0 of length 2 which is of type DSECT which means it is a dummy section and is not included in the output section memory allocation (see SPRU513P section 8.5.9). So this may be having some impact but we do not understand why at the moment. Can you tell us the function of this section ?

    PW.

  • Hello

    I apologize for the delay, Krishna is out of office. 0x3FFFC0 is the reset vector where PC will go upon reset and then from there run the boot up code.

    There will be boot differences if you have a debugger connected vs when you don't. These are detailed in the technical reference manual.
    You can refer to the blinky with DCSM example for programming OTP.

    Best regards
    Chris
  • Solution to this problem:

    The debugger enables the CLA clock which by default is disabled when the processor starts.

    So if the code does not enable the CLA clock then the omission will not be apparent while executing under the debugger.

    But when an attempt is made to run the code standalone, it will not run due to no CLA clock - the default condition.

    But tests under the debugger all pass and the code runs!

  • Thanks for the update, glad it is now working!

    Best regards
    Chris