• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 33 subscribers
  • Views 1286 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Configure control value for a het instruction

David Sabol
Genius 4850 points

Other Parts Discussed in Thread: HALCOGEN, TMS570LS0332

Hi,

I am using the TMS570LS0332, CCS6 and Halcogen 4.1

Is there a way in halcogen to set the control value for a given instruction?  For instruction 57 I want to set the control value to (0x04000064U).  Right now the halcogen het init code sets it to (0x00000004U), but I don't  see anywhere that I can change this value.

 

I can change it manually, but it would be nice not to need to.

[EDIT] Perhaps it would be helpful to explain what I am trying to do, as there may be a better way.

 

I am generating pwm pulses through the het, and need to monitor the period and duty cycle.  This works fine, but if I break the signal path (so there is no pulse coming in) capGetSignal returns a bogus (but non-zero) duty cycle and period (ie duty cycle of 94%, period of 3.4 ms).

 

I am not the original designer, so I don't know why we want to set it up to capture on the rising and falling edge instead of always.  What is the difference?  What is the proper way to know if a signal has flat lined (always high or always low) through capGetSignal?

 

Thanks

  • 0
    TI__Expert 4580 points

    Hello:

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

    Regards.

  • 0 in reply to Enrique Lizarraga
    Genius 4850 points

    I thought I could tell if a signal has flatlined by checking the timestamp through hetGetTimestamp, however the timestamp value is updating even if there are no edges. I believe in the previous version of  halcogen the timestamp did not update when there were no edges.

     

    So what I am seeing is that once I start reading a signal through capGetSignal, you can remove the signal, but it looks like it is still there.  Also, even though I start my pulses, and then some time elapses before I call capGetSignal, the first time I check it always returns 0 for the duty cycle and period.  Is this normal?

  • 0 in reply to David Sabol
    TI__Guru 69050 points

    David,

    No that does not sound normal.  Have you tried simulating this w. the HET IDE?

  • 0 in reply to Anthony F. Seely
    Genius 4850 points

    Thanks for the response.

     

    No, I haven't used the HET IDE, I'll take a look.

     

    It is easy enough for me (for now) to ignore the first reading.  What is more important to me is knowing when the signal has flat lined.

     

  • 0 in reply to David Sabol
    TI__Guru 69050 points

    Ok maybe I didn't read carefully enough.   It looks like there are 2 problems.


    1) You see the edges occurring even after the signal has flatlined.  Not normal.


    2) You must ignore the first input capture.  Could be normal.

    Depending on the instruction (From the TRM)

    PCNT: Note: For FALL2FALL/RISE2RISE, the user should always discard the first interrupt/HTU request if
    interrupt/request are enabled before HET_ON. For both the types, reset edge and capture edge are the
    same and the interrupt or HTU request is triggered on capture edge (which is nothing but the reset edge).
    Once the execution unit is enabled, the first edge generates an interrupt but the value of the counter is of
    no use as this is not the period between 2 edges. So first edge after turning on N2HET is used mainly for
    resetting the counter and start the period count.

    WCAP in HR Mode: The HR Counter starts on a WCAP instruction execution (in the first
    loop clock) and will synchronize to the next loop clock. When N2HET is turned on and a
    capture edge occurs in the first loop clock (where the HR counter hasn’t been synchronized
    to the loop clock), then the captured HR counter value is wrong and is of no use. So the
    captured HR data in the first loop clock should be ignored.

  • 0 in reply to Anthony F. Seely
    Genius 4850 points

    Thanks.  I'll read capture the signal before I actually want to use the info and discard the result.

    1) You see the edges occurring even after the signal has flatlined.  Not normal.

     

    DS - What is normal?  Say I have a signal with a duty cycle of 50% and a period of 7 ms.  When the signal is valid, I get a response from capGetSignal of something like

    duty - 49

    period - 6997.85...

    When the signal is broken, will the duty cycle and period still report those values, but the timestamp *should* remain the same?

    If it matters, I'm trying to monitor the pulse every ms.

    As I am continuing to figure out what is going on, I got rid of looking at the timestamp, and I have found that when the signal is OK, I get a correct values (the duty cycle and period above).  When I then physically disrupt the waveform,  I read values like

    duty - 65

    period - 5255

    So I can tell this is bad because I have a tolerance set on my checks.  But sometimes it retains the value it had before.

     

    I guess I'm still left with the question, how do you tell for sure that a signal has flatlined using the capGetSignal function?

     

    Thanks

  • 0 in reply to David Sabol
    Genius 4850 points

    A little more info...

     

    I was trying to monitor the signal every 1 ms.  Because I was seeing strange behavior with the timestamp, I stored the timestamp value for 1000 samples in an array, and then graphed the results. (1msGraph, attached). Note that there is no pulse going in to the pin I am capturing.

    I initialized the array so the data was all 1000000.  As you can see, after every valid timestamp, two or three samples read 0 before the next valid timestamp.

     

    I then did the same thing, but changed the interval to 10 ms.  (10msGraph, attached).  This looks much better. However, my application needs to react to a flat line within 10ms, so I need something that goes faster.

     

    So..

     

    Is 1 ms just too fast to read the timestamp / getCapSignal?  What is the fastest rate on a 1227? A 3137 seems to be able to monitor it at 1kHz without an issue.

    Again, I see the timestamp increasing even with no signal (no edges) coming in.  I don't know how I can tell if the signal has flat lined (high or low).

     

    Thanks

     

  • 0 in reply to David Sabol
    Genius 4850 points

    Hi,

    Any update to what proper behavior from capGetSignal is, why the het timestamp might increase with no edges, or if there is a limit to the read rate (why I see 0 readings)?

    I'm dead in the water until I get this working  (or I have to use edge interrupts and calculate it on my own)

    Thanks

  • 0 in reply to David Sabol
    TI__Guru 69050 points

    David,

    No idea how PCNT would give you an increasing result with a flatline input.

    capGetSignal is a fancy way to read from a particular address in the HET RAM.

    It's code is just this:

    void capGetSignal(hetRAMBASE_t * hetRAM, uint32 cap, hetSIGNAL_t *signal)
    {
        uint32    pwmDuty   = (hetRAM->Instruction[(cap << 1U) + 25U].Data) >> 7U;
        uint32    pwmPeriod = (hetRAM->Instruction[(cap << 1U) + 26U].Data) >> 7U;

        signal->duty   = (pwmDuty * 100U) / pwmPeriod;

        if( hetRAM == hetRAM1)
        {
            signal->period = ((float64)pwmPeriod * 1280.000F) / 1000.0F;
        }
        else
        {
            signal->period = ((float64)pwmPeriod * 1280.000F) / 1000.0F;
        }
    }

    So things could go wrong.  Are you passing the correct pointer to the function - it should be the base address of the HET RAM.  What are you passing as cap?   It's going to use this as an index into the HET RAM.

    The PCNT instructions start at instruction 25 and 26 in the HET RAM so that's 0x19 and 0x1A for the first cap,  0x1B and 0x1C for the 2nd. etc.

    Now each instruction is 16 bytes so the addresses you would look at are 0x190, 0x1A0,, 0x1B0, 0x1C0, etc offset from the beginning of the HET RAM.  

    The data field of the instruction will be 0x198, 0x1A8, 0x1B8 etc.

    So you can open a memory window in CCS and check these offsets from the beginning of the HET RAM while your program stalled (or running if you inspect through DAP).   They shouldn't be updating if there are no edges to update on. 

    The only thing I can think of that might make them update (and I doubt it... ) is that there is a max spec for how long a pulse input to PCNT can be ... basically the 25 bit counter eventually rolls over.  But I would expect this is an alias issue not a increasing count issue.  And I don't think you would be seeing it until you have several seconds if it were there just based on how long a 25 bit counter would take to roll over at 10ns * loop resolution period ticks. 

    You might really be better served here writing a custom HET program.  It would be very easy to make a loop that included a DJZ which is reset whenever an edge is detected on a pin to your timeout value, and when it decrements to 0 have it jump to an interrupt the CPU.   That's only 3 lines of HET code (maybe 4 if the DJZ doesn't interrupt, I'd have to pull out the TRM to check that.. ) and then you get rid of all the polling.  Plus your detection time becomes bascially tied to your loop resolution so if you have a loop resolution of 128 cycles at 10ns you would be triggering that interrupt within about 1.3us of hitting whatever detection time you set.

    Downside to this is you have to learn the HET IDE and learn to make your own program - but really the program that  comes w. HalCoGen is just a 'starter' program trying to be a general purpose timer.  We expect most people to grow out of this and once you learn the HET IDE you can make the HET do things that fit your app really well.

  • 0 in reply to Anthony F. Seely
    Genius 4850 points

    Thanks for the thorough response... I'll look into the HET IDE.