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 Angle Generator and ACMP use information request

Other Parts Discussed in Thread: RM46L852, HALCOGEN, TMS5703137

Hi


I am trying to generate angle based output with the N2HET software angle generator.

Tools used are RM46L852 on a LaunchpadXL2 board, CCS 6.1 with TI Compiler and HET IDE.


I am using N2HET_2 to simulate a toothed wheel signal. This part of the project is working fine and producing a signal that represents a 6-1 or 6 toothed wheel rotating at 10000RPM (tooth period = 1ms).

The toothed wheel output is connected to pin N2HET1_2. The angular output is from pin N2HET1_1.

The code used in N2HET1 is as below:

; Angle Counter
L00    APCNT { type=FALL2FALL, prv=ON     , data=0 , period=0, irq=OFF };
L01    SCNT  { step=8        , gapstart=33, data=0                     };
L02    ACNT  { edge=FALLING  , gapend  =47, data=47                    };

; Angle Output Channel 1
OUT1    ACMP  { next=L00,                              en_pin_action=ON, cond_addr=OUT1CLR, pin=1, action=SET  , reg=B, data=0  };

OUT1CLR MOV64 { next=L00, remote=OUT1, comp_mode=ECMP, en_pin_action=ON, cond_addr=OUT1SET, pin=1, action=CLEAR, reg=B, data=23 };
OUT1SET MOV64 { next=L00, remote=OUT1, comp_mode=ECMP, en_pin_action=ON, cond_addr=OUT1CLR, pin=1, action=SET  , reg=B, data=0  };

The Gap Start and Gap End were calculated based on the formula in the TRM for a 6 - 1 wheel.

Gap Start = (Step Width * (actual teeth on gear - 1)) + 1 = 33

Gap End =  (Step Width * (total teeth on gear including missing)) - 1 = 47

The ACMP instruction is intended to produce at pulse rising at the beginning of the cycle and falling halfway through (rise at first falling edge fall at fourth).

The output seen on N2HET1_1 is not what I expected. The high pulse tends to span 6 or seven "teeth" of the input wheel and the low part 3 or 4 teeth. Assuming this is some kind of syncing error with the missing tooth I moved to simulating a 6 tooth wheel with no missing teeth.

Gap Start = 41, Gap End = 47.

This lead to a regular output signal with an output period of 7 teeth rise to rise with high duration of 4 teeth and low duration of 3.

After some more experimentation I found that a Gap Start and Gap End of 39 gave a cycle of six teeth. With ACMP rise = 0 and fall = 19 (half duty?) the high period is 3.5 teeth and the low 2.5 teeth.

I would have expected with a SCNT step value of 8 to have 8 counts per tooth giving a cycle overflow of 48 counts. Hence Gap End = 48 - 1 (47).

This appears to be reflected in the ACMP instruction. Using a potentiometer as input to vary the ACMP falling edge I can cleanly move from data = 0 to 39 which I would expect to be the full cycle. This seems to only span from the second falling edge in the cycle onwards.

With OUT1CLR (ACMP falling edge) data = 0: Falling edge is same angle as rising so causes high pulse of cycle length (6 teeth) then low pulse of cycle length and so on.

With OUT1CLR (ACMP falling edge) data = 1: Output rises at the first falling edge of cycle and falls just after the second falling edge of the cycle. This is where I would expect a data value of 8 to cause the falling edge to be.

With each increment of OUT1CLR up to data = 39 the falling edge is shifted smoothly along the cycle as expect.

This behavior seems to be the same with different Gap End values. The ACMP instruction is unable to set an edge within the first tooth except for data = 0 which is the very first falling edge of the cycle.

Any input would be greatly appreciated. Perhaps I have misunderstood the settings of the Gap Start and Gap End values or it is something I have completely missed. I can provide scope captures later to better explain the issue but someone may know what is going wrong in the meantime.

As a side question, I initially intended to use the HWAG but it appears it is only suitable for toothed wheels with no missing teeth or two missing teeth. Is this true?

Thanks for taking the time to read.

Rob

EDIT (31/03/2015) : Added Scope traces and corresponding notes.

Channel 1 is NHET1 Pin 2 (Input from toothed wheel signal). 1KHz 50% Duty signal to simulate 6 teeth on wheel rotating at 10000RPM.


Channel 2 is NHET1 Pin 1 (ACMP output pin). Controlled by an ACMP instruction which sets the pin to rise at ACNT 0 and fall at a varying position. Angle counter gap start and gap end along with ACMP intended start and end values are embedded into each image.

Cursors are set on the expected cycle length ( 1 engine revolution = 6 teeth ).

With ACMP set data = 0 and ACMP clear data = 0 an output which inverts once every cycle length is created. It can be seen the cycle length is 7 teeth long instead of the 6 teeth I would have expected with a Step Width of 8 and Gap End of 47.

With ACMP set data = 0 and ACMP clear data = 1 the output created is a ~1.125ms positive pulse. I would have expected ~0.125ms pulse.

ACMP set data = 0 and ACMP clear data = 7 generates a ~1.875ms positive pulse. I would have expected a ~1.00ms pulse.

The pulse width varies in a linear fashion with the increase of ACMP clear data up to 48 (overflow to 0). The ACMP seems not able to set an event within the first tooth event.

It seems like the ACNT instruction is not setting the NAF for the ACMP instruction to see during the first tooth and extending the whole cycle length by one no matter the value of Gap End.

What am I doing wrong here? I need to be able to generate an output that varies across the whole cycle range. Any help would be much appreciated.


Regards

Rob

  • Hello:

    We have received your post and will get back to you soon.

    Regards,

    Enrique
  • Can anyone help with this please? I suspect I have the SCNT Gap Start setting incorrect but have not been able to resolve anything by trial and error of values from 0 to 60+. 

    With a very basic HWAG project and toothed wheel with no missing teeth I have been able to get the ACMP instruction to set and clear the output pin at all data values (angles) between 0 and 47 as expected. This is good but the HWAG criteria only works with two missing teeth from what I have read. If this is not the case I would prefer to use the HWAG anyway but it is completely undocumented. Can anyone confirm if the HWAG can do this or not and provide information on setting it up?

  • Hi Rob,

    Wow! I'm impressed at how far along you have gotten with just a little information. Sorry we don't have this better documented.

    If you don't mind sending me your project - that will get me up to speed faster than starting from scratch; and this is something I've been sorely needing to understand better.

    The HWAG can support 0 missing teeth; with some CPU intervention I believe. There is a bit in our internal spec documented for this case - it's the ARST bit and will force the HWAG's angle count back to zero. It looks like the TCNT counter tells you when to expect the GAP by counting down to zero, and then if you know there are no missing teeth to be expected you can use this to trigger an event where you set ARST. Then when ARST is set, on the next tooth edge that comes in the ACNT resets to zero.

    There is otherwise logic in the HWAG that is tied to 2 missing teeth, in the sense that at the GAP flag, it expects that the next tooth width is (approximately) 3x the width of the previous tooth. This is checked by making sure the new tooth width is > 2x the previous width (so it allows for some significant deceleration). There doesn't seem to be a check for a tooth that is much much longer, but I think this is a reasonable assumption and if it were a problem the main HET code could probably implement a 'timeout' of sorts anyway. So this detection of the GAP that's tied to two missing teeth as far as I can tell just means that with say 1 missing tooth, you'd have issues where you wouldn't meet the criteria > 2x PCNT-1 and in this case the HWAG assumes it's lost sync w. the wheel and raises an error.

    I thought that the HWAG basically implemented the same logic as the software angle generator, but I don't see a check for 2x the previous count in the psuedo-code for the instructions you've listed. So it may be that there is more flexibility and/or we need to add the handling code for the specific tooth width as additional instructions to the software angle generator program.

    I don't quite understand the issue you're seeing w. the software angle generator and the mismatch between 6 and 7 teeth, but the HWAG tooth count register is supposed to be set to NTeeth(Actual)-1, and this means 57 for a 60-2 tooth wheel. The logic is that the 60-2 tooth wheel has 58 actual teeth, and we count that out as 0...57.

    So there are two adjustments, first 60-2 = 58 and 2nd 58-1=57. Wondering if there is not some analogy to these adjustment's that missing in your example code and producing the extra count. But need to study the code more.

    Best Regards,
    Anthony
  • Anthony F. Seely said:
    Hi Rob,

    Wow! I'm impressed at how far along you have gotten with just a little information. Sorry we don't have this better documented.



    Thanks Anthony. More documentation would be great but I must say that most of the info that has helped me progress has been from your posts on this forum.

    Anthony F. Seely said:


    If you don't mind sending me your project - that will get me up to speed faster than starting from scratch; and this is something I've been sorely needing to understand better.



    No problem, I will zip up the project today and attach it.

    Anthony F. Seely said:


    The HWAG can support 0 missing teeth; with some CPU intervention I believe. There is a bit in our internal spec documented for this case - it's the ARST bit and will force the HWAG's angle count back to zero. It looks like the TCNT counter tells you when to expect the GAP by counting down to zero, and then if you know there are no missing teeth to be expected you can use this to trigger an event where you set ARST. Then when ARST is set, on the next tooth edge that comes in the ACNT resets to zero.



    That makes sense. I have been running the HWAG without using ARST. The angle increment appears to be functioning correctly but I have noticed the ACNT register counting up towards overflow. So the HWAG is not fully synced but as the input is regular with no missing teeth the angle increment output works. Will fix this up and test.

    Anthony F. Seely said:


    There is otherwise logic in the HWAG that is tied to 2 missing teeth, in the sense that at the GAP flag, it expects that the next tooth width is (approximately) 3x the width of the previous tooth. This is checked by making sure the new tooth width is > 2x the previous width (so it allows for some significant deceleration). There doesn't seem to be a check for a tooth that is much much longer, but I think this is a reasonable assumption and if it were a problem the main HET code could probably implement a 'timeout' of sorts anyway. So this detection of the GAP that's tied to two missing teeth as far as I can tell just means that with say 1 missing tooth, you'd have issues where you wouldn't meet the criteria > 2x PCNT-1 and in this case the HWAG assumes it's lost sync w. the wheel and raises an error.



    So if I get what you are saying the HWAG will continue providing angle increments at a rate depending on the last normal tooth period (PCNT) it saw after TCNT hits zero and the GAP Flag is set? So then a GAP of one or not two missing teeth is possible but error checking will have to be provided by the CPU or HET code.

    Anthony F. Seely said:


    I thought that the HWAG basically implemented the same logic as the software angle generator, but I don't see a check for 2x the previous count in the psuedo-code for the instructions you've listed. So it may be that there is more flexibility and/or we need to add the handling code for the specific tooth width as additional instructions to the software angle generator program.

    I don't quite understand the issue you're seeing w. the software angle generator and the mismatch between 6 and 7 teeth, but the HWAG tooth count register is supposed to be set to NTeeth(Actual)-1, and this means 57 for a 60-2 tooth wheel. The logic is that the 60-2 tooth wheel has 58 actual teeth, and we count that out as 0...57.

    So there are two adjustments, first 60-2 = 58 and 2nd 58-1=57. Wondering if there is not some analogy to these adjustment's that missing in your example code and producing the extra count. But need to study the code more.

    Best Regards,
    Anthony



    Yeah my main thoughts are that the problems I'm having with SWAG are something to do with the SCNT Gap Start and ACNT Gap End settings. Maybe there is another instruction required in there or the data fields on these instructions need specific values to sync up with the input properly...

    Anyway I will attach the project later on when I have time.



    Thanks for your help.

    Rob
  • 8182.N2HET_SWAG_HWAG_PRJ.rar


    Have attached the project.

    It contains build steps to compile and pull in the HET files from relative directories so should be all good to unzip and go.

    All the action is in sys_main.c. There are #defines near the top to configure the toothed wheel signal and select SWAG or HWAG etc.

    Im using a RM46 LaunchXL2 and have just shorted HET2_PIN6 and HET1_PIN2 to get the tooth wheel signal to the angle generator input. SCI2 spits out a few interesting variables also.

    Hopefully it is clear enough. Let me know if anything needs more explanation.

    Regards

    Rob

  • Anyone had a chance to look at this?

    I've had some luck with the HWAG criteria bit enabled with a two missing teeth wheel. It seems to work the ACMP pulse looks stable but drifts around in phase with the tooth signal randomly. Sometimes it stops and sits in phase with the tooth signal but not at the correct angle. At the moment I can only put down to noise on my input maybe?

    With one missing tooth (criteria disabled) using ARST it seems no different from when ARST is not set. Not sure what is wrong there. I am setting ARST in the Gap Flag interrupt. Is this the correct way to do it?

    Regards

    Rob
  • Hi Rob,

    Not yet - but it's on my list of todos near the top. Some chance I might get started today.
  • Hi Rob,

    So just getting into the program you wrote - really nicely organized program.

    I can see the HET output toggling; but I'm not seeing any status on the serial port.
    I've got it set for 9600,N81 and I see that whenever I halt the program it's usually in the serial port 'loop' - looks like it's sending and not stuck polling a bit.

    Just to confirm, are you using the serial port built into the XDS110 (which is actually SCI1/LIN on the part) to send the messages back?

    Thanks and Best Regards,
    Anthony
  • Hi Rob,

    From the HalCoGen file it looks like VCLK2 is being set for 220MHz - maybe you can confirm this.

    Sorry about the confusion on this point - it's come up before and we only recently (MAR 2015) got an updated datasheet out that corrects this.
    The previous datasheet had a 'filtering' issue and the line with the VCLK2 max frequency was not being output.   It's 110MHz.

    So while the HET *seems* to be running fine at 2x the max freq - I wouldn't be surprised if it actually is not.   We're at room temp and the launchpads

    should be set closer to 1.26V which makes a big difference in the max frequency - but even with this and the margin that's built in 2x over the design
     limit is *a lot* - so there's probably at least some amount of timing problem going on in this example.

    So this doesn't actually conclude anything other than the fact that we need to keep the HET at 110MHz - and try again.    


    Thanks and Best Regards,

    Anthony

  • Hi Anthony

    Thanks for having a look.

    Yes I just have the XDS110 plugged into my PC and am able to see the output from the project.
    I copied training.ti.com/hercules-how-tutorial-using-sci-uart-communication to set it up. It simply outputs the ACMP Rise and ACMP Fall data fields and the Gap Start and Gap End in SWAG mode.

    Also I forgot about the pot on ADCIN_9. You will want to comment out line 415 of sys_main.c as this writes the ACMP falling data field depending on the ADC value of ADCIN_9. That will be floating around if you don't have anything connected.

    VCLK is running at 220MHz. I don't remember playing with this but I must have mucked it up somehow. Thanks for picking that up. I have changed it to 110MHz but have not seen a noticeable difference.

    From saving the HWACNT and CNT instruction data fields in a buffer at every tooth interrupt it looks like I'm having trouble keeping these in sync. I think the main thing with this is setting the ARST bit at the right time to let the HWAG know about the end of cycle. I will keep working on it but if you could provide any further information on how/when you are meant to set the ARST bit to tell the HWAG about the singularity that would be very helpful.

    Thanks
    Rob
  • Hi Rob,

    I did finally see something out of the USB->UART yesterday so, but nothing that I could read.
    Is the baud rate 9600 N8(2) - it looks like that in HalCoGen but I get garbled output at 9600 baud in PUTTY.

    When you are trying to use the HWAG - do you remove the SWAG instructions from the HET program or otherwise bypass them somehow? If not they may be interfering with the HWAG. I believe there can be only one angle counter operating in the HET at a time.
  • I'm seems to garble also on my PC after I hit a breakpoint and run again but before that it is fine. Baud Rate should be what is set in Halcogen. Sorry I don't have access to Halcogen right now.

    The first HET instruction is a branch to the SWAG or HWAG counters. It defaults to the SWAG but if USE_HWAG is defined the init code sets the cond address to the HWAG instruction.
  • Sorry I have nothing to add at the moment; just replying so I can find this later.

    Kirk
  • Hi Anthony,

    I have no missing teeth and two missing teeth (without hardware criteria) working alright now. The HET still randomly misses a count sometimes so slowly gets further and further out of sync. I'm am using the digital filter and a RC filter on the input but the HWAACNT seems to stay in sync so I don't think noise is the problem.

    As for one missing tooth I am able to get the HWAG to stay in sync with the tooth signal but it still seems to dump two missing teeth worth of angle increments into the HET counter when ARST is set and the end of gap tooth occurs. Can the HWAG work with an arbitrary amount of missing teeth or am I wasting my time here? I need the program to be able to work with any reasonable engine setup (toothed wheel) the controller encounters.
    Any more information to do with ARST or whatever needs to be done to sync up with a one or x missing teeth wheel is what I am after right now. From what I can see it looks like I would have to do hacky things with HET code or CPU intervention to get it to work.

    Thanks
    Rob
  • Hi Rob,

    So I'm still catching up to you - I think you're going to have this figured out before I do.

    I've been able to get your SWAG example running but haven't tried it in HWAG mode.

    Maybe you can tell me what switches to turn - so that I can reproduce the issue you are seeing in HWAG mode w. the counters getting out of sync.

    Regarding the loss of sync - are any of the flags in HWAFLG (offset 0xBC) being set:

    Bit 0 = Overflow period

    Bit 1 = Singularity not found

    Bit 2 = Tooth interrupt

    Bit 3 = ACNT overflow

    Bit 4 = PCNT(n) > 2 x PCNT (n-1) during normal tooth

    Bit 5 = Bad active edge tooth

    Bit 6 = Gap flag

    Bit 7 = Angle increment overflow

    At least bit 7 is documented as possibly causing the HWAG and N2HET to get out of sync if it occurs,  and maybe some of the others could also cause this.  

    How are you reading the ACNT register in the HWAG versus the angle in the N2HET RAM - to determine that they are out of sync?

    And is this something where you can see an error accumulate over time or is it just a random sort of error?

    If it's not accumulating - then it may just be an error due to the fact that you can't simultaneously read both counters, and there could be updates between reading them.   Especially if you are using CCS's memory window to read them then there could be a large amount of time between reads.   That's what I'm wondering - without seeing the result.

    Looking at the N2HET spec and a little bit at the RTL - the Criteria that sets 2 missing teeth can be disabled and replaced with a criteria you choose,  as long as you manipulate the ARST bit.      And I'm not certain about this, but I haven't seen anything indicating an upper bound on the criteria - just > 2 PCNT(n-1) for a lower bound.    So I think it should work for 2, 3, 4 missing teeth - leaving the main questions around 0, 1 missing teeth.    

    I think there may be a more modern way to manage ARST now that we have the HTU.    The docs talk about the CPU but they were written before HTU was created.   With HTU, the HET can perform limited bus mastering functions.

    So one idea might be to code up the singularity criteria in the HET -  this should be a lower rate task than interpolating between teeth which is the main thing HWAG brings - and have HET kick off the write to the ARST bit when the time is right.

    And this may also help w. keeping the two blocks in sync with each other.

    I've never tried this, but according to the datasheet there's nothing that should prevent the HTU from writing to the HET registers:

    That's still arguably 'hacky' but then it's completely contained in "HET" drivers and it's independent of CPU loading - so I think it's about as little of a hack as you can have if you're going to implement a customized criteria.

    Anyway,  if you'd let me know the steps to tweek your code for HWAG and to reproduce the loss of sync - I'll see if I can help figure out what's going on.

  • Anthony F. Seely said:

    Hi Rob,

    So I'm still catching up to you - I think you're going to have this figured out before I do.

    I've been able to get your SWAG example running but haven't tried it in HWAG mode.

    Maybe you can tell me what switches to turn - so that I can reproduce the issue you are seeing in HWAG mode w. the counters getting out of sync.

    Hi Anthony, 

    So you are seeing the same results as I did with the SWAG?

    These instructions all apply to the new version of the project I sent you. To change over to use the HWAG you need to comment out the line which contains "#define USE_SWAG" and uncomment "#define USE_HWAG". You can change the Tooth Input signal and the signal the HWAG is expecting the see by changing the values of the TOOTH_GEN_NUM_OF_TEETH/TOOTH_GEN_MISSING_TEETH and HWAG_NUM_OF_TEETH/HWAG_MISSING_TEETH #defines. 

    I've also added "#define USE_POT" which you can leave uncommented if you want the value of ADC_IN9 to change the falling edge position of the ACMP instruction. Comment it out and the falling edge will be fixed at half way through a revolution.

    Anthony F. Seely said:

    Regarding the loss of sync - are any of the flags in HWAFLG (offset 0xBC) being set:

    Bit 0 = Overflow period

    Bit 1 = Singularity not found

    Bit 2 = Tooth interrupt

    Bit 3 = ACNT overflow

    Bit 4 = PCNT(n) > 2 x PCNT (n-1) during normal tooth

    Bit 5 = Bad active edge tooth

    Bit 6 = Gap flag

    Bit 7 = Angle increment overflow

    At least bit 7 is documented as possibly causing the HWAG and N2HET to get out of sync if it occurs,  and maybe some of the others could also cause this.  

    How are you reading the ACNT register in the HWAG versus the angle in the N2HET RAM - to determine that they are out of sync?

    And is this something where you can see an error accumulate over time or is it just a random sort of error?

    If it's not accumulating - then it may just be an error due to the fact that you can't simultaneously read both counters, and there could be updates between reading them.   Especially if you are using CCS's memory window to read them then there could be a large amount of time between reads.   That's what I'm wondering - without seeing the result.

    To see what the HWAG/HET are doing sync-wise while running I have created an array which into I write the HWAG ACNT, HET ACNT and now the HWAG Flags in the ISR of every tooth interrupt. The array is big enough to let the HWAG run for a few revolutions and save the data at every tooth. I just put a breakpoint in the code where the index for the array overflows and then I can look at the data in the Expressions window.

    At moment there are two separate syncing issues.

    The first appears to be the HET randomly missing an increment. The HWAG is still running in sync but the HET is out of phase. It accumulates over time and sometimes stays in sync for many minutes of running before dropping one ACNT and then another few minutes before it happens again. This carries on until the HET winds right round and comes back in sync before carrying on off again. Sometimes the missing occurs so often the phase angle between the HWAG and HET ACNT appears to wind round and round  a couple of times a second. The unpredictability of this made me suspect some kind of noise issue but the disparity appears to be between the HWAG and the HET not the input and the HWAG so I'm not sure anymore. The Angle Increment Overflow has never been set either from what I have seen. This is only really possible for me to watch for zero missing teeth and two missing teeth due to sync issue two.

    The second issue appears to be due to the way the criteria works. Some background:

    I found online (not from TI) SPNU203 "TMS470 HWAG User Guide" which is for a different and much older processor so its accuracy is dubious. It seems to be very similar to the Hercules anyway and it noted:

    SPNU203 :2.4.1 Use of the ARST Bit In Case of a Toothed Wheel Without Singularity


    In the case of a toothed wheel that has no singularity - that is, no missing
    teeth - the ACNT must be reset once it reaches the angle zero point. In order
    to achieve this, the ARST bit should be set to 1.
    Setting the ARST bit before the reload of the tick counter will cause the
    HWAG not to reload the tick counter. It will behave as for a normal tooth,
    except that the next active edge on the toothed wheel input will reset the
    ACNT and TCNT and clear the ARST bit.

     

    SNNU203 : 2.4 Gap Verification

    ...

    If the hardware criteria is not enabled, then the user must set the bit ARST
    inside the HWACTL register to validate the singularity. This must be done
    before the active edge of the singularity tooth. Otherwise, the HWAG
    generates an interrupt and does not clear the ACNT counter when the tooth
    edge occurs.
    Note:
    For a 60-2 toothed wheel, the ARST flag needs to be set after the reload of
    the tick counter, which is when PCNT(n) = PCNT(n-1). The application
    software, by verifying the criteria, could set the ARST bit after this point.

    ...

    SPNU203 : 2.1.4 End of Cycle

    ... <During the singularity> The tick counter is first loaded with a normal value, and once it reaches zero,
    it is reloaded once with twice the step width value, as long as the Criteria flag
    is not set. PCNT(n) continues to be incremented and to check the criteria with
    PCNT(n-1) (see Section 2.4, Gap Verification ). SCNT continues to generate
    angle ticks until the tick counter reaches zero the second time. The Criteria
    flag is used to validate the tooth in order to reset the counters (see Figure 8).
    When the tooth active edge occurs, if the tick counter is not equal to zero then
    ACNT is incremented with the remainder value.

    This seems to explain why my code works for no missing teeth and two missing teeth but not one missing tooth. The way I understand it works is when ARST is set and an active tooth edge is seen the HWAG resets HWAACNT and dumps the remainder of the tick counter(if there is any) into HWAANGI. 

    So for no missing teeth this works. The last tooth edge sets the Gap Flag and the tick counter is loaded with a "normal value". My code sets ARST in the Gap Flag interrupt so on the next active edge which is the first tooth of the next cycle the HWAACNT is reset to zero and if there was any acceleration the remainder of tick counter is added to HWAANGI, sweet.

    For two missing teeth the last tooth edge sets the Gap Flag and the tick counter is loaded with a "normal value". My code loads a DJNZ instruction in the HET to cause an interrupt after  "PCNT(n) = PCNT(n-1)". The angle tick counter hits zero as PCNT reaches PCNT(n-1) and is reloaded with "twice the step width value". Soon after the DJNZ hits zero and in its ISR ARST is set. When the next active edge is seen HWAACNT is reset to zero and if there was any acceleration the remainder of the tick counter (which contains two teeth worth of steps) is added to HWAANGI, perfect.

    For one missing tooth the last tooth edge sets the Gap Flag and the tick counter is loaded with a "normal value". But then where do you set ARST?

    If the code sets ARST before PCNT reaches PCNT(n-1) the tick counter is not reloaded. When the next active edge occurs only one tooth worth of increments is added to the HET not to mention no ticks appear to have occurred during the second half of the gap so the HET is now one tooth behind the HWAG and the toothed wheel.

    If the code sets ARST after PCNT reaches PCNT(n-1) the tick counter is reloaded with twice the step width value when PCNT reaches PCNT(n-1). ARST is set and when the active edge occurs the tick counter will only be half way through decrementing to zero (as it contains two teeth worth of ticks) so the remainder will be added to HWAANGI and put the HET one tooth ahead of the HWAG and the toothed wheel.

    This seems to correlate with my observations and if correct seems to make use of a one missing tooth wheel require some kind of extra coding. I had a couple of thoughts: 

    1 - Bash the HET to zero on the first tooth active edge. Not nice, could cause ACMP to get stuff up seeing as it generates its compare over a range which the code would be messing with.

    2 - Have a flag in the HET equivalent to the gap flag which only allows the HET to be incremented so many counts during the gap. Probably suffers the same problems as 1.

    I hope my theory is mistaken and there is a way around this without using these "hacks".

    Anthony F. Seely said:

    Looking at the N2HET spec and a little bit at the RTL - the Criteria that sets 2 missing teeth can be disabled and replaced with a criteria you choose,  as long as you manipulate the ARST bit.      And I'm not certain about this, but I haven't seen anything indicating an upper bound on the criteria - just > 2 PCNT(n-1) for a lower bound.    So I think it should work for 2, 3, 4 missing teeth - leaving the main questions around 0, 1 missing teeth.    

    I think there may be a more modern way to manage ARST now that we have the HTU.    The docs talk about the CPU but they were written before HTU was created.   With HTU, the HET can perform limited bus mastering functions.

    So one idea might be to code up the singularity criteria in the HET -  this should be a lower rate task than interpolating between teeth which is the main thing HWAG brings - and have HET kick off the write to the ARST bit when the time is right.

    And this may also help w. keeping the two blocks in sync with each other.

    I've never tried this, but according to the datasheet there's nothing that should prevent the HTU from writing to the HET registers:

    <Image Removed>

    That's still arguably 'hacky' but then it's completely contained in "HET" drivers and it's independent of CPU loading - so I think it's about as little of a hack as you can have if you're going to implement a customized criteria.

    Anyway,  if you'd let me know the steps to tweek your code for HWAG and to reproduce the loss of sync - I'll see if I can help figure out what's going on.

    Definitely a good way to get the HWAG running without CPU intervention which I would definitely take advantage of.

    I would appreciate hearing your thoughts on the syncing issues as running a one missing tooth wheel is definitely a must for my project. 36-1 teeth wheels are very common on some of the engines I need to work with.  If I am going to use HWAG I don't want any hidden nasties that could cause missed events -> engine damage etc.

    Thanks,

    Rob

  • Hi,

    I'm trying to get the HWAG working, and i am currently facing the same sync problems as Rob does.

    I am currently working with a TMS570LS31x HDK,

    the tooth wheel signal is a 6 tooths signal with a gapwidth of 2 tooths wich i generate from another hardware. (also tried with a 60-2 but with same results)

    The HWAG is working like a charm including hardware-criteria, and stays in sync without an error.

    But the N2HET sometimes seems to miss some Angle-Increments from the HWAG.

    I used a StepWidth of 4, the N2HET is configured to produce a pulse every 4 angle increments, wich can be seen in the below picture (green markings)

    but sometimes angle increments seem to be missed ( red markings ).


    I am now wondering if there are some special values configurations, or something that should be taken into account like clock-frequency relations....

    Without any documentation it's hard to figure out what is wrong.

    best regards

    Roland

  • Hi Roland,


    While I have not done any more work on this I am still interested in resolving these issues so the HWAG/N2HET can be used in future engine control projects.

    Maybe there is something to do with the clock configuration that could cause the N2HET to miss an Angle Increment. I don't have any other ideas right now but happy to test out anything you think of and definitely keen to get this working properly. Maybe Anthony Seely would have some input if he has time to have a look?


    Thanks

    Rob

  • Hi Rob,

    Good to see you are still interested :)

    I think i can confirm your thoughts about the clocks,
    the occurance of an error changes dramatically if i change the prescale value for the NHET (Register HETPFR)
    the higher the prescaler the less errors occure.

    My current clock setup: HCLK/VCLK/VCLK2 all 80Mhz HETPFR at maximum HWAG StepWidth of 4

    My thoughts:
    According to some information, the HWAG puts the Angle-Increment changes per Loop-Resolution to the NHET, and there have to be something that clears the accumulated HWAG angle-increments afterwards.

    With a Stepwidth of 4 almost every CNT instruction in the HET loop will receive an angle-increment of 0, and if the increment is > 0 it should be counted regardless if the HET timer runs fast or slow.

    So what really changes with the changing loop-resolution frequency is the frequency the Increments are given to the NHET and the clearing inside the HWAG afterwards.
    According to my tests the occurance of lost Angle-Increments strongly raises with faster NHET looptimes (lower prescale values).
    I think there is either something that have to be taken into account receiving the Increments, or this might be a bug somehow.

    It would be nice to know more about how the Increments are given to the NHET, and when the HWAG clears its accumulated buffer afterwards.
    Also if the Increments are given to the NHET at loop-start or during the CNT instruction?.

    Yeah i also hope to hear from Anthony Seely, he gave good input to the HWAG in the past :)

    best regards
    Roland
  • Hi Roland, Rob,
    Still interested myself but a bit backlogged. We are trying to get an update of the HET IDE out which is mainly intended to fix issues (not add features) although we are trying to move to the current version of synapticad.
    In the process - I can see that the angle instructions are missing test cases, so this may explain why the simulator wasn't very useful when we tried the SWAG instructions. Also found that the BR NAF branches based on NAF='0' in the simulator which doesn't match the HDL.
    Probably the worst issue we've got is that there are seemingly 'minor' typos in the NHET chapter of the TRM for the angle instructions - in at least one place we can see where a clause has moved from outside to inside a {} guarded by an IF statement. The HET IDE model was written based on this TRM and then tested against the RTL -- so if there is an error in the TRM and there isn't a test case for the simulator (the 3 angle instructions) then the simulator probably isn't useful for angle at the moment. We'll get it sorted, but it's going to take longer than I'd hoped.
    Best Regards,Anthony
  • Hi,
    Currently using a different approach to solve the HWAG angle increment loss to the HET.

    The TMS5703137 i am using houses 2 N2HETs,
    1 N2HET is configured to use the HWAG, doing the startup-sync, gap/tootherrors and so on...
    the other N2HET contains the program for ingition and injetion handling and of course the angle counting instructions.

    The current Angle-Value is copied via an HTU-DMA request directly from the HWAG register to a N2HET instruction before it is placed in Register B and of course the Zflag is set if needed.

    Long story short:
    HWAG->Angle via HTU to different NHET each loop, some calculation and then the ACMP instructions can be used.
    The 2nd HWAG is neccesary because else there would be additional Angle-Increments from the HWAG.

    With this approach the ARST bit (for 1gap trigger-wheels) in the HWAG could also be set if needed by a HTUreq like it is stated above in this thread.

    The downside is currently that the increment per N2HET loop should not exceet 1 like with SWAG, but in my application this is not a limitation.

    I am currently a bit short in time, but i will come up later with some code.

    Best Regards
    Roland
  • Nice work Roland. That HTU is very handy. Will give it a try when I get a chance.

    Thanks for taking the time to share your solution.


    Regards

    Rob

  • Let me jump onto the bandwagon as well. I coded up a missing pulse generator in the N2HET in order to test the SWAG and HWAG and I don't seem to have got as far as the others. I'm hoping we can get some documentation or sample code to get a simple angle based mechanism working so I can make use of this (potentially) wonderful chip.
  • Hi Russell,

      I have a work in progress example. Please see attached. I'm still debugging quite a few things. So far I'm kind of getting the constant speed to work. In the NHET side I have setup the ACMP to set the pin high at 0 degree and reset the pin at 0.015 degree using the stepwidth of 64. My flywhee is a 60-2.  the flywheel pulse train is simululated by using NHET. Below are some of my observations. I also have some question for Rob, Roland and every bottom.

    1. After HWAG is enabled the first time it is able to detect the singularity and it is able to sync to first tooth and reset the angle counter.

    2. Once sync'ed the HWAG provides the angle increment to the NHET. The NHET is able to set and clear a pulse at the specified angles.  

    3. After a while, maybe a minute or shorter, the HWAG will lose sync and geneate an interrupt on "singularity found during normal tooth". In the ISR it will resync again. The ISR is not entered every wheel spin. It is only entered when out of sync.

    4. When "singularity found during normal tooth" is entered, I can see that the very next signal to be generated by NHET will be missed. In my example, the ACMP is supposed to assert the pin at every 0 degree and reset at every 0.015 degree.

    5. The above observation (step 3 and 4) will continue a few times until suddenly the ISR is never entered. On my scope I have setup a trigger to catch the entry of the ISR but it never show up again.

    6. I'm only able to get the constant speed to work as explained above. When I accelerate or decelerate, the synchronization is lost during acceleration/deceleration and even afterward when the speed becomes constant. I'm still debugging this.

    Rob, Roland, Russell,

      I need your expert opinions on engine control requirement. I'm not expert in the engine control at the system level. My question is during acceleration or deceleration can you afford to lose even one PWM or having the PWM generated at a wrong angle?

    5751.LS3137_NHET_HWAG.zip

  • Thanks Charles. I have yet to look at the files you provided - I'll try to get sometime to do this on the weekend.

    Regarding your question, what do you mean by pwm? I'm assuming you mean a firing or injection event. Basically you never want to miss one of these events as it will cause an engine miss. You want to track the engine angle as close as possible - minor errors are acceptable(<1 degree) , gross errors are not.

  • Hi everyone, like mentioned here are some pieces of code from my solution.

    Summary:
    Synced start of HWAG via N2HET irq,
    Angle taken from HWAG via HTU transfer every N2HET-loop
    N2HET checks for new angle, also more than 1 angle increment per loop is possible
    N2HET contains the 720 degree handling for a engine cycle
    baisc example of a injector/ignition coil (just very basic, ists not finished yet but working)
    currently only 2GAP trigger-wheels are supported,
    (for 1GAP the sync code & an HTU request for setting the ARST bit in HWAG has to be implemented)

    the code is not finished, not optimized and a bit ugly but is working, also the Cam-Signal and error detection is not included yet
    i have tested it over about an hour now, also with variable trigger-wheelspeed and it is still in sync

    Thanks also to Anthony for some pieces of gap-sync code from another thread
    e2e.ti.com/.../441057

    The usage of the files/code below is at everyones own risk. (its not fully tested yet and lacks some implementations)

    Code for htu request wich copies the Angle value to the N2HET
    void htuInit(void)
    {
    htuDCP1[0].ITCOUNT = 0x00010000 + 1; //DCP0 CPx element count = 1, frame count = BUFFERSIZE
    htuDCP1[0].IHADDRCT = ((pHET_receive_hwag_angle_0*0x10) + 8) | (1<<20) | (1<<18)| (1<<23);
    htuDCP1[0].IFADDRA = (unsigned int)&hetREG1->HWAACNT;
    htuREG1->BFINTC = 0x00000001; // disable buffer full interrupt for DCP0 CPA and CPB
    htuREG1->CPENA = 0x00000001; // enable DCP0 CPA
    htuREG1->GC = 0x00010000; // enable HTU
    }

    HET-isr to start HWAG:

    #if (pHET_sync_successfull_0 > 31)
    #error aye check pHET_sync_successfull_0 and HET-isr
    #endif
    __irq
    void het_1_isr_req_low( )
            {
            static unsigned char int_offset_val = 0, tooth_counter = 0, synced = 0;
            static unsigned long period_gap_sync, period_gap_sync_old = 0, period_gap_minimum = 0;
            
            static unsigned char toggle = 0, toggle2 = 0, clear = 0;
                
            static unsigned char highest_priority_pending;

            highest_priority_pending = hetREG1->OFF2;  //determines wich n2het command requests an isr...
                
                        hetREG1->DSET = 1<<18;
            switch( highest_priority_pending )
                    {
                    default: //this should not happen!
                    break;
                    
                    //case 1:    //instruction 0,32,64
                    //    break;
                    
                    case (pHET_sync_successfull_0+1):
                            hwag_init( hetREG1, TOOTH_NUM, USED_HWAG_STEP_WITH );             
                            hwag_enable_isr_period_overflow( hetREG1 , 0 );
                            hwag_enable_isr_singularity_not_found( hetREG1,0);
                            hwag_enable_isr_acnt_overflow( hetREG1 ,0 );
                            hwag_enable_isr_pcnt_out_of_range( hetREG1 ,0);
                            hwag_enable_isr_bad_tooth( hetREG1 ,0);
                            hwag_enable_isr_angle_inc_overflow( hetREG1 ,0);
                            hwag_enable_isr_gap_flag( hetREG1 ,0);
                            hwag_start( hetREG1 );
                        break;

                    case 33: //program OVERFLOW!!!!
                        hetREG1->DSET = 1<<00;
                        break;
                    case 34: //APCNT UNDERFLOW!!!!
                        hetREG1->DSET = 1<<00;
                        break;
                    case 35: //APCNT OVERFLOW!!!!
                        hetREG1->DSET = 1<<00;
                        break;
                    }
            }


    HET-project-code + hwag.c + hwag.h

    0143.some_files.rar

    best regards

    Roland

    Edit: for formating text / fileupload