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.

HET Problen after power on reset!

Other Parts Discussed in Thread: HALCOGEN

When the program starts from power on reset the HET-pins used as pure inputs does not work. But if i start the program with my debugger the HET inputs will work OK.

The code used to initialize the HET is generated from HalCoGen. I'm using IAR Enbedded Workbench for ARM version 6.30.6 (The latest).

Pleace help me.

/Dan

  • Hello Dan,

    There are no differences with running the code after power on reset or after loading it with the JTAG. The HET pins are set as inputs or outputs via the HET register HETDIR, can you confirm the value and give us more information? How do you test the pins as inputs?

    Best regards,

    Luc

  • Hello Luc.

     

    HETDIR register is set to 0x0FFF8E, HET0 as input. When I start from power on reset HET0 is allways read as 0, but if I start via the debugger and JTAG

    I can read bouth 1 and 0 on the input.

    Here are the code for reading the pin:

    if  ((HETDIN & 1) == 1) {

     do something...

    }

    else {

      do something else...

    }

  • Hi Dan,

    Can you let me know how your PULL registers are set? It seems from your message that the pins are left floating.

    Thanks,

    Luc

  • Hi Luc,

    I have now find out what was the problem when starting from power on reset.

    It has nothing to do with my software, it´s related to JTAG and JTAG reset pin TRST.

    On the evaluatin kit there is a 100kohm pullup resistor on this pin. If we change this to 10k all seems to be working fine.

    It is also possible to solve the problem by putting the jumper at JP1 in the ARM position. In this case you will get a pullup of 1k.

    The reason for this I do not know, perhaps TI may explain it?

    It looks as if HET is involved in the JTAG intrface.

     

    /Dan

  • I've just had a similar problem and I was able to fix it by turning on the pullups (i.e. set the relevant het->PULDIS bits to 0) - it would appear that in my case at least, the HET records all input bits as 0 unless the pull-up is enabled.

  • Hello Dan and Richard,

    In the 470M devices, there is a feaure implemented to allow the input buffers to be disabled which will cause the inputs to always read as zero. Please refer to the verified answer in the following thread for details.

    http://e2e.ti.com/support/microcontrollers/hercules/f/407/p/223401/786457.aspx#786457

    Although, this other thread is regarding the DCAN pins, all IO on the divece have the same feature to disable the input buffers based on the settings for DIR, PULDIS, and PULSEL. Given the default pull direction on the HET pins is a pull down, it is very easy to inadvertantly enter this input buffer disable mode by simply setting the DIR to input and disabling the internal pull. Getting around this is equally as easy by just setting the pull direction to a pull up in conjunction with DIR = input and pull disable = disabled.

     

  • A-ha! That explains it - thank you. It might be worth explaining this a bit more clearly in the TRM ..?

  • Glad to hear that this resolves your issue, Richard. Can you verify the answer above so others that use the forum can know this resolved your issue

     

    Dan,

    Part of what you are seeing with HET inputs working during a JTAG session and not when running stand alone, is that this input disable feature is not available during an active debug session on JTAG. This means the input buffer will be enabled during JTAG and disabled during stand alone.

  • I'd love to but I'm afraid I'm not the person who asked the question and it appears that only the person who asked the question can verify the answer (is that still true? I'm afraid I could only find http://e2e.ti.com/group/helpcentral/f/301/p/64759/246696.aspx#246696 on the help forums) - I don't have the relevant verify answer button, anyway - sorry!