There is a JTAG connection point on the PCB next the the SD card holder. You will see some small pads arrange in a 2x5 grid.
You can find probes from here https://www.tag-connect.com/ You will probably need one of the TC2050-IDC-NL variants, which one will depend on what debug adapter you are using. You can also buy small clips that are designed to hold the probes in place.
I am using a 6 pin SWD version for one of my PCB’s. I also have a 10 pin jtag version but I haven’t actually tried it yet.
I tired using &= for the clearing of a bit in the DIR register, and |= for setting bits in the SET and CLR registers. I ran into some weird issue were Linux would get messed up.
Here is my repo with some examples:
The README.md:
Use of &= and |= on GPIO from an R5 on the BeagleBoneAI64 breaks Linux
If I use the &= operator to clear bit 29 in the GPIO_DIR45 register, and at the same time use the |= operator to set bits 29 in the GPIO_SET_DATA45 and GPIO_CLR_DATA45 registers, random files become unreadable from linux. I also found that whenever this weird bug hits, running journal -k will not complete and when and will end with an abort message.
Making it hit
This folder has 6 example programs, 3 working and 3 not working. The bug only hits if there has not been a working example run since the last board reset/powercycle. In other words, if I run r5_toggle4_orig-working and then next run r5_toggle4_broken_1_yes-and-eql_yes-or-eql without a reset or powercycle, the broken example will seem to work and not bug out.
Alternatively, if I first reset the board and then run r5_toggle4_broken_1_yes-and-eql_yes-or-eql, the bug will hit.
Run make to build
Run sudo ./startup.sh to run the firmware
Spotting the crazy
Run journal -k and see if it aborts
Cat random files on the system until you see some weird input/output error
Random programs don’t start
Sometimes linux just flat out freezes
Random notes
bit 29 in the block 4-5 registers corresponds to pin p9-14 on the BeagleBoneAI64.
Although I have not tested, I highly suspect this issue hits with other gpio blocks and bits.
I tested this bug on two different BBAI64’s and with several different SD card of the same model and size.
I was using linux kernel 5.10 but iirc I also hit this bug on 6.x
I slowly narrowed this bug down after a week and half of fighting. That fact that the bug only hits if I had first not run a working firmware messed with me hard.
The r5 firmware seems to keep running fine when the bug hits. For the examples in this repo the p9-14 pin kept toggling after linux got messed up.
My understanding is that there are some TIers and former TIers working on OpenAMP, but I cannot say for sure. When in doubt, post on e2e.ti.com to get someone from TI to chime in. They probably won’t say much about roadmap, but there’s a chance they could point to existing efforts.
Hi @ewaldhr, Glad you liked it. Unfortunately, I don’t have an example of reading an input.
This example was developed to further my understanding of the potential of the R5F cores. This investigation shaped my modern real-time development philosophy: 1. Do everything that is not real-time on Linux, 2. Do everything that is real-time on a baremetal core. My current rule of thumb is: 0-5MHz I/O update rate = R5F, 5MHz - 50MHz = PRU, above 50MHz = FPGA. NOTE: I have not worked with PRU or FPGA yet, so this is just theoretical. If on R5F, use the SoC peripherals. Don’t write your own drivers, use the TI provided libraries to simplify development.
R5F is a full-blown 32-bit processor (CPU + FPU), therefore, it is a step above PRU in that respect. The issue is that you have to go through the bus fabric to get from the R5F to the outside world. From R5F you can bit-bang at <5MHz, with PRU, i believe you can go up to <12.5 MHz. Experimentation would have to be done to validate these numbers.
This TI document could be an intro to the concepts we are discussing:
Ensuring real-time predictability
It has been a few years since I looked at this, so I don’t have a Jacinto 7 SoC bus architecture diagram handy. The main concept is R5F has to go through one or more busses before it gets to the peripherals or the gpio. The PRU has direct IO.