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.

Halcogen has problems with HET2?

Other Parts Discussed in Thread: HALCOGEN

Hi,

I'm working with a RM48HDK. The attached project is a multiple PWM example mainly following the HalCoGen included example but with 7 PWM for each HET. I've performed the same settings for both HET1 and HET2. The HET pins does not emit nothing. If I disable the HET2 driver in HalCoGen the HET1 starts to work as expected.

Do HalCoGen has some problems or known bug with HET2 PWM?

Thank you

RM48HDK_PWM_TEST.zip
  • Matteo,

    Are you still using Revision A silicon?  HET2 is in a power domain on RM48 (HET1 is always on).
    So the problems with power domains might be causing you trouble.  But I would expect something like a data abort or at least getting stuck polling a HET2 register.

    When you include HET2 - can you see the HET2 registers in the memory window?  Can you read & write to them?

    Can you confirm that you can read/write the HET2 RAM as well? 

     

  • Hi Antony,

    the silicon is a RevB. Can you suggest some way to verify this power domain problem? Tomorrow I can make some test.

    Can this trouble hinibit the HET1 to work properly when the HET2 is enabled too?

    Thank you

  • Matteo,

    Just check & confirm that you can read/write the HET2 registers & RAM  in the memory window of the debugger, at the point after you would be calling hetInit().    If you can access them then this isn't the problem.  If it's rev B silicon I don't think you have a power domain problem anyway - your HalCoGen file had PD3 (which contains the HET2) enabled.

    This would potentially block HET1 if you got stuck in hetInit() trying to program HET2...  but it doesn't sound like this is the case.

    Assuming this is not the case, then when you have enable the PWMs can you also please check the HET address register for HET1 and HET2 when you think the HETs should be running.  This is like the program counter.  You should see it constantly updating in the background as normally the HET keeps running while the debugger is attached and the CPU is stopped.

    Then, you can also look at the HET RAM to see if the address where the counter is implemented is being updated, to see if the HET is counting.  You can also look at other instructions to see what they're doing (check their data and control fields for example to see if they look like they are behaving the way you would expect w. this program).

    Last you can also look at the HET's DOUT register.  When the HET program toggles a pin it will update the DOUT register, so if you don't see DOUT changing this means that the HET program is not even trying to toggle the pin.

    If you see DOUT changing then you can check the direction of the pin to make sure it's set to output.  If it's changing and set to output then something outside the HET (like the pinmux or the muxing logic on the HDK (CBT switches)) would be where you'd look for sources of the problem.

     

  • Thank you,

    I'm going to perform the test you suggested. Meanwhile I've found a HalCoGen bug that could be related to this problem:

    http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/307954/1071678.aspx

  • As pointed here :

    http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/307954/1071678.aspx

    the problem is surely due to a HalCoGen bug.

    You can consider this thread closed.

    Thank you