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.

Flash Module Controller: Some quetions regarding three bit fields

Other Parts Discussed in Thread: TMS570LS3137

Hi.

My questions are regarding the TMS570LS3137.

1. In spnu499b.pdf, page 269, is bit field FEDACSTATUS.ECC_B2_MAL_ERR described.
Question 1.1: Will this error generate also an ESM event (e.g. ESM group 1 channel 6 event)?
Question 1.2: In case no ESM event will be generated: What is your suggestion to work with this bit? I.e.: Should it be periodically be polled? Or will this bit always be set in combination with another bit of register FEDACSTATUS?


2. In spnu499b.pdf, page 300, is bit field EE_STATUS.EE_CMG described. BUT it's not described if this bit is only relevant for diagnostic mode. I assume that it's only relevant for diagnostic mode, cause the equivalent bit field for the main flash banks FEDACSTATUS.COMB2_MAL_G (see spnu499b.pdf, page 269) is only for diagnostic mode.
Question 2.1: Can you confirm my assumption?


3. In spnu499b.pdf, page 300, is bit field EE_STATUS.EE_CME stated.
Question 3.1: There is no description stated at all. But I assume that this bit field should have a similar description as the equivalent bit field for the main flash banks FEDACSTATUS.ECC_B2_MAL_ERR (see spnu499b.pdf, page 269). Is my assumption correct?
Question 3.2: Will this error generate also an ESM event (e.g. ESM group 1 channel 35 event)?
Question 3.3: In case no ESM event will be generated: What is your suggestion to work with this bit? I.e.: Should it be periodically be polled? Or will this bit always be set in combination with another bit of register EE_STATUS?

Thank you and regards
Oliver.

  • Hello Oliver,

      My answers are inline.

    1. In spnu499b.pdf, page 269, is bit field FEDACSTATUS.ECC_B2_MAL_ERR described.
    Question 1.1: Will this error generate also an ESM event (e.g. ESM group 1 channel 6 event)?

    CT>> No, the malfunction error is a severe error if detected. When detected, it means the SECDED loses the capability to properly correct a 1-bit ECC error for access to OTP region via the Bus2 interface. When detected, the error signal will go to ESM  Group 3 channel 7.


    Question 1.2: In case no ESM event will be generated: What is your suggestion to work with this bit? I.e.: Should it be periodically be polled? Or will this bit always be set in combination with another bit of register FEDACSTATUS?

    CT>> As answered above, ESM GP3 channel 7 will be set and the nERROR pin will be asserted.


    2. In spnu499b.pdf, page 300, is bit field EE_STATUS.EE_CMG described. BUT it's not described if this bit is only relevant for diagnostic mode. I assume that it's only relevant for diagnostic mode, cause the equivalent bit field for the main flash banks FEDACSTATUS.COMB2_MAL_G (see spnu499b.pdf, page 269) is only for diagnostic mode.
    Question 2.1: Can you confirm my assumption?

    CT>> Yes, you are correct. This bit is similar to EEC_CME but only active in diagnostic mode. Outside of diagnostic mode this bit is always 0. Thank you for bringing up that the bit is not well described. We will update the document.


    3. In spnu499b.pdf, page 300, is bit field EE_STATUS.EE_CME stated.
    Question 3.1: There is no description stated at all. But I assume that this bit field should have a similar description as the equivalent bit field for the main flash banks FEDACSTATUS.ECC_B2_MAL_ERR (see spnu499b.pdf, page 269). Is my assumption correct?

    CT>> Yes, you are correct. EE_CME is a malfunction error status flag for EEPROM access on the Bus2 interface. Thank you for alerting that the bit has no description in the TRM.


    Question 3.2: Will this error generate also an ESM event (e.g. ESM group 1 channel 35 event)?

    CT>> No, the malfunction error is a severe error if detected. When detected, it means the SECDED loses the capability to properly correct a 1-bit ECC error. When detected, the error signal will go to ESM Group 1 channel 36.


    Question 3.3: In case no ESM event will be generated: What is your suggestion to work with this bit? I.e.: Should it be periodically be polled? Or will this bit always be set in combination with another bit of register EE_STATUS?

    CT>> As answered above, an ESM event will be generated to Group 1 channel 36.

    regards,

    Charles

  • Hi Charles.

    Thank you for the fast response. Your answers are already helping a lot. But I still have additional questions (I've marked them bold and underlined below). I've also inlined them.

    1. In spnu499b.pdf, page 269, is bit field FEDACSTATUS.ECC_B2_MAL_ERR described.
    Question 1.1: Will this error generate also an ESM event (e.g. ESM group 1 channel 6 event)?

    CT>> No, the malfunction error is a severe error if detected. When detected, it means the SECDED loses the capability to properly correct a 1-bit ECC error for access to OTP region via the Bus2 interface. When detected, the error signal will go to ESM  Group 3 channel 7.

    Oliver, 4.Apr.2014:

    Question 1.1.1: Is this information that an ESM group 3 channel 7 is signaled somewhere stated? If not, will the documentation be updated?

    Question 1.1.2: In case such an error will be detected (i.e. ECC_B2_MAL_ERR will be set): Must the bit field ECC_B2_MAL_ERR be cleared, so that in case a second error occurs also this second error will be forwarded to the ESM group 3 channel 7?


    Question 1.2: In case no ESM event will be generated: What is your suggestion to work with this bit? I.e.: Should it be periodically be polled? Or will this bit always be set in combination with another bit of register FEDACSTATUS?

    CT>> As answered above, ESM GP3 channel 7 will be set and the nERROR pin will be asserted.

    Oliver, 4.Apr.2014: Answered. 


    2. In spnu499b.pdf, page 300, is bit field EE_STATUS.EE_CMG described. BUT it's not described if this bit is only relevant for diagnostic mode. I assume that it's only relevant for diagnostic mode, cause the equivalent bit field for the main flash banks FEDACSTATUS.COMB2_MAL_G (see spnu499b.pdf, page 269) is only for diagnostic mode.
    Question 2.1: Can you confirm my assumption?

    CT>> Yes, you are correct. This bit is similar to EEC_CME but only active in diagnostic mode. Outside of diagnostic mode this bit is always 0. Thank you for bringing up that the bit is not well described. We will update the document.

    Oliver, 4.Apr.2014: Answered. 


    3. In spnu499b.pdf, page 300, is bit field EE_STATUS.EE_CME stated.
    Question 3.1: There is no description stated at all. But I assume that this bit field should have a similar description as the equivalent bit field for the main flash banks FEDACSTATUS.ECC_B2_MAL_ERR (see spnu499b.pdf, page 269). Is my assumption correct?

    CT>> Yes, you are correct. EE_CME is a malfunction error status flag for EEPROM access on the Bus2 interface. Thank you for alerting that the bit has no description in the TRM.

    Oliver, 4.Apr.2014: Answered.


    Question 3.2: Will this error generate also an ESM event (e.g. ESM group 1 channel 35 event)?

    CT>> No, the malfunction error is a severe error if detected. When detected, it means the SECDED loses the capability to properly correct a 1-bit ECC error. When detected, the error signal will go to ESM Group 1 channel 36.

    Oliver, 4.Apr.2014: Question 3.2.1: In case such an error will be detected (i.e. EE_CME will be set): Must the bit field EE_CME be cleared, so that in case a second error occurs also this second error will be forwarded to the ESM group 1 channel 36?

     

    Question 3.3: In case no ESM event will be generated: What is your suggestion to work with this bit? I.e.: Should it be periodically be polled? Or will this bit always be set in combination with another bit of register EE_STATUS?

    CT>> As answered above, an ESM event will be generated to Group 1 channel 36.

    Oliver, 4.Apr.2014: Answered.

     

    Oliver, 4.Apr.2014: Question 4: Is there a possibility to test the malfunctions? I.e.: Is it possible to provoke the setting of FEDACSTATUS.ECC_B2_MAL_ERR and EE_STATUS.EE_CME?

    Thank you and regards

    Oliver.

  • Hi Charles.

    I've two additional questions:

    Question 5.1: In case the FEDACSTATUS.ECC_B2_MAL_ERR error is detected, will the corresponding address be captured in register FUNC_ERR_ADD (see spnu499b.pdf, page 271)?

    Question 5.2: In case the EE_STATUS.EE_CME error is detected, will the corresponding address be captured in register EE_UNC_ERR_ADD (see spnu499b.pdf, page 301)?

    Thank you and regards,

    Oliver.

     

  • Hi Oliver,

      My answers are inline.

    Question 5.1: In case the FEDACSTATUS.ECC_B2_MAL_ERR error is detected, will the corresponding address be captured in register FUNC_ERR_ADD (see spnu499b.pdf, page 271)?

    CT>> Yes, the current address during which an ECC malfunction is detected for the OTP access via Bus2 will be saved into the FUNC_ERR_ADD register.

    Question 5.2: In case the EE_STATUS.EE_CME error is detected, will the corresponding address be captured in register EE_UNC_ERR_ADD (see spnu499b.pdf, page 301)?

    CT>> Yes, the current address during which an ECC malfunction is detected for EEprom access via Bus2 will be saved into the EE_FUNC_ERR_ADD register

    regards,

    Charles

  • Hi Oliver,

      I didn't see your new questions in green until now. Here are my answers.

    Question 1.1.1: Is this information that an ESM group 3 channel 7 is signaled somewhere stated? If not, will the documentation be updated?

    CT>> In the datasheet, i.e. spns162a.pdf, the ESM table shows that for ESM Group 3 channel 7 will be set for uncorrectable error on bus1 and bus 2 interfaces except address parity error and errors related to accesses to the  EEprom bank. Since the malfunction is a severe uncorrectable error it fits into this ESM channel. There is room for further clarification in the datasheet. Thanks for the feedback.

    Question 1.1.2: In case such an error will be detected (i.e. ECC_B2_MAL_ERR will be set): Must the bit field ECC_B2_MAL_ERR be cleared, so that in case a second error occurs also this second error will be forwarded to the ESM group 3 channel 7?

    CT>> Yes, you must clear the bit and also importantly read the FUNC_ERR_ADDR so subsequent errors can be captured. Without reading the FUNC_ERR_ADRR the error flag and address are frozen from capturing new errors.

    Oliver, 4.Apr.2014: Question 3.2.1: In case such an error will be detected (i.e. EE_CME will be set): Must the bit field EE_CME be cleared, so that in case a second error occurs also this second error will be forwarded to the ESM group 1 channel 36?

    CT>> Same explanation as above.

    Oliver, 4.Apr.2014: Question 4: Is there a possibility to test the malfunctions? I.e.: Is it possible to provoke the setting of FEDACSTATUS.ECC_B2_MAL_ERR and EE_STATUS.EE_CME?

    CT>> Same explanation as above.

    regards,

    Charles

    Please click the Verify Answer button on this post if it answers your question.

     

  • Hi Oliver,

     Let me clarify the below question. I didn't read it clearly.

    Oliver, 4.Apr.2014: Question 4: Is there a possibility to test the malfunctions? I.e.: Is it possible to provoke the setting of FEDACSTATUS.ECC_B2_MAL_ERR and EE_STATUS.EE_CME?

    CT>> Yes, you can use the diagnostic mode 4 to test the ECC malfunction. These bits will be set in diagnostic mode if faults are intentionally injected. Please refer to the FDIAGCTRL register and also Section 5.6.2 Diagnostic Mode in spnu499b.pdf.

  • Hi Charles.

    Again: Thank you for the fast feedback!

    A lot of questions were answered:

    * Question 5.1 answered.
    * Question 5.2 answered.
    * Question 1.1.1 answered.
    * Question 1.1.2 answered.
    * Question 3.2.1 answered.

    Regarding your answer for question 4: I've read
    * description of FDIAGCTRL register,
    * Section 5.6.2.3, and
    * Section 5.6.2.4
    in spnu499b.pdf. And now arised further questions:

    In spnu499b.pdf, page 258, chapter "5.6.2.3 ECC Malfunction Test Mode 3: DIAGMODE = 3" are the following bit names stated:
    * ECC_MAL_ERR
    * ECC1_MAL_ERR
    * ECC0_MAL_ERR
    BUT in the register description of the Flash Module Controller (i.e. spnu499b.pdf, page 261ff, chapter "5.7 Control Registers") I can not find these bit names! I can only find on page 269 the bit field FEDACSTATUS.ECC_B2_MAL_ERR (which was already discussed in older postings above). But this bit field is only for bus 2 (i.e. and not for bus 1).
    Question 4.1: So can you explain me how I can access the bit fields "ECC1_MAL_ERR" and "ECC0_MAL_ERR"?
    Question 4.2: Have the bit fields "ECC1_MAL_ERR"/"ECC0_MAL_ERR" and FEDACSTATUS.ECC_B2_MAL_ERR any relation?

    In spnu499b.pdf, page 258, chapter "5.6.2.4 ECC Malfunction Test Mode 4: DIAGMODE = 4" are the following bit names stated:
    * COM_MAL_GOOD
    * COM1_MAL_GOOD
    * COM0_MAL_GOOD
    BUT in the register description of the Flash Module Controller (i.e. spnu499b.pdf, page 261ff, chapter "5.7 Control Registers") I can not find these bit names! I can only find on page 269 the bit field FEDACSTATUS.COMB2_MAL_G (which was already discussed in older postings above). But this bit field is only for bus 2 (i.e. and not for bus 1).
    Question 4.3: So can you explain me how I can access the bit fields "COM1_MAL_GOOD" and "COM0_MAL_GOOD"?
    Question 4.4: Have the bit fields "COM1_MAL_GOOD"/"COM0_MAL_GOOD" and FEDACSTATUS.COMB2_MAL_G any relation?

    In spnu499b.pdf, page 269, is the bit field FEDACSTATUS.ECC_B2_MAL_ERR described. This is the ECC Malfunction Error Flag for Bus 2.
    Question 4.5: Is there no ECC Malfunction Error Flag for Bus 1? And if so: Why?

    Sorry that I'm asking that many questions, but IMHO is the current description in spnu499b.pdf not exact/detailed enough.

    Regards

    Oliver.

  • Hello Oliver,

     Let me try to clarify for Questions 4.1, 4.2, 4.3, 4.4 and 4.5 all together.

    CT>> There are no ECCx_MAL_ERR and COMx_MAL_GOOD bits implemented in Hercules devices. The TRM needs to be updated to remove any reference for these bits. Let me give a brief history. The flash wrapper was designed to also support a CPU core without a built-in ECC diangostic logic. This was actually the case for the earlier version of the Cortex-R4F. Processor such as Cortex-M3 also does not support built-in ECC logic for which out flash wrapper is the memory controller in our 470M line of products. Therefore, our flash wrapper in the beginning of the definition will support SECDED logic for the Bus1 interface. This is why you see ECCx_MAL_ERR. Our flash bank width is actually 144 bits of which are two 64-bit data and two 8-bit ECC checksum. The flash wrapper will fetch the entire 144 bits of data word at once. Since the ECC is generated based on 64-bit of data and therefore, there are two built-in SECDED logic working in parallel. This is why you see ECC0_MAL_ERR and ECC1_MAL_ERR. In any case, the key thing for you to know is that in Hercules devices, the Cortex-R4F core has the built in ECC logic. There is no more need for the local SECDED logic in the flash wrapper and hence they are not available anymore. In the register descrption they are removed but in section 5.6.2.3 they are by mistake to still show up in the documentation. I will request for an update.

    Please let me know if my answer clarify your questions.

     

  • Hi Charles.

    Again thank you for the honest and fast feedback!
    So questions 4.1, 4.2, 4.3, and 4.4 are answered. I also understand the answer for question 4.5, but now occur new questions:

    Since the ECC logic for Flash Module Controller (FMC) bus 1 is now part of the ARM Cortex-R4F core, I would expect that there is also a malfunction flag for FMC bus 1. BUT IMHO this flash should be inside the ARM core (i.e. a flag which is similar to FEDACSTATUS.ECC_B2_MAL_ERR).
    Question 4.5.1: Can you tell me if such a flag exists inside the ARM core, and where I can find further information about it? Note: I took a quick look into
      * ARM Cortex-R4 and Cortex-R4F, Revision: r1p3, Technical Reference Manual, and
      * ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition,
    and also searched the for the term "malfunction" inside this documents, but I didn't make a real find. 

    I.e. I only found in ARM Cortex-R4 and Cortex-R4F, Revision: r1p3, Technical Reference Manual the following:
      * page 8-9, chapter "8.3.2 Fault status information"
      * page 8-11, Table 8-1 Types of aborts
      * page 8-15, chapter "Handling TCM ECC errors"
      * page 4-45, chapter "4.2.18 Fault Status and Address Registers"
    But none of them talk about something like a "malfunction".

    Question 4.5.2: If such a flag exists: Is there a possibility to test it?
    Question 4.5.3: Is all status information regarding ECC errors on FMC bus 1 available through TI registers or must also ARM registers be read to get really ALL information about FMC bus 1 ECC errors? Note: In case also ARM registers have to be read I would expect that there is at least a note in TIs' spnu499b.pdf which refers to the relevant ARM document(s) and chapter(s).

    I'm really sorry Charles that I'm torturing you with my questions, but to be honest I think that the spnu499b.pdf chapter "Flash Module Controller" is not in a good shape. And that's the reason for my questions.

    Regards
    Oliver.

  • Hello Oliver,

     Your candid feedback will only make us improve our documentation. So don't feel sorry to ask questions.

    Question 4.5.1: Can you tell me if such a flag exists inside the ARM core, and where I can find further information about it?

    CT>> There is no hardware malfunction detection logic which monitors constantly the well beining of the SECDED inside the Cortex-R4F core. As you know that the two CPU cores are in lockstep. If there is any malfunction in the SECDED or faults in any part of one particular core it shall eventually be detected via the CCM module. However, this is not to say you can't perform diagnostic to check the well being of the SECDED. You can use flash wrapper's diagnostic mode 7 to verify CPU's SECDED. Using diagnsotic mode 7 you can manipulate any data bits to cause the CPU to detect a single bit errors or double bit errors.  Please look at below post about diagnostic mode 7.

    http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/307473/1070183.aspx#1070183

    Question 4.5.2: If such a flag exists: Is there a possibility to test it?

    CT>> As explained above there is no specific malfunction flags in Cortex-R4F core.

     Question 4.5.3: Is all status information regarding ECC errors on FMC bus 1 available through TI registers or must also ARM registers be read to get really ALL information about FMC bus 1 ECC errors?

    CT>> Inside the CPU there are DFSR, DFAR, IFSR and IFAR. These registers will indicate the type of fault detected by the CPU. Uncorrectable ECC fault (which will result in abort) is just one of them among others such as alignment fault, permission fault, external abort and etc. These registers will not indicate information about a 1-bit ECC fault uless you disable the ECC correction in bit 2 of the Secondary Auxiliary Control Register in the CPU. Correctable ECC status and address information can be accessed via the CFLR (Correctable Fault Location Register) register inside the CPU. When CPU detects a single bit ECC fault on the ATCM interface, it will signal this error event via its EVEVNTBUS bit 40. Likewise, for multi-bit ECC error fault, it will signal this error event via its EVENTBUS bit 37. These two signals are routed to the flash wrapper. These signals trigger the flash wrapper to capture the respective ECC flags and addresses. The flash wrapper status and address registers capture the same ECC error information. You can also look at the registers inside the CPU but there is no flags to clear. As you may know that once the flash wrapper captures an ECC error events it will freeze its flags and addresses until the address registers is read. In order to capture subsequent new ECC errors you must clear the flags and read the address. Therefore, it is important in your ECC error handler routine to do so.

  • Hi Charles.

    Now my questions are answered. Thank you for the fast response and the detailed explanation.

    Regards

    Oliver.

  • Hi Oliver,

      It is good to hear that it is clear to you know.