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 )
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.
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).
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 ??
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…
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?
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…
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.
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 https://github.com/TexasInstruments/mcupsdk-core
2. https://github.com/TexasInstruments/mcupsdk-core#downloading-and-installing-dependencies
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.
Seth
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.
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.
Seth
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?