BBAI-64 Cortex-R5 gpio toggle experiment

Yes, I just hit upon the same idea…

I’m modifying your example to work with pins P8_18 and saw in my testing that some upper bits were already masked…doing XOR works with my P8_18 but havent tested with yours (but it works in on my calculator :slight_smile: )

However your approach of testing bits first by bit-shifting is the right approach otherwise by just XORing we would flip a bit to 0 if it was previously set to 1 (so running the same code twice would flop them back and forth…work one time, not work the next, etc)…so what we want is only set a bit if its 0.

XOR is only useful if you want to toggle bits. Clearing or setting bits you should use AND & OR.

I suspect there was a typo somewhere along the way as like I said

*pDir &= 0xDFFFFFFF;

Would be correct to set GPIO0_93 to an output. (~ (1<<29)) = 0xDFFFFFFF

Yes, ok I understand now XOR forces a toggle, whereas AND only ensures its set.

Thats reset. OR ensures it is set.


I’m confused, so bare with me…I think I explained poorly. This register is a mask. So if you want to set pin 1 as output you would need to set the register as 0xE (binary 1110)

Suppose that upon boot, the register was set to 0xF (1111) then we need to AND it to our mask: 0xF & 0xE (this correctly results in 1110). Likewise if we run the code a second time (so register is already starting as 1110) then: 0xE & 0xE keeps it set as 0xE (1110).

Or am I in the wrong movie totally?

From the data sheet it sets the GPIO to either input (1) or an output (0), unless I am confused, which does happen. I am going by the fact you said it was @ 0x00600060.

Also the name implies it is the data direction register.

Check the data sheet, J721E_registers4.pdf ( there is a zip file on the TI website)

Yes, so in this case @FredEckert was setting bit 29 to low (to set it as an output).

However the register was previously set to 0x7FFBFFFF (bits 18 and 31 were already low). So in order to wind up with bits 18, 29, and 31 low we would need to: 0x7FFBFFFF & 0xDFFFFFFF which yields 0x5FFBFFFF ??


*pDir &= 0xDFFFFFFF;

Takes the contents of the register and clears bit 29. The other bits are unchanged. So if low stay low, if high stay high.

But why do we want to change other bits?

To my thinking, we only want to ensure bit 29 goes low…presumably something else had previously set bits 18 and 31 low (these other pins were being used as outputs by some other process). Otherwise we risk clobbering the other GPIOs…

That is exactly what that line does. It only sets bit 29 to a 0.

You are missing the &=

*pDir &= 0xDFFFFFFF;
is the same as
*pDir =  *pDIR & 0xDFFFFFFF;

If the pDir is set to 0x7FFBFFFF, AND that with 0xDFFFFFFF results in 0x5FFBFFFF

I’m actually in 100% agreement. I suppose I said something confusing along the way which got us off track.


How does one get the R5 compilation tools? I am guessing that the gcc-arm-none-eabi tools are for this effort.

I have tried to use many install links and all have failed. It is only 124 MB and this makes me think that it is an obsolete install. I tried from armkeil’s repo online and they may or may not be sharing it for whatever reason…

Does anyone have any ideas on how to download the install of the gcc-arm-none-eabi for the BBAI-64 and/or which install is appropriate to try the available, listed examples?


This worked for me:

apt install gcc-arm-none-eabi

1 Like


I am working on windows 11 for now or at least today I am. Everything is complicated on win 11 for whatever reason. I will try a Debian Distro soon or is there a preferred Ubuntu Distro one would use?


At this moment, I think the TI SDK is based on Ubuntu 18.04, but supposedly they are moving all to Ubuntu 20.04 for the next release of SDK.

However, if you don’t plan on doing specific TI / SDK compiles, then probably Debian 11 would work fine also.

Frankly, I find it “cleaner” to just run an ubuntu dev environment in a VM hosted on my Fedora install. However it really just gets down to personal preference…

1 Like


@BarryBeagle , I will try w/ Ubuntu or Debian instead of this Windows mess I have accumulated today. Blah.


P.S. Thank you for the insight and constant truth! Linux…sheesh. I should have known.

FWIW, if what you’re doing is just compiling C for armv7, the Windows distribution of the ARM gnu tools (gnu-arm-eabi-*) is sufficient and works for me. It includes gcc and binutils (readelf, objdump, etc.). And gdb and openocd work as well. I’m not sure about whether make is included or not.

But yeah, if you want a proper Unix environment, I’d recommend using WSL.

@kaelinl ,

I am glad you brought this up. I have not found the gnu-arm-eabi for Win 11 yet. For some reason, the search led me to many links all pointing to mingw-64/32 and other sites like sourceforge.

Anyway…this is what I have done to some success but not a complete overhaul to compilation:

1. git clone
a. On number 3. of the tutorial under Windows, each download for the GNU-A and GNU-RM give issues.
b. I was able to download them but in .tar.xz format. 
c. Since the "install" of those .tar.xz formatted files for the GNU-A and GNU-RM, I went into the hickups. I cannot figure out how to handle these files w/ WSL2, MinGW-64/32, Make, Cmake, and so on...
3. I got most of what I needed out of the build process up to the point of the "hickups" w/ the toolchains.

Anyway, that is the story so far w/ Win 11. I see they have tested Win 10 but Win 11 has a something or other that needs fine tuning.


P.S. So, if anyone else is building these repos. and coming across issues under Win 11, that so far has been the issue to me and me alone. I can try on WSL2 instead of commanding Terminal to use WSL2 commands from w/in Terminal and/or Powershell.

The .xz files are not working out so far under Win 11 in any format. I have not tried Wine or other ideas…

xz-utils is installed on WSL2 but I get this error:

xz -d gcc-linaro-13.0.0-2022.11-aarch64_aarch64-unknown-linux-gnu.tar.xz
xz: gcc-linaro-13.0.0-2022.11-aarch64_aarch64-unknown-linux-gnu.tar.xz: File format not recognized

Anyway, I tried their instructions, all of them, except for the instruction to install doxygen b/c cmake is an issue so far on the Win 11 side. That is my issue so far.

Windows 10 and Windows 11 are identical for every purpose except GUI and version number inspection.

Can’t comment on TI’s SDK infrastructure.

Hello @kaelinl ,

Thank you for replying again. I am trying w/ WSL2 for some reason now. I have little faith as it is not a full-blown Linux Distro w/ all its powers and it is just a kernel w/ some odd headers. Anyway, I will report back for people following along if and when I configure things correctly.


P.S. Okay…you were right about the others. Those others, the toolchains on ARM’s site, seemed weak but they are worthy. Those toolchains work just fine. The only real concern now is the build process:

make -s -j4 clean DEVICE=am263x PROFILE=debug
make -s -j4 all   DEVICE=am263x PROFILE=debug

Please forget the DEVICE= processor part and the PROFILE= part too. I cleaned them. That worked fine.

The make command for all does not do anything and when investigating further, I start to read about why it is this way…

Can someone kindly direct me to the debug cable for the I think it is called XDS or something similar for the processor… And is it available to be handled via pinout or is that black connector near the Ethernet port for debugging via CCS?

Still trying!