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.

TMS320F28030: Flash programing config

Expert 1190 points

Part Number: TMS320F28030

Using a xds100,  is it required that pins gpio 12 and 17 be shorted to gnd that TRST be pulled high

  • GPIO12 and GPIO17 are not related to TRSTn pin. So, I don't understand why you need to short these pins to ground for TRSTn.

    This question may be better answered with proper context. Please give details about your board? Is it a custom board (or) TI board?
  • With a custom PCB and a xds100, does the device need to be configure to program flash, if so how?
  • If you trying to program flash using JTAG / CCS, no configuration is required.
  • power cycling the device, the device behaves as if it's not programed, why is this the case
  • Programming flash doesn't require any configuration. But, if you want to run the device in standalone mode, you need to configure the device to boot to flash.

    processors.wiki.ti.com/.../FAQs
  • Do GPIO12 and GPIO17 need to be defined when downloading to flash or running from flash (standalone)
    thanks
  • To run this device in standalone, you need to pull both GPIO34, GPIO37 high.
  • if the pin has been allocated as a output, can it be pulled high with a resistor, then be used as a gpio
  • Yes, you can have pull up. But, make sure to have weak pull up.
  • can the internal pull up used rather than external
  • The internal pullup resistors are enabled at reset for the boot mode selection pins. It is still suggested that the boot mode configuration be made externally to avoid the effect of any noise on these pins.

    Regards,
    Manoj
  • Hi Manoj, 4.7k pull ups were added to both pins. of the 7 custom boards, one I was not able to flash. What should I check for?
    The control board use a switch to enable the pull up.

    What other items should I check?
  • JW,

    It is good to know that you were able to program (6 out 7 devices) the flash and run your application code running standalone.

    On the board which had flash programming problem, what was the error message reported?

    As I mentioned before in this post, to program flash in CCS you don't need any GPIO configuration. But, if you are trying to run standalone, you need pull up on GPIO34/37.

    Regards,
    Manoj
  • HI Mark the reported error is a flash.out load failure.
  • Did you already try another .out file? Are you able to program another .out file into flash?
  • HI Manoj, after power up, GPIO37 and GPIO 34 are high (20K resistor) and TRST is high. If TRST is then shorted, then the device boots correctly and the firmware behaves as expected.

    At power up, If GPIO37 and GPIO 34 are pulled hi and TRST is low the device does load the initialized values and misbehaves.

    My understanding, is when TRST is low (at power up) the device will read the GPIO and boot from flash and that the
    Ram would be initialized.

    What did I miss?

    thanks
  • JW,

    When JTAG is connected (TRSTn = 1) then it follows emulation boot, the state of GPIO34 / GPIO37 doesn't matter. But when JTAG is disconnected (TRSTn = 0), state of GPIO34 / GPIO37 affects the boot mode selection.

    If GPIO34 = GPIO37 = 1 & TRSTn = 0, on powerup the code starts executing from flash after BOOTROM code is executed.

    Regards,
    Manoj
  • Hi Manoj, this does not make much sense so bare with me.

    At power up JTAG not connected GPIO34 = GPIO37 = 1 & TRSTn = 1.
    After power up JTAG not connected GPIO34 = GPIO37 = 1 & TRSTn = 0, where TRST is shorted to ground, it perform as expected.
    What do you think?

    btw this is a custom board,
  • I'm sorry, I didn't understand your argument. Please re frame the question differently.

    Can you clarify whether you were able to successfully program flash? I believe the problem is only with code executing from flash when JTAG is connected.

    Regards,
    Manoj
  • I can program the flash. To boot from flash I short the TRSET.
    the sequence of steps:

    1. power on system
    2. GPIO34 = GPIO37 = 1 & TRSTn = 1
    3. wait ~5sec's
    4. short TRST to Ground GPIO34 = GPIO37 = 1 & TRSTn = 0.
    5. Boot from flash and excludes source code.

    6. Send test script Pass

    Test 2

    1 short TRST to Ground  GPIO34 = GPIO37 = 1 & TRSTn = 0

    2.  power on system 
    3. wait ~5sec's 
    5. Send test script Fails


     In case 1  shorting  TRST  to ground  5 sec after power is applied,  pass.

     In case 2 shorting  TRST  to ground before power is applied,  fails

    .

    thanks
    Is this normal behavior?

    thanks

  • JW,

    Why do you want the emulator connected (TRSTn) when you are running in standalone mode? You need emulator connected only during programming / development / debug session.

    For running in standalone mode, you just need to do the following:-

    1) Set weak pull-up on GPIO34 = GPIO37 and weak pull down on TRSTn = 0
    2) Power-on the system. This will automatically run the application code in flash.

    Regards,
    Manoj
  • Hi the emulator is not connected, I need to get through this issue  may I contact you directly

  • JW,

    No, this is not normal behavior.

    Case 2 should be able to run your application code in standalone mode. Case 1 really doesn't make sense to me. Also, I don't see why you have to wait for 5 secs. Is 5 secs a timeout condition before we call a test failed?

    Regards,

    Manoj

  • the time is arbitrary, I can wait 5 sec or 10mins the results are the same.

     starts in stand alone mode
    "Set weak pull-up on GPIO34 = GPIO37 and weak pull down on TRSTn = 0", the codes does not run correctly

    Starts emulation mode  then transition to stand alone mode
    "Set weak pull-up on GPIO34 = GPIO37 and weak pull down on TRSTn = 1", wait, the codes runs correctly.

    In all cases  the emulator is disconnected
     
    suggestions where to look

  • I don't see how "Starts emulation mode then transition to stand alone mode" works. It doesn't make any sense. Only think I could think of is noise on these pins.

    Regards,
    Manoj
  • Hi, the TRST is being read after startup, Can the issue be in the CMD file?


    MEMORY
    {
    PAGE 0: /* Program Memory */
    /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE1 for data allocation */

    RAML0 : origin = 0x008000, length = 0x000800 /* on-chip RAM block L0 */
    RAML1 : origin = 0x008800, length = 0x000400 /* on-chip RAM block L1 */
    OTP : origin = 0x3D7800, length = 0x000400 /* on-chip OTP ONE TIME PROGRAMABLE MEMORY*/

    FLASH : origin = 0x3E8000, length = 0x00FF80 /* FLASH, All sectors combined */
    CSM_RSVD : origin = 0x3F7F80, length = 0x000076 /* Part of FLASHA. Program with all 0x0000 e. */
    BEGIN_FLASH : origin = 0x3F7FF6, length = 0x000002 /* Part of FLASHA. Used for "boot to Flash */
    CSM_PWL_P0 : origin = 0x3F7FF8, length = 0x000008 /* Part of FLASHA. CSM password locations in */

    IQTABLES : origin = 0x3FE000, length = 0x000B50 /* IQ Math Tables in Boot ROM */
    IQTABLES2 : origin = 0x3FEB50, length = 0x00008C /* IQ Math Tables in Boot ROM */
    IQTABLES3 : origin = 0x3FEBDC, length = 0x0000AA /* IQ Math Tables in Boot ROM */

    ROM : origin = 0x3FF27C, length = 0x000D44 /* Boot ROM */
    RESET : origin = 0x3FFFC0, length = 0x000002 /* part of boot ROM */
    VECTORS : origin = 0x3FFFC2, length = 0x00003E /* part of boot ROM */


      */
    RAMM2 : origin = 0x008C00, length = 0x000400 /* on-chip RAM block L2 */
    RAML3 : origin = 0x009000, length = 0x001000 /* on-chip RAM block L3 */
    FLASHB : origin = 0x3F4000, length = 0x002000 /* on-chip FLASH */

    }

     

  • Well, I'm not sure.

    Can you try the following:-

    1) Connect to the device
    2) Set PC to 0x3F7FF6
    3) Hit run and see whether your code executes as expected.

    Regards,
    Manoj
  •  Entered 0x3F7FF6,  result: at  0x3F7FF6

     jumped to InitSysCtrl()

    jumped to Intro0clDel()

    jump to Initperipherial clock

    Jump to GPIO initPie vector table

    Jump to initCpu Timer

    Using the debugger it executes as expected

    Does the  In scripts "EMU mode"  dose the EMU mode need to be selected?

    Do I need to be concern about the GEL See below:

     if (GEL_IsInRealtimeMode())   /* If in real-time-mode */
        {
        }
        else    /* Put device in C28x mode */
        {
             C28x_Mode();
        }
        Unlock_CSM();
        Device_Cal();
        CLA_Clock_Enable();             /* Enable CLA clock - allows the debugger to set CLA breakpoints after reset */
    //  Uncomment for the desired boot-mode on a reset:   
    //    EMU_BOOT_SARAM();           /* Set EMU Boot Variables - Boot to SARAM */
      //  EMU_BOOT_FLASH();           /* Set EMU Boot Variables - Boot to flash */
    }

  • JW,

    If my previous suggestion worked (meaning your application code worked as expected), then Case 2 condition should work as it is.

    Gel script affects boot rom code execution only when device is connected to CCS and not when running in standalone.

    Please use the below reference material to get further debug tips.

    www.ti.com/.../spra958l.pdf

    processors.wiki.ti.com/.../FAQs

    Regards,
    Manoj
  • JW,

    By any chance have you programmed OTP_KEY / OTP_BMODE?

    Regards,
    Manoj
  • I have not programed the OTP_KEY/OTP_MODE.

    in case 1: The data received through the SPI is off by one bit causing the failure.

    ISR code :
    iSpiRxData = SpiaRegs.SPIRXBUF; // Read data
    iSpiRxDataFlag = TRUE;

    SpiaRegs.SPIFFRX.bit.RXFFOVFCLR=1; // Clear Overflow flag
    SpiaRegs.SPIFFRX.bit.RXFFINTCLR=1; // Clear Interrupt flag
    PieCtrlRegs.PIEACK.all|=0x20; // Issue PIE ack
  • JW,

    Case 2 is what you need to run application in standalone mode. So, I would recommend you to debug case2 instead of case1.

    Regards,
    Manoj
  • JW,

    Is this issue resolved? Can I close this thread?

    Regards,
    Manoj