• State Resolved
  • Locked Locked
  • Replies 22 replies
  • Subscribers 32 subscribers
  • Views 692 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.

AM263P4-Q1: <ECP> Clarification regarding CCM Self Test Error Forcing mode

Vandana Chintala
Prodigy 40 points

Part Number: AM263P4-Q1
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

Hello, 

I’m working with the AM263P-CC board and need clarification regarding the CCM Self-Test Error Forcing mode.

According to the AM263P TRM and the register addendum, the key value for entering CCM Self-Test Error Forcing mode should be 15 (0xF). However, in SDK 11.02.00.19, I observed that the code writes a key value of 9 (0x9) for the same purpose.

When I enable the self-test error forcing in my application, ESM Error Status Register (ESM_ERR_STS) shows bit 19 enabled (SDL_ESM0_CCM_0_SELFTEST_ERR according to SDK) but I do not see any change in the CCM Status Register (CCMR_CCMSR1) . The bits remain unchanged, and the expected forced error indications do not appear.

Could you please clarify the following points?

  1. Correct Key Value:
    Which key value (0xF or 0x9) should be used to correctly enable Self-Test Error Forcing mode in CCM?

  2. Register Behavior:
    When I write 0x9 or 0x15 to the CCMR_CCMKEYR Register, the CCMR_CCMSR Register reads back as 0x00.
    Is this the expected behavior for the self-test error forcing operation?

  3. Understanding Error Forcing vs. Self-Test Error Forcing:
    Could you please elaborate on what exactly happens internally. Specifically, what differences should we expect in CCM behavior and ESM error signaling?

  4. In the SDK SDL_CCM example, the following configuration is used for ESM initialization. Can you please clarify why 1 and 8 are being used for ESM error config (.esmErrorConfig)?

  • 0
    TI__Guru* 75836 points

    Hi Vandana,

    Apologies for the delayed response!

    I am working on your issue now and will try to provide my update as soon as possible.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 40 points

    Hi Jagadish,

    Thanks for the update! 

    Regards, Vandana.

  • 0
    Prodigy 40 points

    Hi Jagadish, 

    Can you please provide some update on this as soon as possible. It would be really helpful, Thankyou.

    Regards,

    Vandana Chintala

  • 0 in reply to Vandana Chintala
    TI__Guru* 75836 points

    Sure Vandana,

    I will try to provide by end of the day.

  • 0 in reply to jagadish gundavarapu
    TI__Guru* 75836 points

    Hi Vandana,

    Vandana Chintala said:
    Which key value (0xF or 0x9) should be used to correctly enable Self-Test Error Forcing mode in CCM?

    Self-Test Error Forcing Mode should use 0xF only. I think there seems to be some error in the code.

    Inject error should use 0x9 but self-test error forcing should use 0xF only not 0x9. I will discuss this with internal team once and comeback to you on this.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 40 points

    Ok Jagadish, sure.
    Also please do let us know the behavior of CCM Registers and ESM Registers after writing value 0xF. We are trying to enable CCM at the BOOT level code

    Thanks & regards,

    Vandana Chintala

  • 0 in reply to jagadish gundavarapu
    Prodigy 40 points

    Hi Jagadish, 

    Could you please let me know when can we expect an update in self test error forcing mode. 

    Meanwhile could you also please elaborate on difference between error forcing and self test error forcing mode, specifically what differences should we expect in CCM registers behavior and ESM error signals, registers in both modes. 

  • 0 in reply to Vandana Chintala
    TI__Guru* 75836 points

    Hi Vandana,

    Apologies for the delayed response!

    jagadish gundavarapu said:
    Inject error should use 0x9 but self-test error forcing should use 0xF only not 0x9. I will discuss this with internal team once and comeback to you on this

    I raised an internal JIRA to bring this issue to software development team.

    I am waiting for their confirmation about this issue and i will update you as soon as i got response from them.

    Vandana Chintala said:
    Also please do let us know the behavior of CCM Registers and ESM Registers after writing value 0xF. We are trying to enable CCM at the BOOT level code

    As mentioned in TRM, in self-test Error forcing mode CCM registers related to self-test will not get affect by this self-test error forcing mode. Only ESM signal related to self-test will get activated after this testing.

    I mean in this testing a mismatch pattern is applied on CCM module to self-test for one clock cycle, so that means it will trigger self-test ESM error flag:

    And after this testing again CCM will go to the normal lock step mode.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 40 points

    Hi Jagadish,

    Thanks for the update.

    You mentioned that in the self-test error forcing mode, the CCM registers related to the self-test will not be affected. However, in the SDK 11.00.19 CCM example, the code for self test error force mode enters the SDL_CCM_selfTest() function with testType = SDL_CCM_SELFTEST_TYPE_ERROR_FORCING.

    Inside this function, after initiating the error-forcing mode, the implementation continuously reads the corresponding CCM status register (monitorTypeStatusRegister) and checks whether any of the status bits (SDL_CCM_ALL_STATUS_BITS) are updated. If these bits never change, the loop exits only due to timeout, which causes the function to return SDL_EFAIL.

    Could you please review this SDK function and clarify how will self test error forcing mode succeed, given that the CCM status register does not update? 

    Thanks and Regards,
    Vandana Chintala

    ...   ...

  • 0 in reply to Vandana Chintala
    TI__Guru* 75836 points

    Hi Vandana,

    Vandana Chintala said:
    Inside this function, after initiating the error-forcing mode, the implementation continuously reads the corresponding CCM status register (monitorTypeStatusRegister) and checks whether any of the status bits (SDL_CCM_ALL_STATUS_BITS) are updated. If these bits never change, the loop exits only due to timeout, which causes the function to return SDL_EFAIL.

    Your understanding is correct!

    jagadish gundavarapu said:
    Self-Test Error Forcing Mode should use 0xF only. I think there seems to be some error in the code.

    And as we discussed earlier, there is a code issue and configuring wrong mode for self-test Error forcing mode right, so this is the reason it is getting through earlier. But you are right maybe we also need to change the logic that terminates the mode.

    Our development team will analyze this and rectify it in next release.

    jagadish gundavarapu said:
    I mean in this testing a mismatch pattern is applied on CCM module to self-test for one clock cycle, so that means it will trigger self-test ESM error flag:

    Until then as a workaround you can poll the "self-test ESM error flag", if this is SET before timeout means "self-test Error forcing mode" executed successfully or else if timeout then there is an issue self-test Error forcing mode.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to Vandana Chintala
    Prodigy 40 points

    Also I've noticed differences between CCM Event bits enable map. I'm attaching both SDK bit configuration map enabled and bit configuration enabled for our code.

    I have used 0x001801E0 because I'm enabling only below mentioned error events (we're only using core 0):

    SDL_ESM0_R5FSS0_R5FSS0_BUS_MONITOR_ERR_PULSE_0 (69U) 

    SDL_ESM0_R5FSS0_R5FSS0_COMPARE_ERR_PULSE_0 (70U)

    SDL_ESM0_R5FSS0_R5FSS0_VIM_COMPARE_ERR_PULSE_0 (71U) 

    SDL_ESM0_R5FSS0_R5FSS0_CPU_MISCOMPARE_PULSE_0 (72U) 

    SDL_ESM0_CCM_0_SELFTEST_ERR (83U)

    SDL_ESM0_CCM_0_LOCKSTEP_COMPARE_ERR (84U)

    Could you also please clarify why BUS_MONITOR_ERR_PULSE and CPU_MISCOMPARE_PULSE events are not being enabled in the SDK code and if they are necessary to enable or not.
            

    Thanks and Regards, 
    Vandana Chintala

  • 0 in reply to Vandana Chintala
    Prodigy 40 points

     
    Hi Jagadish, 

    Could you please provide some clarification regarding this event bit map enabling and ESM event triggering in Self Test Error Forcing mode. It would be really helpful. Thankyou!

    Regards, 
    Vandana Chintala 

  • 0 in reply to Vandana Chintala
    TI__Guru* 75836 points

    Hi Vandana,

    Vandana Chintala said:
    Could you also please clarify why BUS_MONITOR_ERR_PULSE and CPU_MISCOMPARE_PULSE events are not being enabled in the SDK code and if they are necessary to enable or not.

    For CPU/VIM output compare related testing's like CCM error forcing and CCM self-test, it is not required to enable BUS_MONITOR_ERR_PULSE and CPU_MISCOMPARE_PULSE ESM signals.

    Because there is not direct impact on these signals with these tests. And these are helpful in Checker CPU Inactivity monitor.

    Vandana Chintala said:
    Could you please confirm what the expected behavior is?

    I am testing this one on my setup and will update you soon.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 40 points

    Hi Jagadish, 

    Thank you for the update. Looking forward for your results on expected behavior of self test error forcing mode.  

    Thanks and Regards, 
    Vandana Chintala

  • 0 in reply to Vandana Chintala
    TI__Guru* 75836 points

    Hi Vandana,

    My sincere apologies for the delayed response. Weekend followed by couple of days leave, so delay incurred in response.

    And today i tested in practical.

    jagadish gundavarapu said:
    As mentioned in TRM, in self-test Error forcing mode CCM registers related to self-test will not get affect by this self-test error forcing mode. Only ESM signal related to self-test will get activated after this testing.

    And this is true only ESM bits will get activating in ESM self-test error forcing mode.

    And for self-test error forcing mode testing, you just need to do below line modification in SDK code.

    Once you did this modification, please re-build the SDL library in SDK using below command.

    Once you build the SDL library in SDK now, we have to clean build our CCM example from CCS:

    Once you did clean build now flash the generated output files to OSPI using Uniflash, and run the test.

    I did and now all three tests are executing successfully at my end.

    Note: Here i added some debug logs to verify whether we are getting ESM interrupt or not for error forcing mode, and i am getting interrupt successfully and all the tests got executed successfully.

    Try this method at your end and let me know your update on this.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 40 points

    Hi Jagadish,

    Thank you very much for your response.

    I attempted writing 0xF for the self-test error forcing mode and was able to successfully trigger the SDL_ESM0_CCM_0_SELFTEST_ERR flag. However, I noticed that during the error forcing mode, three error flags are being triggered:

    • SDL_ESM0_R5FSS0_R5FSS0_COMPARE_ERR_PULSE_0

    • SDL_ESM0_R5FSS0_R5FSS0_CPU_MISCOMPARE_PULSE_0

    • SDL_ESM0_CCM_0_SELFTEST_ERR

    I am particularly curious about why the MISCOMPARE error flag is being raised, since as discussed earlier, you mentioned that this flag should not appear in this scenario (CPU Output Compare feature, Error Forcing Mode, value written = 0x9, we are not using SDK for BOOT level development)

    Additionally, I would appreciate some clarity on the below two bitmaps used in the SDK code. I would like to understand why those specific values are used and what they represent. Since I noticed that in CCM_Test_esmInitConfig_MAIN, only the lockstep compare error and self-test error event bits are enabled, while the CPU compare error pulse is not enabled in either bitmap. Please provide some input on this. 


         

    Thanks in advance for your guidance.

    Regards, 
    Vandana Chintala

  • 0 in reply to Vandana Chintala
    Prodigy 40 points

      

    Hi Jagadish,

    It would be really helpful if you could provide us with some clarity regarding the above SDK bit maps which are being enabled for CCM and ESM. Would like to know why compare error bit and Bus monitor error bit are not being enabled in particular. 

    I'm expecting below error event bits to be enabled, since we are only using RFSS0. 


    SDL_ESM0_R5FSS0_R5FSS0_BUS_MONITOR_ERR_PULSE_0 (69U)

    SDL_ESM0_R5FSS0_R5FSS0_COMPARE_ERR_PULSE_0 (70U)

    SDL_ESM0_R5FSS0_R5FSS0_VIM_COMPARE_ERR_PULSE_0 (71U)

    SDL_ESM0_R5FSS0_R5FSS0_CPU_MISCOMPARE_PULSE_0 (72U) - Ruled out based on our earlier discussion

    SDL_ESM0_CCM_0_SELFTEST_ERR (83U)

    SDL_ESM0_CCM_0_LOCKSTEP_COMPARE_ERR (84U)

    Thanks and Regards, 
    Vandana Chintala

  • +1 in reply to Vandana Chintala
    TI__Guru* 75836 points

    Hi Vandana,

    Apologies for the delayed response!

    The tests we are performing in this example are CPU Output Compare Diagnostic tests that i highlighted below.

    And these tests mainly trigger the below highlighted four ESM interrupts:

    That is the reason in ESM bitmap we enabled only these 4 interrupts:

    In above picture first two words are related to level interrupts and next word is the first 32 pulse interrupts and we are enabling four interrupts that we discussed here.

    And you are correct the below highlighted ESM interrupts also triggering during CPU Output Compare Diagnostic tests.

    And this is expected only, during error forcing mode in output compare logic, intentionally we are giving mismatch sequence to trigger CCM errors so that obviously triggers the above highlighted ESM interrupts as well. However, as per my understanding those are not required for this output compare logic tests, and TRM also didn't cover these interrupts for output compare diagnostic tests.

    TRM mentioned R5FSS0_cpu_miscompare error for Checker CPU Inactivity Monitor tests that i highlighted below:

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 40 points

    Hi Jagadish, 

    Thanks for the update. I really appreciate it.

    Regards, 
    Vandana Chintala

  • 0 in reply to Vandana Chintala
    TI__Guru* 75836 points

    Hi Vandana,

    Vandana Chintala said:
    Thanks for the update. I really appreciate it.

    My pleasure!

    --
    Thanks & regards,
    Jagadish.