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.

Blocking behavior in case more than one flag for an ESM channel exists.

Other Parts Discussed in Thread: TMS570LS3137

Hi.

My question is regarding the TMS570LS3137.


The ESM mdoule can be configured to collect error information from other modules (e.g. DMA). In case an error occurs in one module (e.g. DMA), all corresponding flags (i.e. ESM and DMA flags) must be cleared, so that the error will be forwarded to the ESM module. My question is now: How is the blocking behavior in case more than one flag for an ESM channel exists in an other module (e.g. the DMA module)? This question is described with two example cases below:
Example for Group1, Channel 2, DMA - MPU, CASE 1:
  1.) DMAMPCTRL.INT0ENA = 1
  2.) DMAMPCTRL.INT1ENA = 1
  3.) An error occurs in DMA MPU region 1. So DMAMPST.REG1FT will be set to 1 and an error will be forwarded to the ESM module.
  4.) DMAMPST.REG1FT will NOT be cleared by intention.
  5.) An error occurs in DMA MPU region 0. So DMAMPST.REG0FT will be set to 1. QUESTION: Will now a new error be forwarded to the ESM module? Or is the forwarding already blocked cause of the set flag DMAMPST.REG1FT?
Example for Group1, Channel 2, DMA - MPU, CASE 2:
  1.) DMAMPCTRL.INT0ENA = 1
  2.) DMAMPCTRL.INT1ENA = 0
  3.) An error occurs in DMA MPU region 1. So DMAMPST.REG1FT will be set to 1 and NO error will be forwarded to the ESM module.
  4.) DMAMPST.REG1FT will NOT be cleared by intention.
  5.) An error occurs in DMA MPU region 0. So DMAMPST.REG0FT will be set to 1. QUESTION: Will now an error be forwarded to the ESM module? Or is the forwarding already blocked cause of the set flag DMAMPST.REG1FT?
NOTE: These are only two examples. But the question regarding the blocking behavior raises for ALL ESM channels for which there are two or more flags for one and the same ESM channel.

Thank you and regards

Oliver.

  • Oliver, 


    Printed this one out earlier and am now getting to it since it's a tough one.

    I'll see if I can get to it tonight.   If not just want to let you know it's not missed.

  • Oliver,

    The MPU in the DMA is unique so I would not regard this as a general answer for all IPs on the device.  They need to be asked on a case-by-case basis.

    Regarding the DMA,  each interrupt flag is and-ed with it's enable and then there is an 'or' of all the enabled interrupt flags for MPU regions - this is what is sent to the ESM.

    The ESM is edge sensitive on it's inputs.   So you would need to clear all of the MPU error interrupt flags in the DMA in order to 'unblock' a new MPU error originating from the DMA.

    In that sense then, in your CASE1 you will have already set the ESM error bit and if you have not gotten into the interrupt handler for the ESM and started looking at the DMA MPU source,  and then a new DMA MPU error occurs, you won't 'set' the ESM flag again with this new error.    So you would need to make sure that you have cleared all of the DMA MPU errors before leaving the service routine - or else you may have future errors blocked.

    In your CASE2 the disabled MPU error interrupt never causes the ESM request line to be asserted, so there is no blocking but also no event to service as far as ESM goes.  The 2nd error that occurs will generate the ESM event though.  Now in this case if you leave the 1st MPU error interrupt disabled in the DMA you woudln't necessarily need to clear it, because it couldn't block future errors on other MPU regions while disabled.

     

  • Anthony,

    thank you for the fast feedback. So for the ESM Group1, Channel 2, DMA - MPU, the behaviour is now clear. So this discussion could be closed. But as stated I need the information for all ESM channels. And since you stated "... They need to be asked on a case-by-case basis. ...", I opened the following new discussion:

    http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/304618.aspx

    Regards

    Oliver.

  • Thank you Oliver,
    I had to inspect the RTL code for the device to get this answer, which really needs to be in our TRM as you need it to program the device correctly.   We need to figure out how to get similar answers for the other IP.   I replied to this effect on your other post - as it's a bigger task and we need to talk to our manager about how to get the job done.