XCTU vs API pin configuration

I just want to make sure I’m doing this correctly. Let’s say I am programming the S3B 900HP Pro, Programmable version, and am using CodeWarrior/SDK to deploy code to it. Here’s my pinout:

  • XPIN1 = VCC
  • XPIN2 = uart0 [TX Pin]
  • XPIN3 = uart0 [RX Pin]
  • XPIN4 = <>
  • XPIN5 = special0 [Reset Pin]
  • XPIN6 = ord_1 [GPIO Pin]
  • XPIN7 = <>
  • XPIN8 = special0 [BKGD Pin]
  • XPIN9 = <>
  • XPIN10 = GND
  • XPIN11 = <>
  • XPIN12 = <>
  • XPIN13 = <>
  • XPIN14 = VCC REF
  • XPIN15 = special0 [Association Pin]
  • XPIN16 = <>
  • XPIN17 = <>
  • XPIN18 = ord_ai1
  • XPIN19 = <>
  • XPIN20 = <>

What should this look like if I decide to open it up in XCTU and configure it some? Does how it look in XCTU even matter if I always intend to run it in API mode using the code I deploy?

If it does matter, are they usually configured as pull-ups for RTS/CTS/DIN/DOUT/DTR?


The pins will be the same connection to talk to XCTU. You just needs to understand the XCTU will want to talk to the RF processor via the FreeScale processor.

Even if you want to interface with the API, be it from an external processor, XCTU or the internal processor, API mode would have to be enabled.

I thought I had gotten past this issue, but I’ll bring this up again since I haven’t found a clear cut answer. My inputs are working fine now, but if I want pull protection, they only seem to be configurable as pull-ups.

My input pin 6 (GPIO10) is normally 0V/low, and driven high/VCC when active. Is there no option in the Smart Editor / somehow NOT using XCTU, to configure an Input pin as a pull-down?

Or are we just expected to provide our own external pull-downs for this purpose? Or should I just attempt to write PD at runtime, despite the documentation recommending not to?

In the Smart Editor, add the standard GPIO function. Set it for the correct pin and the direction you want.

The Smart Editor offers a radio selection for Enabled, but not direction. If you’re implying to just set PD at runtime, I’ll just do that.

No, what I am referring to is in the smart editor, right click and add a standard GIO function. In it, select the desired pin (Pin 6) and set the desired default function (active high or low).

If you’re referring to “drive strength,” then I have tried both high and low for these channels. I have also ensured the settings were carried over to the header file that the Smart Editor modifies.

Type: Input
Pullup enabled: True
Slew Rate: False
Drive Strength: High

Double checked again, testing both configurations under the assumption drive strength is what is meant by logic level active state:

Pull-up: Enabled
Drive Str: High

Pull-up: Enabled
Drive Str: Low

Both of these configurations were saved, verified against header file, main.c and project cleaned and rebuilt, and also with optimizations both enabled and disabled. The result is the GPIO pin still residing HIGH by default, and triggering low when the pin is grounded.