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.

TMS320F28388D: TMS320f28388D

Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE

Tool/software:

Hi Good Morning,

We are using TMS320f28388d development board for our one of the projects. Among all three cores we have assigned Ethercat to the CM core.

Here We are updating the Firmware using FOE (Firmware upgrade over Ethercat) and for this we have implemented customised bootloader for all three cores. Bootloader is responsible for receiving firmware file from twincat and programming to the internal flash of each cores.

Also we have implemented reset command, Twincat sends Resent command through SDO, whenver reset command receives The CM core will send this command to CPU1 and later CPU1 will enable watch dog timer to reset the cores.

Here whenever CPU1 triggers Watch dog timer to reset the cores, CPU1 gets booted and able to issue Boot command for both CPU2 and Cm core.

SO in the above process, we are seing that whenever CPU1 resets and brings CM out of reset, in some cases CM is not able to come out of Reset.

I tried to debug and could not succeed, will you please help us to resolve this.

Here i have attached the startup file.

//#############################################################################
//
// FILE:   startup_cm.c
//
// TITLE:  Cortex M4 Family Interrupt Vector Table for CGT.
//
//#############################################################################
//
//
// $Copyright:
// Copyright (C) 2022 Texas Instruments Incorporated - http://www.ti.com
//
// Redistribution and use in source and binary forms, with or without 
// modification, are permitted provided that the following conditions 
// are met:
// 
//   Redistributions of source code must retain the above copyright 
//   notice, this list of conditions and the following disclaimer.
// 
//   Redistributions in binary form must reproduce the above copyright
//   notice, this list of conditions and the following disclaimer in the 
//   documentation and/or other materials provided with the   
//   distribution.
// 
//   Neither the name of Texas Instruments Incorporated nor the names of
//   its contributors may be used to endorse or promote products derived
//   from this software without specific prior written permission.
// 
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
// $
//#############################################################################

#include <stdint.h>

//
// Forward declaration of the default fault handlers.
//
static void resetISR(void);
static void nmiISR(void);
static void faultISR(void);
static void defaultISR(void);

//
// External declaration for the reset handler that is to be called when the
// processor is started     
//                                               
extern void _c_int00(void);

//
// Linker variable that marks the top of the stack.
//
extern unsigned long __STACK_END;

// External declarations for the interrupt handlers used by the application.
// To be added by user
extern void lwIPEthernetIntHandler(void);
extern void SysTickIntHandler(void);
extern void Ethernet_genericISRCustom(void);
//
// Interrupt vector table. In the RAM variant, the vectorTableRAM is used and 
// in the Flash variant, the vectorTableFlash is used. The Flash variant can be
// be used when memory is a concern and the RAM variant can be used when 
// speed is a concern.
//                          
#ifdef _FLASH
#pragma RETAIN(vectorTableFlash)
#pragma DATA_ALIGN(vectorTableFlash, 1024U)
#pragma DATA_SECTION(vectorTableFlash, ".vftable")
void (* const vectorTableFlash[])(void) =
#else
#pragma RETAIN(vectorTableRAM)
#pragma DATA_ALIGN(vectorTableRAM, 1024U)
#pragma DATA_SECTION(vectorTableRAM, ".vtable")
void (* const vectorTableRAM[])(void) =
#endif
{
    (void (*)(void))((uint32_t)&__STACK_END),
                                            /* The initial stack pointer */
    resetISR,                               /* The reset handler         */
    nmiISR,                                 /* The NMI handler           */
    faultISR,                               /* The hard fault handler    */
    defaultISR,                             /* The MPU fault handler     */
    defaultISR,                             /* The bus fault handler     */
    defaultISR,                             /* The usage fault handler   */
    0,                                      /* Reserved                  */
    0,                                      /* Reserved                  */
    0,                                      /* Reserved                  */
    0,                                      /* Reserved                  */
    defaultISR,                             /* SVCall handler            */
    defaultISR,                             /* Debug monitor handler     */
    0,                                      /* Reserved                  */
    defaultISR,                             /* The PendSV handler        */
    defaultISR,                             /* The SysTick handler       */
    defaultISR,                             /* MCANSS_0 handler          */
    defaultISR,                             /* MCANSS_1 handler          */
    defaultISR,                             /* MCANSS_WAKE_AND_TS_PLS ISR*/
    defaultISR,                             /* MCANSS_ECC_CORR_PLS ISR   */
    defaultISR,                             /* Reserved                  */
    defaultISR,                             /* ECAT ISR                  */
    defaultISR,                             /* ECAT_SYNC0 ISR            */
    defaultISR,                             /* ECAT_SYNC1 ISR            */
    defaultISR,                             /* ECAT_RST ISR  ISR         */
    defaultISR,                             /* CANA0 ISR                 */
    defaultISR,                             /* CANA1 ISR                 */
    defaultISR,                             /* CANB0 ISR                 */
    defaultISR,                             /* CANB1 ISR                 */
    defaultISR,                             /* EMAC ISR                  */
    defaultISR,                             /* EMAC_TX0 ISR              */
    defaultISR,                             /* EMAC_TX1 ISR              */
    defaultISR,                             /* EMAC_RX0 ISR              */
    defaultISR,                             /* EMAC_RX1 ISR              */
    defaultISR,                             /* UART0 ISR                 */
    defaultISR,                             /* Reserved                  */
    defaultISR,                             /* SSI0 ISR                  */
    defaultISR,                             /* Reserved                  */
    defaultISR,                             /* I2C0 ISR                  */
    defaultISR,                             /* Reserved                  */
    defaultISR,                             /* USB ISR                   */
    defaultISR,                             /* UDMA_SW ISR               */
    defaultISR,                             /* UDMA_ERR ISR              */
    defaultISR,                             /* Reserved                  */
    defaultISR,                             /* Reserved                  */
    defaultISR,                             /* CPU1TOCMIPC0 ISR          */
    defaultISR,                             /* CPU1TOCMIPC1 ISR          */
    defaultISR,                             /* CPU1TOCMIPC2 ISR          */
    defaultISR,                             /* CPU1TOCMIPC3 ISR          */
    defaultISR,                             /* CPU1TOCMIPC4 ISR          */
    defaultISR,                             /* CPU1TOCMIPC5 ISR          */
    defaultISR,                             /* CPU1TOCMIPC6 ISR          */
    defaultISR,                             /* CPU1TOCMIPC7 ISR          */
    defaultISR,                             /* CPU2TOCMIPC0 ISR          */
    defaultISR,                             /* CPU2TOCMIPC1 ISR          */
    defaultISR,                             /* CPU2TOCMIPC2 ISR          */
    defaultISR,                             /* CPU2TOCMIPC3 ISR          */
    defaultISR,                             /* CPU2TOCMIPC4 ISR          */
    defaultISR,                             /* CPU2TOCMIPC5 ISR          */
    defaultISR,                             /* CPU2TOCMIPC6 ISR          */
    defaultISR,                             /* CPU2TOCMIPC7 ISR          */
    defaultISR,                             /* FMC ISR                   */
    defaultISR,                             /* FMC_CORR_ERR ISR          */
    defaultISR,                             /* AES Interrupt ISR         */
    defaultISR,                             /* TIMER0 ISR                */
    defaultISR,                             /* TIMER1 ISR                */
    defaultISR,                             /* TIMER2 ISR                */
    defaultISR,                             /* CMRAM_TESTERROR_LOG ISR   */
    defaultISR,                             /* Reserved 52               */
    defaultISR,                             /* Reserved 53               */
    defaultISR,                             /* Reserved 54               */
    defaultISR,                             /* Reserved 55               */
    defaultISR,                             /* Reserved 56               */
    defaultISR,                             /* Reserved 57               */
    defaultISR,                             /* Reserved 58               */
    defaultISR,                             /* Reserved 59               */
    defaultISR,                             /* Reserved 60               */
    defaultISR,                             /* Reserved 61               */
    defaultISR,                             /* Reserved 62               */
    defaultISR                              /* Reserved 63               */
};

//
// This is the code that gets called when the processor first starts execution
// following a reset event. 
// Any actions (such as making decisions based on the reset cause register,    
// and resetting the bits in that register) are left solely in the hands of    
// the application.
//                                                               
#pragma RETAIN(resetISR)
#pragma CODE_SECTION(resetISR, ".resetisr")
void resetISR(void)
{
    //
    // Jump to the CCS C Initialization Routine.
    //
    __asm("    .global _c_int00\n"
          "    b.w     _c_int00");
}

//
// This is the code that gets called when the processor receives a NMI.  This 
// simply enters an infinite loop, preserving the system state for examination
// by a debugger. 
//                                                            
static void nmiISR(void)
{
    //
    // Enter an infinite loop.
    //
    while(1)
    {
    }

}

//
// This is the code that gets called when the processor receives a fault       
// interrupt.  This simply enters an infinite loop, preserving the system state
// for examination by a debugger. 
//                                             
static void faultISR(void)
{
    //
    // Enter an infinite loop.
    //
    while(1)
    {
    }

}

//
// This is the code that gets called when the processor receives an unexpected 
// interrupt.  This simply enters an infinite loop, preserving the system state
// for examination by a debugger.    
//                                          
static void defaultISR(void)
{
    //
    // Enter an infinite loop.
    //
    while(1)
    {
    }
}

  • Hi,

    Please allow me to get back to you in a day or two.

    Thanks,

    Ben Collier

  • Hi,

    Are you using the Device_bootCM() function on CPU1? Does CPU1 get stuck in that function? 

    Thanks,

    Ben Collier

  • Hi Benjamin Coller,

    Yes iam using the Device_bootCM() function in CPU1.

    No CPU1 never stuck in this function, CPU1 is executing this function all the time.

    please find the code snippet attached here for the same.

     

  • What is the warning that CCS is reporting on that line? 

    This function should wait until CM is out of reset.

    Best Regards,

    Ben Collier

  • There is no warning on that line.

    Yes, I verified that this is waiting until CM is out of reset.

    The problem is coming when we do soft reset to the microcontroller. We are using watchdog timer for softreset.

    whenever we are resetting the controller around 27 times using watchdog timer all three cores are booting and the code is executing, but at 28th time when we do soft reset, the CM is not coming to the main function and if we do power cycle then CM is able to execute the code.

    The above said cycle for 27 times is not fixed some time it varies 21 to 27.

  • Hi,

    I am out of office until 9/19/24, I will try to get back to you as soon as possible upon my return.

    Thank you,

    Ben Collier

  • Thank you llier, please message me and help us to resolve this issue.

  • Hi Rajkumar,

    whenever we are resetting the controller around 27 times using watchdog timer all three cores are booting and the code is executing, but at 28th time when we do soft reset, the CM is not coming to the main function and if we do power cycle then CM is able to execute the code.

    The above said cycle for 27 times is not fixed some time it varies 21 to 27.

    Why do you WD reset so many times? Just for testing purposes? And does it work properly the first ~27 times in your test and then not work the 28th?

    Since Ben is out I'll try and reassign your question to a Bootloader or reset expert on the team.

    Best,

    Kevin

  • Thank you, Kelvin,

    our bootloader is resetting the cores whenever we do application programming through the twincat.

    in single cycle we need to program for all the three cores hence we are doing reset for 3 times in a single cycle.

    When we are testing the bootloader code we found this behavior after some resets. Reset periodicity is not fixed for 27 or 28 times, sometimes we have got in 5 times itself.

    when we debug this issue, we found that, after reset CPU1 is able to boot itself and also CPU2.

    when CPU1 calls Device_bootCM() function to boot, CPU1 is executing and coming out of this function call but CM core is not able boot to main function.

    in this case if we do power cycle then it starts working again.

  • Hi Rajkumar,

    When the issue happens. Can you read back the below status register
    CMRESCTL- RESETSTS bit field

    Yes, I verified that this is waiting until CM is out of reset

    Also read back the address 0x20000000 for CM BootRom status.

    Specifically check the Bit 31 and 0:7. This can give us better understanding of the CM core status in this scenario.

    Thanks.

  • Thank you, Prarthan Bhatt,

    I will give you this data in couple of hours today.

  • Hi Prathan Bhatt,

    The value of the register CMRESCTL is 2, that means the bit value of RESETSTS is 1.

    0x20000000 is the flash memory of CM, whenever there is an issue CM will not reach to Main function, in this case how do I read this address?

    and i think we cannot access this address from CPU1, please correct me if aim wrong.

  • Ok Rajkumar. 

    The CM is out of reset so we can see why it did not reach main().

    Can you read the below register CMTOCPU1IPCBOOTSTS Register

  • Hi Prathan Bhatt,

    I have read CMTOCPU1IPCBOOTSTS and please find the value is as below.

    CMTOCPU1IPCBOOTSTS = 0x00001007 when the code is working 

    CMTOCPU1IPCBOOTSTS = 0,  when the issue exists.

  • Rajkumar,

    Thanks for the input.

    If CMTOCPU1IPCBOOTSTS is 0 seems like CM didn't even write to the register in bootrom.

    1) Can you check the address where CM is stuck when you see this issue ?

    Is it in any of the below address ranges ?



    2) CPU1TOCMIPCBOOTMODE Register value when failure occurs vs when issue doesnt happen ?

    Also how about the CMTOCPU1IPCSENDCOM Register value ?

    3) CPU1TOCPU2IPCBOOTMODE register value when failure occurs vs when issue doesnt happen ?

    Thanks.

  • Thank you, Prathan Bhatt,

    please find the values as below,
    CPU1TOCPU2IPCBOOTMODE = 0x5A00C803, when There is an issue
    CPU1TOCPU2IPCBOOTMODE = 0x5A00C803, when There no issue, So this value is same in both condition
    CPU1TOCMIPCBOOTMODE = 0x5A007D03, when There is an issue
    CPU1TOCMIPCBOOTMODE = 0x5A007D03, when There no issue, So this value is same in both condition

    Iam seeing this issue without the JTAG and i think i cannot see the Wait point address stuck for CM, or please tell me how can i see this without the JTAG/Debugger.

  • Rajkumar,

    When this issue happens standalone then you can connect using debugger and check where it is stuck right ?

    Make sure you remove gel file before connecting to avoid reset or any other initialization

    Thanks

  • Thank you, Prarthan,

    I tried to load symbols without Gel File, but getting following error while connecting.

    I have loaded the symbols when the issue exist with the Gel files as below, in the below image CM is showing that it is waiting for boot command mode, is this method correct please look into this.

  • Hi Prarthan,

    I have a doubt on adding entry_point in the liker settings as below,

      For CPU1, CPU2 we have added entry_point as "code_start" but for CM it is left blank and no entry point is mentioned, is this an issue?

    Also, May I request for the call at your time, so that we can understand the issue and will be helpful to close it very soon.

  • Hi Rajkumar,

    I have loaded the symbols when the issue exist with the Gel files as below, in the below image CM is showing that it is waiting for boot command mode, is this method correct please look into this.

    When you are running the test and this issue happens follow below steps:

    - Start debug less project https://www.youtube.com/watch?v=g2aaJV_DcZY
    - After launching remove GEL file for CPU1 and CM
    - Connect to CM core only
    - If you are able to connect to CM core then its out of reset already and you can load the symbol to see and if you are in CMBROM_waitForCommand() then Bootrom is just waiting for CPU1 to set flag 0 to signal the IPCBOOTMODE is ready
    - If you are not able to connect then CM core has not come out of reset which is very unlikely

    You can try the same the scenario where there is no issue

  • Thank you, Prarthan,

    I have followed the steps as you said and i see that in case of an issue CM is not connecting and when there is no issue iam able to see the connection.

    Here I have attached the video of both,

    Refer "At_Issue_03.10.2024_12.29.25_REC" for the issue capture and

              "No_Issue03.10.2024_12.33.41_REC" for the capture when there is no issue.

    So, if the CM is not coming out of the reset, then what could be the possible issue, since we are seeing IPC boot status register is 0 when there is an issue,

    but CPU1 is calling the function "Device_bootCM(BOOTMODE_BOOT_TO_FLASH_SECTOR0)" and coming out this .

    I have verified the Memory allocation also and looks good.

    Hi Prarthan,

    As I continued my debug, below are some observations.

    As per the above message i was seeing that CM was getting struck in Boot rom, so in that case i implemented to restart the controller using software reset option and after this, the CM is coming out of reset and Communication is getting established.

    After the above implementation, i see that the CPU2 is getting struck when CPU1 calls Boot function for CPU2, i tried to debug and, i fount that CPU2 is coming to main and getting struck in the function "Flash_claimPumpSemaphore()", but CPU1 is releasing the flash semaphore before it calls the cpu2 boot function.

    So based on the above two issues, i can see that IPC resistor access is common between both CM and CPU2 issue.

    Do we need to follow any sequence for IPC before we do any soft reset in the controller.

    So can you please look into this and help me to solve the issue, we can even have a call whenever you have time. please check this. 

    Thank you.

  • Hi Rajkumar,

    Sorry for the delay, let me take a look at this and reply by tomorrow.

    Thanks

  • Hi Rajkumar,

    Can you work with the local FAE who can help set up a call. It would be better to have a working session on the issue.

    Thanks

  • Thank you, Prarthan,

    Let me check.

  • Hi Rajkumar,

    Checked the Error message in the debugging guide page here : 

    https://software-dl.ti.com/ccs/esd/documents/ccsv7_debugging_jtag_connectivity_issues.html

    Can you try updating ccs to latest version with updated device drivers.

    Also did you try to run this on f2838xd controlcard, and you get the same issue ?

    Can you also try to monitor the XRSn pin on oscilloscope and see the behavior when issue occurs ?

    Thanks

  • Thank you, Prarthan,

    Already Iam using CCS version 12.7.1.

    Iam using the TMS320f28388d control card for development, so all these observations are on the same board.

    I have not seen XRSn pin state during the issue, let me check this and update you.

    I have uploaded the code in the link provided, please check it.

    Thank you.

  • There is a 12.8 CCS version available on web : https://www.ti.com/tool/CCSTUDIO?keyMatch=ccs&tisearch=universal_search&usecase=partmatches#downloads

    I ran the project you uploaded on drive, I cant see the issue.

    Are you able to re-produce the issue on your end ?

    Thanks

  • Thank you, Prarthan,

    The XRSn remains high(3.28v) when there is an issue. please see the attached image for the same.

    Yes, i am able to re produce the issue here. whenever there is an issue, you see only D1 LED is high and D2 is low, that means CPU2 has come out of reset and CM is got struck in reset.

    Are you able to see both LEDs are high all the time and please let me know which CCS version you are using.

  • Rajkumar,

    I am not able to reproduce the issue.

    Here are the steps I did : 

    1) Launch ccxml, just like how I showed you on the call

    2) Connect to CPU1, CPU2 and CM in same order

    3) Load CPU1, CPU2 and CM programs in flash in same order

    4) Set EMU BOOT mode to Flash

    5) Run flash programs CPU1,2 and CM in same order

    6) Terminate the session

    7) I can see both the LEDS are "on".

    Can you share your steps ?

  • Alternatively what I did was : 

    Connect Jumper cables to GPIO72 and GPIO84 Boot Mode Pins to 3.3V.

    Then powercycle the controlcard, then I can see both the LEDS are "ON".

    You need to set the Bootmode for CPU1, otherwise in standalone mode its going to assume you are in parallel IO mode(0,0) without anything connected to GPIO 72, 84.

    Thanks

  • Good Morning Prarthan,

    if we don't configure CPU1 in flash boot mode, then we should not see CPU1 to boot, but here in our case CPU1 is able to boot and call other cores to come out of reset.

    i have set switch S2 to left position in the Controller card, that means CPU1 is configured to Flash Boot Mode. with this configuration itself Iam seeing the issue.

    DO you want me to connect even GPIO72 and GPIO84 to VCC other than the S2 Switch configuration? 

    Please let me know. 

    Thank you.

  • Yes if you have both the Switch position to left, it effectively does the same thing.

    I powered cycled the board with just S2 both switches to left and I can see both LED's on.

    I am using CCS Version: 12.8.0.00012 

    Did you try this on multiple boards ?

    Thanks.

  • Hi Prarthan,

    yes , i am using the same configuration in multiple boards and seeing the same result.

    Let me try using CCS 12.8.0.00012 and update you.

    Thank you.

  • Hi Prarthan,

    Here I have attached video which shows the steps followed here to flash the kernel code. please go through it.

    Also, I will try to flash using CCS 12.08 and update you on the result.

    can you please tell me what is the c2000 ware version and compiler version you are using?

    Thank you.

  • Hi Rajkumar,

    Just to make sure, instead of starting debug session directly, can you load cpu1,2 and cm after launching ccxml like I showed you on the call last week.

    I am not seeing any issues on my end the led's are on always, I even removed the debug probe and just powered the base board HSEC.

    Also I think you said earlier you needed to do Power cycle to make it work, but after you did power cycle did it always work or you see issue after few resets ? 

    Thanks.

  • Good morning Prarthan,

    I have followed the step as same as you using the ccxml  with CCS 12.8.1.00005. but still i am seeing the issue.

    Question: Also I think you said earlier you needed to do Power cycle to make it work, but after you did power cycle did it always work, or you see issue after few resets ? 

    Answer: after power cycle again i use to see the issue after few resets and i need to do power cycle again to get out from that state.

    please let me know the compiler version for all cores and the c2000ware version you are using?

    But i am wondering, why are you not able to simulate the issue, can we please have a call today at your convenient time?

  • Hi Prarthan,

    I have one observation, when I moved the function "setupESCGPIOs" from Flash to Ram in run time, i am not seeing the issue. i knew that this will increase the execution speed, but does it have any impact on memory issue also?

  • Hi Rajkumar,

    Yes we don't expect any impact on memory because of moving function to RAM instead of flash.

    Not sure if you tried this before but if you could try launching ccxml and then load programs and before running set the EMU Boot Mode to flash and run programs sequentially from cpu1,2,3 and let the ccs be connected, do you see the CM going in and out of resets ?

    EMU BOOT to Flash can be enabled by below going to scripts menu --> EMU BOOT--> FLASH through CCS selection shown below for CPU1.

    Thanks.