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.

N2HET ECMP/MCMP influencing pin status even when en_pin_action=OFF

Hi all,

I want to simply compare two values in a N2HET PWM program without touching the pins. However, when I do an ECMP/MCMP with en_pin_action=off when no signal has been sent to that pin yet, the pin stays low forever. If I give the pin a signal first, I can safely do the same comparison without affecting the pin state. The expected behaviour would be that a ECMP/MCMP with en_pin_action=off will not in any way affect the pin behaviour, regardless of prior or posterior commands. Is this a bug or did I misunderstand something?

Kind regards,

Tim

 

 

 

 

  • Hi Tim,

    I have referred your question to one of our experts who will be getting back to you shortly

    Best regards,

    Paul

  • Hello Tim,

    I do not completely understand your issue, yet to answer the question, so let me paraphrase your issue to make sure i understand it first and please correct me if i am wrong.

    1- You are trying to compare two values using ECMP or MCMP.

    2- If you use en_pin_action=OFF, assign pin=X and do not initialize or drive any value on pin X after reset, then pin X stay low forever.

    3- If you use en_pin_action=OFF, assign pin=X and initialize pin X to a known value e.g. 1 initially, then, pin X stays at the same value (e.g. 1 ) forever.

    4- Is it the expected behavior for ECMP or MCMP?

    Can you please let me know if this is what you would like to confirm?

  • Hello Henry,

    My situation is the following:

    ABC CNT { next=BCD,reg=A,comp=GE,max=1249};

    BCD MCMP { next=CDE,en_pin_action=ON,cond_addr=CDE,pin=0,order=REG_GE_DATA,action=PULSEHI,reg=A,data=0x1F};

    CDE ECMP { next=DEF,en_pin_action=OFF,cond_addr=EFG,pin=0,reg=A,data=0};

    It works if counter ABC first points to BCD, but if I skip BCD and let ABC point directly to CDE, pin 0 will not get high again, even if CDE { en_pin_action=OFF } and another instruction with en_pin_action=ON is executed later on pin 0. I would expect these later instructions to be able to change the pin 0 status, since I just "loose" a pin this way.

    I hope that was clearer!

    Regards,

    Tim

  • Hello Tim,

    i think i understand your issue now.

    If you look at TRM: hercules_trm_spnu499.pdf section 19.2.5.4 has a "note that for each N2HET pin, only one instruction specifying a high resolution operation (hr_lr=HIGH) is allowed to execute per loop resolution period.  This includes any instructions where hr_lr=HIGH but en_pin_action=OFF."

    Another important thing is that the hr_lr is default to 0 which is high resolution mode.   Please refer to section 19.2.5.3

    Reading your example, it seems that BCD MCMP and CDE ECMP instructions using high resolution structure.  This would violate the specification.  Even if it seems to work if you counter ABC points to BCD, but this is not intended and not recommended for this back to back high resolution operation on the same pin as outline on TRM.  

    Without seeing more detail of "later" instruction, i would assume that they are also default to high resolution mode.

    Now, i noticed that you are using reg A which is 25-bit register to do ECMP, you may want to specify explicitly that hr_lr=LOW for CDE. 

    I hope that helps.

  • Hello Tim,

    BTW, if you would like to do arithmetic comparison of register A to 0, you can use SUB instruction to subtract zero from A and decide to store or not store the result into the immediate field.  this will set the Z flag if value is zero and follow by a BR on Z.  This will not affect any pin operation.  This will make use of an extra instruction, but it works without any worry of side affect on your pin.

  • Hello Henry,

    I'm a bit short on instructions, but I will try it anyway.

    A side question: if an irq is triggered during a CNT loop, will it get sent to the cpu directly or at the end of the LR cycle? I could not find anything in the spnu503 on it.

    Regards,

    Tim

  • Hi Tim,

    The irq is generated at instruction boundary and condition is true. 

    Hope this helps.

  • Tim,

    Did this resolve your issue?  If so please hit the green "verify answer" button on Henry's response and we will close the thread.  

    Thanks!

    Paul

  • Yes, it did. My bad, I read the response, planned on posting a reaction but then my attention got diverted and I forgot.

    Thanks for the great help!