• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 30 subscribers
  • Views 377 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM2634-Q1: sometimes CCM module works abnormal when power-on, and Cpu always gets into ESM high-priority interrupt handler

Will Gao
Intellectual 2335 points
Part Number: AM2634-Q1

Hi BU experts, 

Customer used SDL to init the CCM for R5FSS1 core cluster and let it work in lockstep mode. Now they are doing stress testing, i.e. periodically power-off and on the board to see if device works normally. They found sometimes after power-up the AM263x is always resetting itself due to WD is not serviced. In order to debug the issue, they disabled the WD. And then when issue happened, they accessed the chip with emulator (gel script's actions all disabled), and found that the R5FSS1-0 is located at ESM handler to clear the CCM status, keep running the core and it still gets into this ESM handler. However, when they tried the above debugging action couples of time, the R5FSS1-0 can work again, i.e. will not get into ESM handler anymore and works normally. 

In order to furtherly sure this root-cause, they removed the CCM configuration codes, tried the same test. And now the issue not happened. It states that the issue is truly caused by CCM. And they had an interesting founding that when the issue is met, after they connect the chip with emulation and disconnect it afterwards, the chip can work normally. So the emulator seems that will "reset" the CCM module or something else. 

Please help analyze this issue, why sometimes CCM will get stucked and even the ESM handler in SDL can not save it. And why emulator can "recover" the CCM module. 

Thanks & Regards, 

Will 

  • 0
    TI__Guru**** 192486 points

    Hi Will ,

    CPU/VIM CCM-R5F can run in one of the following four operating modes:

    1. Active compare lockstep mode
    2. Self-test
    3. Error forcing
    4. Self-test error forcing

    The operating mode can be selected by writing a dedicated key to the key register (CCMKEYRx) of the corresponding diagnostic. The mode #1 (Active compare lockstep mode) is the default mode on start-up. In lockstep mode, the bus output signals of both CPUs and VIMs are compared. A difference in the CPU compare bus outputs is indicated by signaling an error to the ESM,

    Which mode is used in customer's stress test? 

    Not all internal registers (R0, R1, ...) of the Cortex-R5F have fixed values upon reset. To avoid an erroneous CCM-R5F compare error, the application software needs to ensure that the CPU registers of both CPUs are initialized with the same values before the registers are used.

    Do you know which ESM flag is set?

  • 0 in reply to QJ Wang
    TI__Intellectual 2335 points

    Hi QJ, 

    Thanks for your answer. I will check with customer on this ESM flag, but I believe it is CCM_1_lockstep_compare_err because customer doesn't add self-test codes for R5FSS1 so far.  

    QJ Wang said:
    Not all internal registers (R0, R1, ...) of the Cortex-R5F have fixed values upon reset. To avoid an erroneous CCM-R5F compare error, the application software needs to ensure that the CPU registers of both CPUs are initialized with the same values before the registers are used.

    How can application software initialize the internal registers? Do we have corresponding APIs, it is very low level. 

    Regards, 

    Will 

  • 0 in reply to QJ Wang
    TI__Guru**** 192486 points

    Hi Will,

    Before performing CCM self test., The JTAG emulator should be disconnected.

    As far as I know, certain debug operations place the CPU in a halting debug state where the code execution is halted.  Because halting debug events are asynchronous, there is a possibility for the debug requests to cause loss of lockstep. CCM-R5F will disable all functional diagnostics upon detection of halting debug requests. Core compare error will not be generated and flags will not update. 

    Will Gao said:
    they removed the CCM configuration codes

    Do you mean the code of SDL_CCM_init()?

    Will Gao said:
    R5FSS1-0 is located at ESM handler to clear the CCM status, keep running the core and it still gets into this ESM handler.

    Can you tell me which instruction in the INT handler for example SDL_ESM_hiInterruptHandler() ?

  • +1 in reply to Will Gao
    TI__Guru**** 192486 points
    Will Gao said:
    How can application software initialize the internal registers?

    The bootloader should do it after the R5FSSx is configured to operate in lock step mode.

    You can re-init those registers at the very beginning of _c_int00 function in boot_armv7r_asm.S. I don't see a API for doing this job.

    mov r0, 0x0000
    mov r1, #0x0000
    mov r2, #0x0000
    mov r3, #0x0000
    mov r4, #0x0000
    mov r5, #0x0000
    mov r6, #0x0000
    mov r7, #0x0000
    mov r8, #0x0000
    mov r9, #0x0000
    mov r10, #0x0000
    mov r11, #0x0000
    mov r12, #0x0000
    mov r13, #0x0000

  • 0 in reply to QJ Wang
    TI__Intellectual 2335 points

    Hi QJ, 

    QJ Wang said:
    CCM-R5F will disable all functional diagnostics upon detection of halting debug requests. Core compare error will not be generated and flags will not update

    Understood now. Thanks. 

    QJ Wang said:
    Do you mean the code of SDL_CCM_init()?

    Yes, if they removed this part, and the issue can be avoided. 

    QJ Wang said:
    Can you tell me which instruction in the INT handler for example SDL_ESM_hiInterruptHandler() ?

    Yes, The program will get into SDL_ESM_hiInterruptHandler(), CCM error is set as causing high-priority interrupt to ESM. And corresponding CCM callback will be called. 

    Regards, 

    Will 

  • 0 in reply to QJ Wang
    TI__Intellectual 2335 points

    Hi QJ, 

    QJ Wang said:
    The bootloader should do it after the R5FSSx is configured to operate in lock step mode

    I guess you are talking about the SBL but not RBL? I checked the SBL codes (sbl_qspi), but not find any codes to do so: 

     

    And there are no initialization codes in c_int_00: 

    I will try to add the codes you recommended, will update the result here. 

  • 0 in reply to Will Gao
    TI__Guru**** 192486 points

    Hi Will,

    I will double check with our hardware experts if those internal registers are initialized by HW automatically. 

  • 0 in reply to QJ Wang
    TI__Intellectual 2335 points

    Hi QJ, 

    The solution works! The issue can be avoided now. 

    Regards, 

    Will