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.

CCS/TMS570LS3137: Configure GIOB[2] as GPIO and Multiplexing

Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN

Tool/software: Code Composer Studio

I simply want to connect a GPIO to GIOB[2] on pin 55. Is this possible?

I am using a PGE QFP (144 pin) package. In spns162c it lists the MIBSPI3NCS[0]/AD2EVT/GIOB[2]/N2HET2_PIN_nDIS on pin 55 with a discription of:

"The application cannot output a level onto this terminal when it is configured as GIOB[2]. A pull-up is enabled 20 μA on this input. This pull cannot be disabled, and is not programmable using the GIO module pull control registers."

When looking at the pinmux settings in halcogen 4.06.00 for pin 55, I can only find the MIBSPI3NCS[0] and AD2EVT, but no GIOB[2].

Table 4-1 of spnu499b mentions the multiplexed pin of GIOB[2] is 55, but the dedicated pin is 142 (I don't see this anywhere in spns162; in fact pin 142 is something entirely different). In 4.3.3 of spnu499b it mentions connecting the N2HET2 to the MIBSPI3NCS[0]/AD2EVT for a fault detection (which is apparently how the GIOB[2] multiplexing is used?). PINMMR29[16] is set to 1 for multiplexing. But it seems like if GIOB[2] multiplexing is on, it needs to be connected to either the MIBSPI or AD2EVNT modules?

When I poll GIOB[2] in software, I'm not getting any response.

Thanks,

Ryan

  • Hi Ryan,

    PGE doesn't have a dedicated GIOB[2] pin. The BGA package has one which is pin F2 (dedicated GIOB[2). The GIOB[2] pin:

    The application cannot output a level onto this terminal when it is configured as GIOB[2]. Can you pull this pin low by external input?

    Regards,
    QJ
  • Can you pull this pin low by external input?

    Yes, sort of. At least that's whats supposed to be happening on the hardware side. I'm using two PWM's and an RC filter + another voltage signal to feed into a comparitor circuit which should drive GPIOB[2] high or low. The PWMs' outputs and the voltage signal to the compare with are fine (I have test points on those), but no test points on the GPIOB[2] directly.

    When I read in GPIOB[2], I get 0, no matter how the PWMs are outputting (this should not be the case). I've confirmed that I'm reading it right in the code, since when I set GPIOB[2] to pull-up in halcogen, GPIOB[2] reads 1.

    It's possible it is a hardware problem, but unlikely. I'm trying to make sure I have everything set up correctly in halcogen and on the software side before I blame it on hardware. Note: the GPIOA's are all operating correctly.

    I'm a little concerned that in the pinmux tab, pin 55 doesn't have an option for GPIOB_2 (whereas the GPIO_A ports do)

    For reference:

    Thanks,

    Ryan

  • Okay, I think I figured it out. spnu499b is quite confusing (Table 4-2 and Table 4-3), seeming to indicate that the PGE package does have a dedicated pin, but elsewhere it seems not.

    Regardless, I found the answer after a careful reading of this paragraph and some trial and error. According to the following from pg 299 of spnu499b:

    "The N2HET modules on this microcontroller support a mechanism to respond to faults indicated on their PIN_nDIS inputs. This input for the N2HET2 module is connected to the MibSPI3_nCS[0]/AD2EVT terminal. When this terminal is driven low, the N2HET2 can be configured to tri-state all PWMs output from the N2HET2. It is very useful to be able to generate an interrupt to the host CPU when this happens. Therefore, the MibSPI3_nCS[0] / AD2EVT signal is also available to be connected to the GIOB[2] signal. This device also contains a dedicated terminal for the GIOB[2] signal. This necessitates a multiplexor on the input connection to the GIOB[2]. This multiplexor's selection is controlled by PINMMR29[16]. When PINMMR29[16] is cleared (0, default), the connection to the GIOB[2] comes from the dedicated terminal. When PINMMR29[16] is set, the connection to the GIOB[2] comes from the MibSPI3_nCS[0] / AD2EVT terminal. Enabling this connection to the GIOB[2] allows the application to generate a GIO interrupt to the host CPU when the external fault monitor circuitry drives the MibSPI3_nCS[0] / AD2EVT terminal low to indicate a fault condition to the N2HET2 module."

    So if PGE doesn't have a dedicated GPIOB[2] input, there is no reason for PINMMR29[16] to ever be set to 0 for the PGE variant. When PINMMR29[16] set to 1, GIOB[2] input is active on pin 55 (MibSPI3_nCS[0] / AD2EVT terminal). To change this in halcogen, see the following screen capture. This box should be permanently checked and grayed out in halcogen for the PGE variant?

    Thanks,

    Ryan