• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 577 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: sometimes PC pointed to Boot-ROM region after running EtherCAT and Ethernet about 10 minutes

Yale Li 李耀先
Expert 4660 points

Part Number: TMS320F28388D

Board&Project: customer self-made

They have already achieved EtherCAT and Ethernet communication. But sometimes when they debug the project, the PC will point to Boot-ROM region("0x162e" or "0x162c") after running about 10 minutes.

Here is the map file:

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  CMBANK0_RESETISR      00200000   00000008  00000006  00000002  RWIX
  CMBANK0_SECTOR0       00200008   00003ff8  00001138  00002ec0  RWIX
  CMBANK0_SECTOR1       00204000   00004000  00000000  00004000  RWIX
  CMBANK0_SECTOR2       00208000   00004000  00000000  00004000  RWIX
  CMBANK0_SECTOR3       0020c000   00004000  00000000  00004000  RWIX
  CMBANK0_SECTOR4       00210000   00010000  0000c788  00003878  RWIX
  CMBANK0_SECTOR5       00220000   00010000  00000000  00010000  RWIX
  CMBANK0_SECTOR6       00230000   00010000  00000000  00010000  RWIX
  CMBANK0_SECTOR7       00240000   00010000  00000000  00010000  RWIX
  CMBANK0_SECTOR8       00250000   00010000  00000000  00010000  RWIX
  CMBANK0_SECTOR9       00260000   00010000  00000000  00010000  RWIX
  CMBANK0_SECTOR10      00270000   00004000  00000000  00004000  RWIX
  CMBANK0_SECTOR11      00274000   00004000  00000000  00004000  RWIX
  CMBANK0_SECTOR12      00278000   00004000  00000000  00004000  RWIX
  CMBANK0_SECTOR13      0027c000   00004000  00000000  00004000  RWIX
  C1RAM                 1fffc000   00002000  000013f8  00000c08  RWIX
  C0RAM                 1fffe000   00002000  00000158  00001ea8  RWIX
  BOOT_RSVD             20000000   00000800  00000000  00000800  RWIX
  S0RAM                 20000800   00003800  00002140  000016c0  RWIX
  S123RAM               20004000   0000aa00  0000991a  000010e6  RWIX
  S3RAM_PARA            2000ea00   00001600  000015e0  00000020  RWIX
  E0RAM                 20010000   00004000  00000000  00004000  RWIX
  CPU1TOCMMSGRAM0       20080000   00000800  00000110  000006f0  RWIX
  CPU1TOCMMSGRAM1       20080800   00000800  00000000  00000800  RWIX
  CMTOCPU1MSGRAM0       20082000   00000800  00000624  000001dc  RWIX
  CMTOCPU1MSGRAM1       20082800   00000800  00000000  00000800  RWIX
  CPU2TOCMMSGRAM0       20084000   00000800  00000110  000006f0  RWIX
  CPU2TOCMMSGRAM1       20084800   00000800  00000000  00000800  RWIX
  CMTOCPU2MSGRAM0       20086000   00000800  00000110  000006f0  RWIX
  CMTOCPU2MSGRAM1       20086800   00000800  00000000  00000800  RWIX


SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
00200000    00200000    00000006   00000006    r-x
  00200000    00200000    00000006   00000006    r-x .resetisr
00200160    00200160    000002a0   000002a0    r--
  00200160    00200160    000002a0   000002a0    r-- .const.1
00200400    00200400    00000d40   00000d40    r--
  00200400    00200400    00000140   00000140    r-- .vftable
  00200540    00200540    00000848   00000848    r-- .const.2
  00200d88    00200d88    000003b8   000003b8    r-- .cinit
00210000    00210000    0000c788   0000c788    r-x
  00210000    00210000    0000c788   0000c788    r-x .text
1fffc000    1fffc000    000013f8   00000000    rw-
  1fffc000    1fffc000    00000a00   00000000    rw- .stack
  1fffca00    1fffca00    000009f8   00000000    rw- .data
1fffe000    00200008    00000158   00000158    r-x
  1fffe000    00200008    00000158   00000158    r-x .TI.ramfunc
20000800    20000800    00002140   00000000    rw-
  20000800    20000800    00002000   00000000    rw- .sysmem
  20002800    20002800    00000140   00000000    rw- .vtable
20004000    20004000    0000991a   00000000    rw-
  20004000    20004000    0000991a   00000000    rw- .bss
2000ea00    2000ea00    000015e0   00000000    rw-
  2000ea00    2000ea00    000015e0   00000000    rw- LOCALRAMS3_PARA
20080000    20080000    00000110   00000000    rw-
  20080000    20080000    00000110   00000000    rw- MSGRAM_CPU1_TO_CM
20082000    20082000    00000624   00000624    rw-
  20082000    20082000    00000624   00000624    rw- MSGRAM_CM_TO_CPU1
20084000    20084000    00000110   00000000    rw-
  20084000    20084000    00000110   00000000    rw- MSGRAM_CPU2_TO_CM
20086000    20086000    00000110   00000000    rw-
  20086000    20086000    00000110   00000000    rw- MSGRAM_CM_TO_CPU2
  
  .stack     0    1fffc000    00000a00     UNINITIALIZED
                  1fffc000    00000004     rtsv7M4_T_le_eabi.lib : boot_cortex_m.c.obj (.stack)
                  1fffc004    000009fc     --HOLE--

.vtable    0    20002800    00000140     UNINITIALIZED
                  20002800    00000140     driverlib_cm.lib : interrupt.obj (.vtable)

.sysmem    0    20000800    00002000     UNINITIALIZED
                  20000800    00000010     rtsv7M4_T_le_eabi.lib : memory.c.obj (.sysmem)
                  20000810    00001ff0     --HOLE--

--

Thanks & Regards

Yale

  • 0
    TI__Expert 6035 points

    Yale, 

    Could you provide some more details on what program is being run? It is not possible to diagnose the issue based on the information available. 

    Thanks. 

  • 0 in reply to Sahil Deshpande
    TI__Expert 4660 points

    Hi Sahil,

    EtherCAT uses cia402. The PDI interrupt and SYNC0 interrupt are used in the CM core for data transfer. The SYNC0 interrupt triggers the IPC0 interrupt from CM to CPU1, and the EtherCAT data is transferred to CPU1 in the IPC0 interrupt of CPU1. And in this IPC0 interrupt, the IPC0 interrupt from CPU1 to CM is triggered, and the CPU1 data is transferred to CM, and then sent to the master station through the PDI interrupt.

    Ethernet communication uses UDP protocol routines, and two port numbers are opened. In the receiving interrupt callback functions of these two port numbers, IPC1 and IPC2 are used to transmit data to CPU1 respectively. In the process of using Ethernet communication, the two receiving interrupt periods are 500ms and 62.5us respectively..

    In the Debug mode of CCS, the three cores start running at full speed. The customer board communicates with the computer's debugging interface via Ethernet via a network cable. At this time, the code runs normally. Then when communicating with TwinCAT through the network cable, the CM ran away. At this time, neither Ethernet nor EtherCAT worked properly.

    --

    Thanks & Regards

    Yale

  • 0 in reply to Yale Li 李耀先
    TI__Expert 6035 points

    Yale, 

    We are looking into it, please expect a response by Friday. 

    Thanks.

  • 0 in reply to Sahil Deshpande
    TI__Expert 4660 points

    Thanks.

    And we would like to know if CCS has relevant tools or methods that can locate where the CM code jumps to address 0x162e.

  • 0 in reply to Yale Li 李耀先
    TI__Expert 4660 points

    Hi Sahil,

    The latest reply from the customer:

    In the latest test, I found that even if I do not use ECAT and Enet communication, but perform ESC register read and write operations on the while loop in CM, when I comment it out, the program does not run away and it happens randomly. So I'm wondering if it's caused by insufficient stack space.

    After checking the manual, I found that I can use -entry_hook to check whether the stack space has overflowed, but I don't know how to do it. Can you give me some guidance on how to check whether the stack space has overflowed?

    --

    Thanks & Regards

  • +1 in reply to Yale Li 李耀先
    TI__Expert 6035 points

    Okay Yale, we will look into it. 

    However, due to Diwali vacation next week, please expect a response by Monday 20th Nov.

    Thanks.