• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 101 subscribers
  • Views 1857 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.

TMS320C6657: How to reset Core1 from Core0 if Core1 goes into abnormal operation mode.

Hitoshi Sugawara
Mastermind 18650 points
Part Number: TMS320C6657

Hi Champs,
Could you please let us know how to reset properly Core1 by Core0 if Core1 goes into an abnormal operation condition?
The customer would like to now appropriate SW procedure for reset issued by Core0.

We have already informed below, however, it seems that they do not help for their requested RESET method.
o Hardware Design Guide for KeyStone I Devices Application Report
   [SPRABI2C AUG13]
   (http://www.ti.com/lit/pdf/sprabi2)

   - Page 54~55
     5.1.4 LRESET
 o C6657 Datasheet [SPRS814C MAY16]
   (http://www.ti.com/lit/gpn/tms320c6657)
   - Page 43
     5.7.6 External Interrupts Electrical Data/Timing
       Table 5-8. NMI and Local Reset Timing Requirements
       Figure 5-8. NMI and Local Reset Timing

Thank you very much for your kind support.
Best regards,
Hitoshi Sugawara

  • 0
    TI__Guru**** 161600 points
    Hi,

    I've notified the sw team. Their feedback will be posted directly here.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    TI__Guru* 95265 points
    Hi,

    From TMS320C6657 data sheet, Section 7.4, there is a Table 7-9 for the reset behavior of different reset types. If you just want to reset corepac1 from corepac0, then the way is to do a local reset.

    What do you mean the "seems that they do not help for their requested RESET method"?

    Regards, Eric
  • 0 in reply to lding
    TI__Mastermind 18650 points
    Hi Eric,
    Thank you for your feedback.
    Will check with the customer again and get back to you.
    Best regards,
    Hitoshi Sugawara
  • 0 in reply to Hitoshi Sugawara
    TI__Guru* 78325 points
    Adding some more details from an offline thread on pending questions on this topic from field team and customer


    Objective
    When Core1 becomes abnormal condition by Abort, Core0 would issue CPU reset to Core1 so that Core1 goes back to normal mode. This is first time for customer to develop such SW with C6657.

    Questions:
    1) Customer would like to know the correct sequence to reset Core1 from Core0 when Core1 goes into abnormal condition.
    The attached excel (shared offline) shows their sequence to reset Core1 from Core0 by IPC. Could you please check it and please let us know the appropriate sequence.

    2) When they followed the sequence, they have faced the problem as follows:
    Ipc_module->ipcSharedAddr becomes NULL in Ipc_attach() called in Ipc_start().
    Therefore, Ipc_start() can not finish.
    Could you please check why it becomes NULL?

    3) If TI has other way to reset Core1 from Core0, please let us know.

    4) SDK version
    1 Customer would like to utilize these version above except MCSDK.
    Could you please let us know the appropriate MCSDK version?

    SDK (version)
    CCS 5.5.0.00077
    MCSDK or Processor SDK 2.1.2.6
    SYS/BIOS 6.37.4.32
    XDCTools 3.25.6.96
    IPC 1.25.3.15
    CGTools c6000_7.4.11

    TI field team verified that
    MCSDK v2.1.2.6 supports
    SYS/BIOS 6.33.06.50
    XDCTools 3.23.04.60
    IPC 1.24.03.32

    2 Please let us know the most reliablible SDK combinations. he SDK sev

    5) This is important for customer too.
    After Core1 is reset successfully, Core1 must start correctly and share the memory etc.
    They would like Core1 to restart like the cold start. Could you please let us know there are any things customer has to initialize after Core1 is reset.
  • 0 in reply to Mukul Bhatnagar
    TI__Guru* 95265 points

    Hi,

    The referred packages are from very old MCSDK release and were replaced by Processor SDK RTOS, the latest release is 3.3. The core local reset doesn't behavior the same as a cold reset which happens in a system level. What caused the core1 stuck? If core 1 used some pheriphals and had error, they will not be reset. Do you use shared memory as the transport layer? When core 1 started to run, was it starting the same address as it run from the cold start? Is any shared buffer you need to clear? What is the IPC example you used for this purpose and we can look into it? When core 0 runs IPC_start() to wait for core1 respond and timeout, where is the core 1 side program counter? If you load the symbol, can you find out where core 1 stuck? 

    Regards, Eric

  • 0 in reply to lding
    TI__Mastermind 18650 points
    Hi Eric,
    Thank you for your kind check. For your questions, will work with the customer and answer them later.

    2) When they followed the sequence, they have faced the problem as follows:
    Ipc_module->ipcSharedAddr becomes NULL in Ipc_attach() called in Ipc_start().
    Therefore, Ipc_start() can not finish.
    Could you please check why it becomes NULL?

    3) If TI has other way to reset Core1 from Core0, please let us know.
    Is this the normal way to make a local reset by IPC?

    4) SDK version
    The customer is concerned about the system level re-evaluation must be needed if the MCSDK and the other related software development environment are drastically changed.
    So let me clarify whether TI recommend the latest release version 3.3 instead of current version of the customer uses.

    I would very appreciate if you could kindly give us the answers for these 3 questions first.
    Best regards,
    Hitoshi Sugawara
  • 0 in reply to Hitoshi Sugawara
    TI__Guru* 95265 points

    Hi,

    For 2), Please let us know what exact IPC example they tried so we can analyze

    For 3) The local reset is not by IPC, it is from power domain to reset a particular CorePac without resetting any other chip components. It doesn't involve in IPC.

    For 4) The issue is after core local reset, what else is needed to make sure IPC can still run, I think this is not IPC/MCSDK/Processor SDK release related. If customer used older releases, this should fine, no need to upgrade to the latest.

    Regards, Eric

  • 0 in reply to lding
    TI__Mastermind 18650 points

    Hi Eric,
    Thank you for update.

    For 2), let me share the example locally with you.

    For 3), let me study more about your comment.

    For 4), thank you for your observation. It helps us a lot.

    5)
    Moreover, we found the related sled as follows:
    TI E2E: IPC_attach on core 1 returns -11 after reloading core 1
    (e2e.ti.com/.../229528)

    According to the sled, IPC_DETACH() is a handshake between cores.
    That means that IPC_DETACH() must be called before "Reset" in the user case.
    (Please refer to the shared file locally.)

    Consequently, it said that IPC does not support crash scenario.
    It seems IPC does not help the customer’s requested condition which is Core1 Abort condition ( Time out occurs from Core1).
    "Ipc does not support the scenario where something crashes. We only support controlled shutdowns by both sides."

    I think this is the answer for the customer.
    What do you think?

    Best regards,
    Hitoshi

  • 0 in reply to Hitoshi Sugawara
    TI__Guru* 95265 points
    Hi Hitoshi,

    Thanks for sharing this E2E thread! Yes, this answered customer's question: if core 1 aborted for some reason, core 0 can do a local reset to core 1 for its program resuiming. But local reset doesn't guarantee that programs always works. In this IPC case, Ipc does not support the scenario where something crashes. We only support controlled shutdowns by both sides.

    Regards, Eric
  • 0 in reply to lding
    TI__Mastermind 18650 points
    Hi Eric,
    Thank you very much for your confirmation.
    will work with the customer to find the best way to resolve their requirements.
    Best regards,
    Hitoshi