• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 423 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.

HalCoGen 3.5.2 - GIOB[2] input always high

Andy Kay
Intellectual 765 points

Other Parts Discussed in Thread: HALCOGEN

Hi there,

I'm working with RM46L852ZWT
I have a problem:

- GIOB[2] input is always high
- in the thread http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/262129.aspx there is a solution for that
-> solution setting bit  PINMMR29[16]

Now my question:

How can I setup HalCoGen V3.5.2 to set this bit?

Best regards,

Andy

  • 0
    Intellectual 765 points

    ok, I found the possibility in HalCoGen:

    -> HalCoGen -> PINMUX -> Special Pin Muxing
    -> "Use GIOB_2, for disabling selected HET2 PWM outputs" = YES!!!

  • 0 in reply to Andy Kay
    TI__Mastermind 49120 points

    Andy,

    I am glad. What the HALCoGen PINMUX tab does not show is the dedicated input path for GIOB[2]. This input comes from ball F2 or pin 142 by default and gets switched over to ball V10 or pin 55 when PINMMR29[16] is set.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 765 points

    Hi Sunil,

    ups, in my case it's the other way round...

    I want to get the input signal from ball F2.

    - I have to SET bit PINMMR29[16] in order to get input signal from ball F2

    Regards, Andy

  • 0 in reply to Andy Kay
    TI__Mastermind 49120 points

    Hi Andy,

    You must have silicon rev A for the RM46 MCU. There is a correction made to this implementation going from silicon rev A to rev B. The issue is described in RM46x silicon rev A errata (SPNZ187), which I cannot find on the web for some reason. I will look into the availability of this document.

    Can you please confirm the silicon revision? You can read out the device id register at address 0xFFFFFFF0 and verify that it reads 0x8046AD05. The value for silicon rev B would be 0x8046AD15.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 765 points

    Hi Sunil,

    I just had a look at SPNZ187...

    Errata says "Some multiplexing controls are not compatible with the emulation device"

    What is meant with "emulation device"?

    (I will send you my silivon rev. numbers later...)

    Regards, Andy

  • 0 in reply to Andy Kay
    TI__Mastermind 49120 points

    Hi Andy,

    The RM48x MCUs are a superset of the RM46x MCUs, except that the RM48x MCUs do not have the ePWM, eCAP, eQEP peripherals. An application written for RM46x is required to work as-is on RM48x as long as it does not use these modules. Now though, you have an added benefit of being able to trace CPU code execution (via ETM) as well as all RAM accesses (via RTP).

    In this regard, the RM48x is considered to be an emulation device for RM46x.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 765 points

    Hi Sunil,

    now, I have read out my silicon revision.

    device id register at address 0xFFFFFFF0 is 0x8046AD05,
    so it seems, that I have silivon revision A (as you wrote).

    I will pay attention to this fact and I will set (for Rev. A)
    or clear (for rev. B) bit PINMMR29[16] according to the silicon revision.

    Regards, Andy