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 functions and HWAG information request

Other Parts Discussed in Thread: TMS570LS20216

Hi,

I've been looking for some information on the Angle functions of the N2HET, however I cannot find much.

The HET IDE does no have any example using the Angle functions in its algorithm library.

Also there is no documentation at all for the HWAG.

Could you please provide some algorithms or examples using the angle functions with the HWAG and/or proper documentation?

I would like to see how the N2HET can handle precise angle triggered pulses (for engine management applications)

Thanks.

  • Hi Fabien,

    I'm working on the HWAG documentation - not done but I will post here drafts of what I have which are register descriptions and a few figures.

    5483.NHET_REG_HWAG_DRAFTONLY.pdf

    1856.N2HET_Images.pdf

    Best Regards,

    Anthony

     

  • Hi Fabien,

    Some additional explanation:    If you look at section 19.3 of our TRM (SPNU499) which is 'Angle Functions',  there is an explanation of the software angle generator approach.  This uses two instructions (APCNT and SCNT) to generate an angle 'increment' signal.  Then the ACNT instruction increments conditionally based on this signal,  and with the ACMP instruction you can then compare your desired angle to the angle of the angle counter to trigger a pin action.

    At a very high level, the HWAG is doing the job of the APCNT and SCNT instructions in hardware so you wouldn't need them.   It passes an angle increment to the N2HET each loop resolution period and this angle increment can be more than +0 or +1,  it can actually be up to +2047.    

    Since the HWAG implements these higher rate counters in hardware and can pass a larger increment value to the loop resolution program that is running the ACNT and ACMP instructions,  you can effectively create more points between each tooth edge than you could with the software angle counter.   That's it's biggest advantage.

    The ACMP instruction is also specially tailored to angle increments more than +1.   You can see in the reference manual section 19.3.5.1 that the ACMP instruciton performs the operation:

    Old Counter Value < Compare Value <= New Counter Value

    So, with HWAG the angle increment might be something like +5 for a loop.

    Now, if your angle count from the previous loop was +10,  and the increment is +5 then the compare will match for angles 11, 12, 13, 14, 15.

    So you don't need to worry about skipping over your compare value.

    HWAG also detects singularities with the same sort of algorithm that is described in the Software Angle Generator section of the TRM, but again in hardware.

    Apologies that this section of the reference manual isn't complete yet.  Please ask any questions you might have here for now.

    Thanks and Best Regards,

    Anthony

  • Hello,

    Are there any updates in HWAG documentation?

    I can't understand how HWAG should find missed teeth for initial sync, or in the case when sync is lost? It's done in hardware, or CPU should do this job?

  • Yaroslav,

    Hi, no update yet to the user documentation.  Sorry about this.  It's taking longer than I'd hoped.

    I am in the process of getting an interface board built up so I can connect the HDK to an engine simulator that we have in our lab;  it generates the toothed wheel signal (analog though!)  and next goal is to put together some example code since others are asking.   Also I want to make sure I understand the HWAG before trying to explain it in the user's guide.

    I'll try to give some answers based on my understanding from the HWAG (TI internal) design documentation.

    The missing teeth can be detected by HWAG or it can be detected by the CPU.  It depends on how you want to do it. 

    The method of detection that is built into the CPU is to look for a case where the current tooth measurement exceeds 2x the measurement of the last tooth.   So this would be 2/3 of the way through the gap which is 3 teeth wide in a 60-2 wheel.

    At this point either an interrupt can be generated and the CPU can validate the tooth with additional 'checks' and then tell the HWAG to start the next cycle, or you can just let the HWAG roll over by itself into the next cycle.  

    The CPU *does* need to initialize the HWAG initally though on the first missing teeth event.  You can still use the logic in the N2HET to detect based on the 2x criteria, but the CPU needs to go in and tell it 'yes this is '0' now start counting.

    Last the HWAG does have a way to detect a loss of sync.  You tell the HWAG how many teeth the wheel does have and when it counts this many teeth it expects to see the missing tooth based on the 2x criteria check.   If it doesn't;  then that causes an interrupt as well and the CPU can get involved to resync.

    Hope that helps a little.  I think the next thing will be to get some example code and scope shots...

    Thanks and Best Regards,

    Anthony

  • Thank you for the answers.

    I have trigger logic fully implemented in SW on a different CPU, and I'm learning how to take benefit from N2HET. Some example code and scope shoots would be great to see. 

    Is it possible to adjust  "2x criteria"? For example 36-1 wheel has 2 teeth wide gap, so criteria threshold should be 1.33x.  

    Mitsubishi has 36-2-1 wheel with 2 different gaps on the opposite sides. Can HWAG handle two gaps?

  • Yaroslav,

    Hi, making some progress on the bench, now I've got the hardware hooked up and signal conditioning on a breadboard is working.  Have the CNCD plugged into the breadboard to receive the wheel signal.

    It's not possible to adjust the 2x criteria in hardware.   But we might be able to go to the mode where the CPU has to validate the GAP and see how much work we can get the N2HET to do for the CPU.  (maybe the N2HET code can check for the 1.33x critiera and then just have the CPU restart the next HWAG cycle if it's validated.).

    Regarding the Mitsubishi wheel, are there the same number of teeth between gaps or is it asymmetric?  i.e. is it 17 teeth, 1 tooth gap, 16 teeth, 2 teeth gap?

    Thanks and Best Regards,

    Anthony

  • Anthony,

    So we can disable HWAG gap checking function, and do checks in N2HET? Can N2HET restart HWAG without disturbing CPU? Is it possible to restart HWAG not from zero but from some different angle?

    Is it possible to see HWAG function diagram for better understanding?

    Mitsubishi wheel is 36-tooth wheel with 3 missing teeth:  17 teeth, 1 tooth gap, 16 teeth, 2 teeth gap

  • Yaroslav,

    Yaroslav Khomyak said:
    So we can disable HWAG gap checking function, and do checks in N2HET? 

    Yes.  The 2x critieria in hardware is optional.  And in fact HWAG can work with a wheel that has no missing teeth.

    Yaroslav Khomyak said:
     Can N2HET restart HWAG without disturbing CPU? 

    There might be a way, the N2HET cannot directly write to it's own control registers.  So this would involve something like a DMA request.

    Yaroslav Khomyak said:
      Is it possible to restart HWAG not from zero but from some different angle? 

    HWAG itself doesn't count angle,  the angle count is a N2HET instruction so I think it can be reset differently according to how one writes the N2HET program.

    What HWAG does is generate the 'delta angle' input that goes to the angle count instruction which is executed during each N2HET loop.  So it's basically estimating the angle increment value per N2HET loop based on the previous tooth measurement.  It does re-sync on each tooth input so there's no long term accumulation of error..

    Yaroslav Khomyak said:
      Is it possible to see HWAG function diagram for better understanding? 

    I snipped these from the internal design spec, which I shouldn't really do.  I need to clean these up and get them published.  But that will take some time and you have been very helpful so here they are,  but pls. note I cannot post the entire internal design spec.

    The big picture - shows that what HWAG does is generate an angle 'increment'  (delta angle) but the counting is done by N2HET.

    The gap checking isnt' clearly show in this figure,  but that's the main function that HWAG does other than generating the angle increment to N2HET.

     

    And a block diagram of the sub-blocks:

     

    Yaroslav Khomyak said:
      Mitsubishi wheel is 36-tooth wheel with 3 missing teeth:  17 teeth, 1 tooth gap, 16 teeth, 2 teeth gap

    Thanks - I'll try to come back to this one and think of a solution.  It would involve changing the teeth count register though, since the gap occurs after a different # of teeth for each 1/2 cycle.

  • Anthony, as I understand,

    HWAG =  APCNT + SCNT + Missing teeth logic

    We can process 60-2 wheel entirely in HW, but other wheels should be processed by SW, because HWAG missing teeth logic is not adjustable.

    Am I right?

    I'm going for a 2-week vacations in a few days. After that will try to write some code to detect 60-2 wheel. It would be nice to see some sample code if any.

  • Hi Yaroslav,

    Yes, that's about right.

    The potential upside would be to get the N2HET (v.s. the HWAG) to assist in the missing teeth detection for other configs.

    -Anthony

  • Hi Anthony,

    Do you have any example help code for 60-2 toothed wheel?

    I'm looking for this code for years for TMS570, but if you have available even to N2HET could help me.

    I'm almost giving up and leaving for the eTPU microchip.

    Best Regards,

  • Henrique,

    Nothing put together that I know of.  What do you want to do exacty?

  • Anthony

    I would like to decode the crank angle of a toothed wheel 60-2, using the NHET functions from TMS570LS20216.

     If possible, none interrupt will generated by NHET.

    Its possible, do you have any example code?

    Best Regards

  • Henrique,

    Sorry we don't have any example code for the HWAG.

  • Has any progress been made towards documentation and possibly example code?

    I have a 32 tooth trigger wheel (none missing, but could be modified) I'd like to implement a decoder for.

    Thank you.

  • Hi Kirk,

    Sadly, no. Just the information in this post so far.
    Do you know of a good way to show this function on an eval board, w.o. having to cart around a lot of hardware?
  • Hi Mr. Seely.

    How does this sound:
    - variable frequency pulse generator with 50% duty cycle, possibly generated with a N2HET module for devices with two such modules, or a timer or PWM-like module for those without. A button on the LAUNCHXL board could increment the frequency an odd amount, like 33 pulses per second or similar with each push so each increment isn't an "even" divisor of the previous or next, rolling over after 60K pulses per second to simulate a 60 tooth trigger.
    - the thing above simply inverts a GPIO pin, possibly with some logic to emulate a missing tooth; pin is active low but possibly configurable active high.
    - an N2HET watches that pin, preferably routed via external jumper so external triggers could be supplied.
    - the N2HET can toggle an LED on the LAUNCHXL2 board either showing pin events or missing tooth if the source provides, maybe output some calculation like RPM or something over USB serial back channel to a terminal window.

    A little more fancy might be to prompt the user to input tooth count and RPM in a terminal window then synthesize that for an N2HET module to decode, the point being to show how the R4 cores can change N2HET operation by writing to its registers. As an aside, this might be a way for the N2HET to decode some of the more odd trigger patterns with non-adjacent missing teeth like what's been mentioned previously.

  • Hi Kirk,

    Thanks - this all sounds pretty reasonable.

    What do you think about the angle based pulse output though. Another LED?
  • Blinking LEDs might cycle too fast to be a good visual indicator, but that would depend on the frequencies involved. For instance, the 32 tooth wheel I mentioned would be making pulses 32 times at one revolution per second; well above the point many peoples' eyes can detect flicker. A blink occurring during a "missing tooth" event would reduce that to a blink per second, but once the simulator exceeds the equivalent of 20-30 revolutions per second, the same effect would occur.

    What may be useful is having the true output present on a pin, like I'd mentioned, which can be measured with test equipment, while the system blinks an LED at some interval proportional to the true frequency.

    Maybe the simulation and decoding routines, respectively, invert two LED's on the LP so the user could see both are running, and see blinking rates increase or decrease with the changes in output frequency. Since the simulation and decoder would be independent and isolated code, both LED's showing the same states would be indicative of the decoder correctly reading the simulation.

  • Considering TMS57012 LaunchPad....
    "USER LED A" could indicate the output from the simulation; "USER LED B" could indicate the output from the decoder.
    "USER SWITCH A" could increment and "USER SWITCH B" could decrement the simulation "speed".

    An odd multiple such as 31 should provide an obvious indication the speed did in fact change.