I'm trying to use GPIO128 through GPIO135 (names later changed to GPIO192 through GPIO199?), but I keep having problems with bit 1 of that port. I can't clear that bit out of GPEDAT once it is set. See image below. I just ran the line that set GPEDAT to 0x2 and that worked, and then I ran the line that should have made it 0x4, but instead, it is 0x6.
interesting, are you 100% sure that if you use GpioG1DataRegs.GPBSET.bit.GPIO35 = 1, you don't see any error? are you scoping hte signal out to really make sure it is HIGH?
GPIO35 is one of the boot mode IOs, so please check your schematic and board if there is a contention. I tried to repeat the same experiments on my board, I don't see any issue with GPIO35- I'm able to toggle it properly and GPEDAT is not dependent on GPIO35.
Your question actually lead me to the answer. I had been watching signals on a scope, but not after I found that the problem involved writing to GPBDAT to change GPIO35. Now I have uncovered a hardware problem on my board.
Here's a final summary:
First, I noticed that bit 1 in GPEDAT was stuck on. I couldn't do anything to clear it. Including writing to group 2 GPEDAT in code, manually changing GPEDAT in a watch window, and setting bits in GPECLEAR.
Then, I noticed that the bit did NOT get stuck if I didn't write to group 1 GPBDAT to change the state of GPIO35.
Then, I started using GPBSET instead of writing to GPBDAT directly, and that kept bit 1 in GPEDAT from getting stuck high.
Today I went back and looked at GPIO129 (now called GPIO193) on the scope, and I noticed that it was 3.3V when turned on, but only about 1.7 when off. I had a hardware problem causing this. This pin corresponds to GPEDAT bit 1. Apparently, group 2 GPEDAT was picking up on the state of the actual pin, which really was stuck high. But this only happened after writing to group 1 GPBDAT. Very strange.
Now with the hardware problem resolved, I can go back and write to the GPBDAT register directly instead of using GPBSET, and everything works. GPEDAT is fine.
Thanks for all your help. I really appreciate it.
Glad to hear that you found the root cause. Good luck and feel free to post your findings, feedback and questions.
I only have GPIO35 tied to the inputs of a few logic chips. There shouldn't be any contention.
However, my hardware problem was causing contention on GPIO129. Two pins on a 74HC273 logic chip were reversed, so GPIO129 was being driven high when it was supposed to be an output.
So that was the root cause of the problem. But the behavior of GPEDAT was very strange. Bit 1 got stuck high only after writing to GPBDAT, and it would only get "unstuck" if I powered off the board.
In order to actually recreate this situation you'd have to externally drive GPIO129 high while it is configured as an output.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.