N2HET: Updating the Program Field through CPU write access in case N2HET is turned on?

Hi Oliver,

Challenging question!  (but good one). 

Oliver Gr��ndonner said:

But now I would have additional questions regarding the consequences of updating the Program Field of an N2HET instruction through a CPU write access, in case the N2HET is turned ON (i.e. HETGCR.TO = 1):

1. Why there is no hint in the datasheet or the TRM (spnu499b.pdf) that such an access should not be done? Or I didn't find this hint.

I found a very weak hint in SPNS499b:

 In the earlier version of the IP (HET) this text was actually stronger:  (SPNU495C):

And in the current N2HET design, we do have the Protect Program Fields (PPF) bit 18 in HETGCR.
On the other hand, you have to modify the program field (bit 22) to set/clear a breakpoint in N2HET code when you are debugging, and you can do this while the code is running.  But this is something done during debug, not while the application is running standalone.   So I don't have a great answer for you; except I think there's something there and probably a good idea to avoid if possible.   I can do some more digging but for now I'd recommend avoidance;  so you're not in a use case that's unusual and at risk of finding new errata..

Oliver Gr��ndonner said:

2. The ADD, SUB, etc. instructions could update the bits [0..8] of the Program Field. If I understand it right, this is allowed, cause with this mechanism is assured, that the Program Field which will be udpated is currently not executed. Is this correct?

Yes but this was an enhancement that was added to N2HET and *specifically* tested.  It's also the case that the modification is from the N2HET to it's own program memory which is more coordinated than what can be done through the CPU interface.

Oliver Gr��ndonner said:

3. Assume the following HET program:

   ; At every start of a new LRP, an interrupt will be generated.
   L000: DJZ { next = L001, irq = ON, data = 0, ... }
   L001: CNT { next = L002, ... }
   
   ; Here are additional 98 instruction L002 to L099 in between, which will be executed under all circumstances.
   
   ; The Program Field of this BR instruction will be modified by a CPU write access.
   L100: BR { ... }

   ; Further instructions.

 
So at every LRP start, an interrupt will be generated, and in the called ISR will the Program Field of the BR instruction at L100 be written by a CPU write access. From this it follows that it is assured, that this BR instruction is not executed when its Program Field is updated.
Would this be already a problem for the N2HET module, or is this not a problem?
If it's a problem: What could happen?

Sorry I'm having a bit of a hard time following exactly.  What is the DJZ doing and where will the jump go on the conditional address?    I'd personally not suggest relying on the interrupt timing to synchronize the CPU to the HET program such that you plan on changing the HET program field thinking that the HET won't be executing in that area - unless you have very loose timing.  The CPU interrupt latency might be a lot more than you might expect.   Especially if your HET code is put into a system where there's an OS between the interrupt request and the execution of your HET handler code.

I think it would be better if you were to use the DJZ to ensure the BR isn't executed by jumping around it, and only change the BR when you know the DJZ is going to cause it to be skipped.  I do this a lot when debugging N2HET code and it seems to work ok.  I think we need to get a better answer for your first question - but until then I'd suggest something like the DJZ guarding instruction rather than relying on interrupt timing - as a more robust method.

On the other hand, could you change the "BR" to a DJZ and have the CPU modify the conditional address and data instead?  This type of structure is clearly within the scope of the intended use case of N2HET - as you can read about changing the control and data fields in the TRM.  If you could restructure this way - I think it would be even safer.

Oliver Gr��ndonner said:

4. Assume a CPU write access to a Program Field of an instruction happens. And at the very same point in time the same instruction will also be executed by the N2HET: What is the worst case which could happen?
   Example 1: Assume this instruction is a BR instruction, and due to the CPU write access the bit field "Next program address" will be updated from LabelOLD to LabelNEW. IMHO the worst case is, that it could not be stated in advance if the N2HET will execute as next instruction the LabelOLD or LabelNEW. Or am I wrong?
   Example 2: Assume this instruction is a PCNT instruction, and due to the CPU write access the bit field "Type select" will be updated from FALL2RISE to RISE2FALL. IMHO the worst case is, that it could not be stated in advance if the N2HET will stop counting on a rising edge (which occurred during the last LRP) or not. Or am I wrong?
   Cause if these are the worst cases, for our needs this would not be a problem.

I think these are 'reasonable' assertions - but if our designers didn't validate such cases there's always a good chance that something implementation specific and not easy to see from the high level description in the TRM could be a problem.  So I think the real question I need to research is how much validation was done with the CPU changing the NHET program while the N2HET is running.   My guess is not much as the original HET had this use case as not allowed.

Oliver Gr��ndonner said:

5. Is it possible that the N2HET could get stuck forever or some similar action (in case the Program Field of an instruction is updated by a CPU write access and the same instruction is executed at the same point in time by the N2HET)?

Yes this is the kind of 'unexpected' behavior that I'd worry about if using the N2HET outside of what it's expected use case and validation covered.   It's fear of the unknown rather than something specific you can put your finger on;  but given unknown I'd suggest trying to structure the code to avoid the CPU changing the program field if possible;  at least until we get more information.

Anthony,

again thank you for the fast and detailed response.

Regarding question 3: Assume that the bit field cond_addr is also L001. So this instruction, is only for interrupt generation. And the 100 instructions from L000 to L099 will always under all circumstances be executed. But you got the meaning of this example anyway, and I understand the argumentation in your answer.

Summarized it could be stated that your current suggestion/advice is to avoid CPU write accesses to Program Fields of N2HET instructions, in case the N2HET is turned ON.

But you also wrote "... I need to research ..." and "...until we get more information...". If I understand this right you will do more investigation regarding this topic, and post this information afterwards here.

The only question which I have now at the moment: Can you assess when new information will be available? I don't want you to tell me a specific date. I only want to know if it's feasible within the next to weeks, or if this would take a longer time duration? Reason behind this question: Depending on when the new information will be available, we have to decide how to go on with our projects.

Thank you and regards

Oliver.

Hi Anthony.

Just wanted to know, if you can already estimate when you can give me new information on this topic?

Thanks and regards,

Oliver.

Oliver,

Hi, sorry I don't have an update yet.  

Anthony.

Regarding your alternative suggestion: A colleague of mine had already a similar suggestion.

Thank you for the clarification and regards

Oliver.