The docs say that all the bits on P1 are available for GPIO, and also say that if configured as inputs, only P1_0 and P1_1 cannot be pulled. (FYI, those two tend to drift high). But here’s what I’m finding with P1_7, and I have confirmed this with 2 different devices.
Even in bootloader mode, P1_7 is driven HIGH, enough to light a 2mA LED through a 470R resistor, to ground.
under program control, with p1 set to be pulled high, and all P1 pins pins (10 -> 17) set as inputs, and PULLED, P1_7 is still apparently driven high, based on my test with the LED. If read its value, its state will typically seem to toggle with each read. So it doesn’t seem useful as an input. You can force it high or low and read its state correctly, but you pretty much have to connect it directly to 3v3 or GND to get a constant HI or LO. A external resistor pull, even as stiff as 470R won’t do it.
Obviously I’m missing an unintended conflict. The USB link in my test code is being used as an interface to transmit diagnostic messages, via usbComTxSend(), could this be an issue? I also notice p1_7 can serve as the RXD for USART1. I didn’t intentionally enable USAR1, but maybe its somehow used with the usb port? If so its not apparent from the schematic.
By default, the internal pull-up resistors on Port 0 and Port 1 will be enabled, so that would explain why you were able to get your LED to light up. You should notice the LED get signifcantly brighter when you actually drive P1_7 high.
In general, P1_7 is a useful input; we used P1_7 as the UART input line on our Wixel shield for Arduino. As you can see from the schematic, it is connected to the Arduino’s TX line through a 2.2/4.7 kilohm voltage divider but it still works fine. Of course, using it as a UART input is different from using it as a general-purpose input.
What was P1_7 connected to when you were reading its input value and it was toggling with each read?
A 20K pullup to 3.3V would provide barely 1/10 of a milliamp, assuming a LED with a 1.2V drop. (3.3 - 1.2) / 200000 = .0001. That’s not near enough to light it to the high brightness I was seeing.
It wasn’t connected to anything when i was seeing the toggling. At that point I re-connected my LED with a 470K resistor, and noticed it was still driving it to the same brightness as before the application started. I also tried connecting my LED to the other input pins for port P1, and did not see this affect. Finally I tried a different wixel, and didn’t see any different behavior.
I just tried erasing a Wixel, power cycling it, and then putting an LED (with a 100 Ohm resistor in series) from P1_7 to GND. The LED lit up very faintly. I got the same behavior for P1_6. Could you try the same thing? The size of the resistor or the type of LED shouldn’t matter too much, but you should make sure to use the “Erase Wixel” command in the Wixel Configuration Utility and then power cycle the Wixel to be absolutely sure that your code is having no effect on the result.
Thanks Dave! You were right. It is something in my code. But first of all I neglected to realize that erasing does not return board/chip states to their defaults, until I either POWER CYCLE or reset! I’m always glad when a problem is my fault, because at least it means I can fix it!
Anyway, I finally realized that my transmitter initialization was still mostly the same as the radio_test_tx example. Since it was a test application, I guess the author intended some debug via an LED, because this was included …
IOCFG2 = 0b011011; // put out a PA_PD signal on P1_7 (active low when the radio is in TX mode)
