• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 30 subscribers
  • Views 1027 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.

TMS570Lc43570, system power down and restart via sci 4 interrupt

Lars Guenther
Intellectual 675 points
Other Parts Discussed in Thread: HALCOGEN

Hi all,

I have a problem with the function "System Power Down", parameter "Sleep" and wake up via sci4 interrupt.

Short background:
I have a 100ms task, this is activated via RTI and in this task I call the function "System Power Down" after 5sec only to see if my wake up is working.

The problem of the wake up is sometimes it is working and sometimes not. It is a 50% chance that it is working or not.

It is possible to get access via Debugger if it the system is not wake up and I implemented some debug variables before calling "System Power Down" to see what going on.


So here is my Debug code:

/* Debug */
DebugIRQINDEX     = vimREG->IRQINDEX;
DebugFIQINDEX     = vimREG->FIQINDEX;
DebugFIRQPR0      = vimREG->FIRQPR0;
DebugFIRQPR1      = vimREG->FIRQPR1;
DebugFIRQPR2      = vimREG->FIRQPR2;
DebugFIRQPR3      = vimREG->FIRQPR3;
DebugINTREQ0      = vimREG->INTREQ0;
DebugINTREQ1      = vimREG->INTREQ1;
DebugINTREQ2      = vimREG->INTREQ2;
DebugINTREQ3      = vimREG->INTREQ3;
systemPowerDown(SYS_SLEEP_MODE);              <--------------- calling Systen Power Down

Now the following szenario:
- restart system via power off / on
- the software is calling "System Power Down" after 5 sec. and it is not possible to get access via sci4
- I start the Debugger, the debugger stops in "prefetchEntry"
- I looked at my debug variables    
    DebugIRQINDEX,    value is 0x0000 0000
    DebugFIQINDEX,     value is 0x0000 0000
    DebugFIRQPR0,      value is 0x0000 0003
    DebugFIRQPR1,      value is 0x0000 0000
    DebugFIRQPR2,      value is 0x0000 0000
    DebugFIRQPR3,      value is 0x0000 0000
    DebugINTREQ0,      value is 0x0100 0000
    DebugINTREQ1,      value is 0x0000 0000
    DebugINTREQ2,      value is 0x0000 0000
    DebugINTREQ3,      value is 0x0000 0000
the debug variables before calling "System Power Down" are looking good, but if I looked at the corresponding register via debugger (Debugger stops in prefetchEntry) I see:

    IrqIVec,     value is 0x0000 0078    <- ???
    FiqIVec,    value is 0x0000 0001    <- ???
    FIrqPr0,    value is 0x0000 0003
    FIrqPr1,    value is 0x0000 0000
    FIrqPr2,    value is 0x0000 0000
    FIrqPr3,    value is 0x0000 0000
    IntReq0,   value is 0x0100 0001    <- ???
    IntReq1,   value is 0x0000 0000
    IntReq2,   value is 0x0000 0000
    IntReq3,   value is 0x0080 0000    ok, this is my sciLowLevelInterrupt (channel 119) and it is pending


What I do not undestand is:
    - why it is sometimes wortking and sometime not, it is like a random function. If it is running the values of the debug variables are equal to the register values. That's how it should always be.
    - the register differences before and after calling "System Power Down" if it is not running
    - the IrqIVec0 = 0x0000 0078, this means the interrupt channel 125 is activated. But it is a reserved interrupt and it is definedly not enabled in my HalCoGen Project. What kind of interrupt is this ? I do not find any documentation.
    - FiqIVec = 0x0000 0001, this means "esmHighInterrupt". How can I generate this interrupt.

Many thanks in advance and happy X-mas.

Best regards
Lars

  • 0
    TI__Guru 68920 points
    Lars,

    I think there is a human bug at TI because someone here doesn't know the hexadecimal system ;)

    I see where we confused you:

    Table 19-11. Interrupt Dispatch
    Register Bit Field Highest Priority Pending Interrupt Enabled
    0x00 No interrupt
    0x01 Channel 0
    : :
    0x79 Channel 126
    0x80 Channel 127

    0x80 - 0x1 = 0x7F !

    So actually, 0x78 = 120 decimal and this means channel 119

    I'll submit a ticket to get this corrected.

    Ok that's one piece of the puzzle.

    The ESM interrupt being NMI is something that once you enable the FIQ interrupt mask in the CPSR register, you don't have any control over. The ESM channel on this interrupt channel is really not maskable at all in the VIM.
    So it's just an indication of some error. Could be something simple like an ECC error..
    And the prefetch abort is also indicative of this sort of problem.

    What do the ESM status registers say about the source of the offense?
  • 0 in reply to Anthony F. Seely
    Intellectual 675 points

    Hi Anthony,

    now this makes sense and you were right I was looking at Table 19-11.

    So I will look at the ESM register but in the next year. I will be back at the 2. Jan.

    Best regards and marry X-mas

    Lars

  • 0 in reply to Lars Guenther
    Intellectual 675 points
    Hi Anthony,

    so I am back and I read the ESM status register.

    ESM1:
    Stat1 0x80000000 Status Register 1 [Memory Mapped]
    Stat2 0x00000004 Status Register 2 [Memory Mapped]
    Stat3 0x00000000 Status Register 3 [Memory Mapped]
    Stat4 0x00000000 Status Register 4 [Memory Mapped]
    Stat5 0x00000000 Status Register 5 [Memory Mapped]
    Stat6 0x00000000 Status Register 6 [Memory Mapped]
    Stat7 0x08000000 Status Register 7 [Memory Mapped]
    Stat8 0x00000000 Status Register 8 [Memory Mapped]
    Stat9 0x00000000 Status Register 9 [Memory Mapped]

    ESM2
    Stat1 0x00000000 Status Register 1 [Memory Mapped]
    Stat2 0x00000000 Status Register 2 [Memory Mapped]
    Stat3 0x00000000 Status Register 3 [Memory Mapped]
    Stat4 0x00000000 Status Register 4 [Memory Mapped]
    Stat5 0x00000000 Status Register 5 [Memory Mapped]
    Stat6 0x00000000 Status Register 6 [Memory Mapped]
    Stat7 0x00000000 Status Register 7 [Memory Mapped]
    Stat8 0x00000000 Status Register 8 [Memory Mapped]
    Stat9 0x00000000 Status Register 9 [Memory Mapped]

    As I understand the register Stat1, Stat4 and Stat7 are for the ESM error group 1, Stat2 is for the ESM group 2 and Stat3 is for ESM group3. The rest stat 5,6,8,9 is not used.

    So I see ESM1, Stat1 register, bit 31 and Stat7, bit 27 is set. That means "CCM Selftest error" and "SCM Timeout" on CPU1. No bit is set in the ESM2, that means no error is detected on CPU2.

    I read the CcmR5 register.

    CcmR5:
    CcmSr1 0x00010000 CCMR5 Status Register1 [Memory Mapped]
    CcmKeyR1 0x00000000 CCMR5 Key Register1 [Memory Mapped]
    CcmSr2 0x00000000 CCMR5 Status Register2 [Memory Mapped]
    CcmKeyR2 0x00000000 CCMR5 Key Register2 [Memory Mapped]
    CcmSr3 0x00000000 CCMR5 Status Register3 [Memory Mapped]
    CcmKeyR3 0x00000000 CCMR5 Key Register3 [Memory Mapped]
    CcmPolCntrl 0x00000000 CCMR5 Polarity Control Register [Memory Mapped]
    CcmSr4 0x00000000 CCMR5 Status Register4 [Memory Mapped]
    CcmKeyR4 0x00000000 CCMR5 Key Register4 [Memory Mapped]
    CcmPDStat0 0x00000000 CCMR5 Power Domain Status Register0 [Memory Mapped]
    CcmPDStat1 0x00000000 CCMR5 Power Domain Status Register1 [Memory Mapped]

    Bit 16 is set in CcmSr1, that means "Compare Error for CPU Output Compare Diagnostic".

    And now I have no idea.

    Best regards
    Lars
  • 0 in reply to Lars Guenther
    TI__Guru 68920 points
    Lars,

    This may be due to some silicon errata.

    Please see errata Device #48, 49, 56 in www.ti.com/.../getliterature.tsp

    And let me know if you think it may be one of these issues.
  • 0 in reply to Anthony F. Seely
    Intellectual 675 points
    Hi Anthony,

    I see the ESM group 2, channel 2 interrupt in the ESM Register IntOffstHgh (value is 0x23, errata --> DEVICE#56).
    But it is not so easy for me to solve this problem.

    So what I have done is:
    1.) running the software with the debugger (Break point is set before calling the function systempowerdown). Everythink looks fine including the ESM registers. Than I step into the function "systempowerdown" with the parameter "SYS_SLEEP_MODE". The clocks are switched off and the debug session is stopped.

    I want to wake up with a SCI4 interrupt. So it seams that the clocks are wake up because I can use my debugger (load symbols only) after I send a byte via sci4. But if I am using the debugger I see that the debugger stops in "prefetchEntry" and the ESM group 2 channel 2 interrupt is pending. I do not know where I have to write the 0x5 in ESMEKR register because it is a new debug session and I can not restart the system.


    2.) I call the function "systempowerdown" without changes in the registers "CSDISSET" and "CDDIS". So my debug session is not stopped because all clocks are available and everythink is running fine. The software stops in the line _gotoCPUIdle_, WFI (wait for interrupts) and I can run further on if a SCI4 interrupts is detected.

    For me it seams that I have a problem with the wake up functionality if the clocks are disabled. My wake up and power down source is set the LPO high in the HalCoGen project.

    Best regards
    Lars
  • 0 in reply to Lars Guenther
    TI__Guru 68920 points
    Hi Lars,

    Sorry I'm losing track of the big picture here.

    We had identified one documentation error, that IRQIVEC = 0x78 really does correspond to channel 119.

    Did you confirm that this documentation error didn't translate to a coding error (by putting the wrong address in VIM RAM or dispatch table) such that it's not the source of the Prefetch Abort?

    If so, then we should probably focus more on the Prefetch Abort. The value in R14 and SPSR when you break at the Prefetch Abort vector (0x0C) are of importance. Also the values of CP15_INSTRUCTION_FAULT_STATUS and CP15_INSTRUCTION_FAULT_ADDRESS will be useful to know. We should understand what lines of code these trace back to.

    I'm not really clear on your last post, it is tricky to step through a power down you really need to 'run through' it so I don't know what to make of your results. All I can say again is that the WFI may not be actually executed in cases where there are any interrupt requests at the CPU boundary (even if the interrupts are masked off in CPSR) and also a debug request like you would get if you have a breakpoint set or are assembly stepping can prevent the WFI.

    So I'm thinking it's best to focus on the source of the Prefetch Abort. If it's not due to the documentation error than knowing the register values mentioned above should point in the right direction.

    -Anthony
  • 0 in reply to Anthony F. Seely
    Intellectual 675 points
    Hi Anthony,

    here you can find my application code (file HL_sys_intvecs.asm). My application code is starting at address 0x00200000 because I had a boot loader stored at flash bank 0.

    ***************************************************************************************************************************
    51 b _c_int00
    $D:/STMs_11VP18/EBICAB_600_SW/STM_SW/TICore/source/HL_sys_intvecs.asm:51:67$(), resetEntry():
    00200000: EA00B390 b _c_int00
    53 b undefEntry
    undefEntry:
    00200004: EAFFFFFE b undefEntry
    55 b svcEntry
    svcEntry:

    00200008: EAFFFFFE b svcEntry
    57 b prefetchEntry
    prefetchEntry:
    0020000c: EAFFFFFE b prefetchEntry
    59 b dataEntry
    dataEntry:
    00200010: EAFFFFFE b dataEntry
    62 b reservedEntry ;0x14
    reservedEntry:
    00200014: EAFFFFFE b reservedEntry
    63 ldr pc,[pc,#-0x1b0]
    00200018: E51FF1B0 ldr pc, [pc, #-0x1b0]
    64 ldr pc,[pc,#-0x1b0]
    0020001c: E51FF1B0 ldr pc, [pc, #-0x1b0]
    ****************************************************************************************************************************

    I read the registers with the following values:

    Core Registers:
    R14: 0x00200010

    IRQ Register:
    SPSR_irq: 0x8000031F
    N (Negative/Less than) = 1
    A (Asynchronous abort) = 1
    E (Data endianness bit) = 1
    Mode = 11111 (system)

    Abort Register:
    SPSR_abt: 0x80000397
    N (Negative/Less than) = 1
    A (Asynchronous abort) = 1
    IRQ (disable) = 1
    E (Data endianness bit) = 1
    Mode = 10111 (system)
    R13: 0x08001400
    R14: 0x00200010

    CP15 Register:
    CP15_INSTRUCTION_FAULT_STATUS: 0x00001008
    SD = 1 --> AXI Slave error caused the abort
    Status = 1 --> Synchronous External Abort valid

    CP15_INSTRUCTION_FAULT_ADDRESS: 0x0020000C

    Do you know what "AXI Slave error cause the abort" mean ?

    Best regards
    Lars
  • 0 in reply to Lars Guenther
    TI__Guru 68920 points

    Lars,

    Best explanation I can find is:

    "A memory access performed through the AXI master interface or the AXI peripheral port can
    generate two different types of error response, a slave error (SLVERR) or decode error
    (DECERR). These are known as external errors, because they are generated by the AXI system
    outside the processor. Synchronous aborts are generated for instruction fetches, data loads,
    exclusive stores, and data stores to strongly-ordered-type memory. Non-exclusive stores to
    normal-type or device-type memory generate asynchronous abort"


    While this isn't crystal clear on the difference between SLVERR or DECERR,  I think this indicates that there was an error on an instruction fetch from some memory that is located on the AXI master interface and that the error was detected inside the slave.

    So for example an ECC error detected within the flash wrapper might be causing this.


    Maybe look at the TRM SPNU563  section 7.10 Summary of L2FMC Errors  and check the registers listed there to see if the level 2 flash controller is detecting any errors and reporting them.

    -Anthony