• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 650 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.

AM2432: SDL ECC on Arm Cortex M4

Luis Vazquez
Prodigy 110 points
Part Number: AM2432

Hello there,

We have some questions regarding using SDL for ECC on TI Sitara AM2432 Arm-Cortex M4 core:

  1. In the ECC SDL example, SDL_ECC_AGGR1(Value 3) is passed as memtype for ECC init(SDL_ECC_init) API. Can you provide more information on this interface ?
    1. Why AGGR1 is passed as memtype?
    2. How these memtypes are linked with the physical memory?
    3. Our objective is to perform RAM test on M4 core. If we are selecting memtype as MCU_M4FSS0(SDL_MCU_M4FSS0_BLAZAR_ECCAGGR) and we wanted to perform test on ECC wrappers, How can we test it?  In TRM document, this memory is shown as inaccessible.



  2. In the TRM document(Refer: Table 12-5051) we could see 6 ECC endpoints are connected to ECC AGGR1. But in the example during ECC Initialization API( SDL_ECC_init), it selects only 2 below given ECC end points.

    IAM64_MAIN_INFRA_CBASS_MAIN_0_AM64_MAIN_INFRA_CBASS_IK3VTM_N16FFC_MAIN_0_VBUSP_P2P_BRIDGE_IK3VTM_N16FFC_MAIN_0_VBUSP_BRIDGE_BUSECC & IAM64_MAIN_INFRA_CBASS_MAIN_0_AM64_MAIN_INFRA_CBASS_MAIN_SYSCLK0_4_CLK_EDC_CTRL_CBASS_INT_MAIN_SYSCLK0_4_BUSECC).

    What about other ECC endpoints?

  3. What is the exact difference between SDL_ECC_init API and SDL_ECC_initMemory API ?
    Our understanding is SDL_ECC_initMemory has to be called multiple times to initialize multiple ECC endpoints where as we can call SDL_ECC_init just once to initialize multiple ECC endpoints. Please clarify

  4. What is the exact difference between SDL_ECC_injectError  API and SDL_ECC_selfTest API ? Please clarify below points.
    1. Can we use SDL_ECC_selfTest API during run time. Our understanding is that as it’s a blocking call it has to be used during startup only.
    2. Our understanding is that SDL_ECC_selfTest API provides ‘number of retries’ and ‘Interrupt handling mechanism’ which needs to be added additionally in case of SDL_ECC_injectError API by the user application.

  5. In the example of ECC, it is clearly shows how to inject error on ECC Interconnect using SDL_ECC_injectError API. Is it the same way for ECC Wrappers?

  6. Can you provide us more information on different Checker ‘Group ID’ and ‘Checker Type’?
    1. Parity, Redundant and Error Detect and Correct.
    2. Do we need to inject error on each and every Checker Group IDs and verify?

Thanks,

Luis

  • 0
    TI__Mastermind 19365 points

    Hi Luis, 

    I'm looking in to this query. I will provide feedback in the next couple of days.

    Thanks and Regards,
    Vishwanath Reddy.

  • 0 in reply to Vishwanath Reddy
    TI__Mastermind 19365 points

    Hi Luis, 

    Apologies for delayed response. I was on emergency leave.

    1. Example is testing 2 RAM's out of total 6 RAM's connected to the aggregator SDL_ECC_AGGR1.  Structure SDL_ECC_aggrTable in the file sdl_ecc_soc.h file contains the list of all the aggregators available on the SOC. This structure also has the details of which RAM's are connected to the aggregator. This structure corresponds to the table you have mentioned in the TRM. For inaccessible memory types, we only validate weather we get the ESM response by directly writing into ECC aggregator. 

    2. Example showcases few RAM ID's to show how to inject and detect errors. Same can be expanded to other RAMID's connected to it.

    3. SDL_ECC_init API will initialize the required interrupts(SEC/DED/Parity) for the required aggregator and for configured RAM
    ID's. SDL_ECC_initMemory will do a read and write back of the data for the configured RAM ID.

    4. Your understanding is correct. 

    5.Yes, it's the same way for either ECC wrappers on interconnect type memories.

    6. I will provide details on this point in the next couple of days.

    Thanks and Regards,
    Vishwanath Reddy.

  • 0 in reply to Vishwanath Reddy
    Prodigy 110 points

    Thanks Vishwanath (I hope everything is good on your side)
    The team will evaluate your answers and see if further information is required

  • 0 in reply to Luis Vazquez
    Prodigy 110 points

    Additional questions from the team:

    7. Gentle Reminder on Question no 6.

    8. Our objective is to perform RAM test(Data RAM and Instruction RAM) on M4 core. To test it, we need to select memtype as MCU_M4FSS0(SDL_MCU_M4FSS0_BLAZAR_ECCAGGR) and need to perform test on below areas

    • ECC wrappers i.e BLAZAR_IIRAM_ECC(address range 0x00000000 – 0x0002FFFF) & BLAZAR_IDRAM_ECC(address range 0x00030000 – 0x0003FFFF)
    • EDC Interconnect i.e BLAZAR_IIRAM_EDC_CTRL_0 & BLAZAR_IDRAM_EDC_CTRL_0

    Is it correct? Please Confirm this.

    9. According to TI’s previous reply “For inaccessible memory types, we only validate weather we get the ESM response by directly writing into ECC aggregator”, we won’t be able to perform  SDL_ECC_injectError to above inaccessible memory i.e on ECC wrappers (BLAZAR_IIRAM_ECC and BLAZAR_IDRAM_ECC). – Please Confirm this.

      1. If YES, Is there any way to inject error to this RAM area during product run time and verify that the ECC error detection functionalities are working as expected.
      2. If YES, Is this the only procedure to test this RAM area or ECC wrappers to Initialize the memory using SDL_ECC_initMemory API. then perform read and write operation, and wait for ESM response upon any detected error.  – Please Confirm this.
  • 0 in reply to Luis Vazquez
    TI__Mastermind 19365 points

    Luis,

    Thank you for your patience. 

    7:

    Checker Type:
    This can take any of the values from below:

    #define SDL_ECC_AGGR_CHECKER_TYPE_INVALID   (0U)
    #define SDL_ECC_AGGR_CHECKER_TYPE_EDC         (1U)
    #define SDL_ECC_AGGR_CHECKER_TYPE_PARITY    (2U)
    #define SDL_ECC_AGGR_CHECKER_TYPE_REDUNDANT (3U)
    This is fixed and cannot be configured. 

    Parity: 
    Parity is a form of protection to cover signals at a low cost. The function is to XOR all the bits of the signal together to produce a single code bit (with inversion), or the parity bit. This parity bit is then transported on the bus. This protection can only detect single bit errors reliably, and as such is used for the control bus signals to gain some coverage.

    Redundance:
    Redundancy is the simplest form of protection. It is only used for the main control signals on the bus, such as the main request or acknowledge. The safety signal is simply an additional bit that replicates the state of the original signal.

    EDC:
    https://www.ti.com/lit/an/spraco4a/spraco4a.pdf?ts=1705909070789&ref_url=https%253A%252F%252Fwww.google.com%252F

    Group ID: Each EDC type memory has multiple groups.
    TI recommends to inject and verify all checker Group ID's.
    8: Aggregator and RAM ID's  are correct.
    9. The M4F memories you want to test are accessible. You should be able inject and detect the errors on it. My comment is for memories which are not accessible(like R5F cache memories).
    Thanks and Regards,
    Vishwanath Reddy.
  • 0 in reply to Vishwanath Reddy
    Prodigy 110 points

    Thank you Vishwanath. I will confirm with my colleagues if there are following up questions or if this information is enough for now and we can close this ticket. 

  • 0 in reply to Vishwanath Reddy
    Prodigy 80 points

    Thanks for the reply Vishwanath, we have a good understanding for the time. We will do a test on our side and will revert back with further follow up questions, if any.