**** BEGIN LOGGING AT Mon Oct 26 02:59:57 2020 Oct 26 04:10:03 you just need to examine the mechanism that controls the strikers. The shift key selects with symbol is pushed if it's electrically controlled you need something for that as well. Oct 26 09:46:15 all I see now is a motor that spins a couple of pulleys w/ a belt. Oct 26 19:49:44 Hello! I'm writing program for Beaglebone Black PRU's which is using ADC. I want PRU to receive interrupt upon ADC's FIFO0THRESHOLD. I've set up PRU's INTC so when I manually set System Event 53 (as I get it, to be generated by adc), Host Interrupt 0 become visible to PRU at __R30[30]. My issue is that I cannot get System Event 53 to be set by ADC. Even if I set ADC's FIFO0THRESHOLD manually System Event 53 is not set. Please help. Oct 26 20:11:44 hmm Oct 26 20:15:06 gpvs: first two thoughts: 1. check that the MII_RT_EVENT_EN bit in the MII_RT register of the pruss CFG submodule is set to 0 (its reset default is 1). py-uio takes care of this in its initialize() function but I don't know whether libprussdrv or remoteproc-pru do so Oct 26 20:15:21 2. make sure that no linux driver is loaded for the adc Oct 26 20:16:27 DT fragment to ensure the kernel driver will not load but the adc is kept enabled: https://pastebin.com/1DpVivf6 Oct 26 20:17:43 (you can compile that into an overlay using overlay-utils, or put /dts-v1/; /plugin/; at the top and compile it directly with dtc or using bb.org-overlays) Oct 26 20:19:55 also uncomment disable_uboot_overlay_adc=1 in /boot/uEnv.txt ... that should actually suffice to keep the kernel from loading a driver for the adc, though it will also result in the adc itself being disabled, which the overlay I linked to will fix Oct 26 20:20:29 oh he left Oct 26 20:20:31 pfft Oct 26 20:30:19 Must notta wanted help... Oct 26 20:30:41 I couldn't remember all the registry bits. (pout) Oct 26 20:40:34 zmatt: I can see MII_RT register mentioned in Processor Technical Reference Manual (Rev. Q) but it is mysteriously missing from pru-software-support-package/include/am335x/pru_cfg.h. Seems like it's a right place to look for it, isn't it? Oct 26 20:41:03 zmatt: I had to reboot to linux to try what you suggested Oct 26 20:41:43 gpvs1: reboot what? your computer? why? Oct 26 20:41:47 oh Oct 26 20:41:52 why reboot to linux? Oct 26 20:43:44 zmatt: I have Code Copmoser etc. setup on linux OS. Thought Windows is not supported anymore by Code Composer. Originally logged into IRC from Windows. Oct 26 20:44:24 oh you're using code composer Oct 26 20:46:18 any specific reason why? the pru compiler itself is also preinstalled on the bbb itself, and available for download for linux (x86 and arm), mac, and windows Oct 26 20:47:07 so unless you're using ccs for jtag debugging (seems unlikely), it's basically little more than an old version of Eclipse Oct 26 20:47:42 zmatt: I'm not sure how I debug PRU code without Code Composer. Seemed like a to go solution for newbie. So I am in with jtag plugged. Might be the overkill? But what do I know :) Oct 26 20:48:33 oh wow you are actually using jtag... that's not very common :) Oct 26 20:50:32 the options for debugging pru are indeed not great... my py-uio library does have the low-level facilities for it (i.e. single-stepping and setting breakpoints) and has an example that can trace execution by printing an instruction, single-stepping, and printing any registers that changed. it does not (yet) support using the debug information from an ELF executable though, only pasm executables Oct 26 20:51:10 zmatt I was able to compile the file, there was just an issue with the file name I gave it. Though I have tried to run spidev-test and it's coming up unsuccessful. Do you have any idea why this might be? It's just not transferring any data Oct 26 20:51:17 there's also the fairly old prudebug: https://github.com/poopgiggle/prudebug Oct 26 20:51:37 pwhudson11: what file? Oct 26 20:51:57 Sorry, I asked you the other day for a dts file for the AI using spi2 Oct 26 20:53:00 zmatt: Code Composer PRU jtag debug (I don't know what exactly it uses) is fine and does what I want from it, at least for now. about MII_RT. should I add it to .h by hand? Am I using wrong version of PRU platform support? Oct 26 20:55:03 gpvs1: you can try to fix the header, or just do it the simple yet gross way: *(unsigned volatile *)0x4a32602c = 0; Oct 26 20:55:16 that address assumes you're using an AM335x-based beaglebone Oct 26 20:55:48 oh it can access cfg locally Oct 26 20:56:08 then *(unsigned volatile *)0x2602c = 0; should work regardless of which chip you use Oct 26 20:57:07 pwhudson11: double-check whether the pinmux is correctly applied, e.g. using https://github.com/mvduin/bbb-pin-utils/tree/bbai-experimental#show-pins Oct 26 20:57:20 pwhudson11: like the CAUTION says, beware that some peripheral numbering may be off by one Oct 26 20:58:51 I have show-pins, it's showing them all as SPI Oct 26 20:59:22 gpvs1: it's really bizarre that it requires jtag, since PRU debugging uses its memory-mapped interface so there's absolutely no benefit to using JTAG to access PRUSS... a small debug proxy running on linux on the beaglebone could have done the job instead Oct 26 21:00:45 pwhudson11: then it should just work, are you sure it's not a problem with however you're trying to test it? are you using a loopback connection from mosi and miso to test it? Oct 26 21:02:46 Yeah that's exactly what I have to test it. I can look at the spidev-test Oct 26 21:05:20 zmatt: well, if only I knew. but NOW I have jtag emulator in my house. back in the day, who would say I'll ever see one in person. who would say it will see ME? :) Oct 26 21:06:08 a jtag debugger can be quite handy to have, even if the circumstances are rather uncommon Oct 26 21:06:18 pwhudson11: what "spidev-test" ? Oct 26 21:06:59 zmatt: your solution with MII_RT_EVENT_EN seems to work! Thanks a lot! As an aftermath, any tips on how I could get this insight myself? By reading some resource? How did you know? Oct 26 21:08:38 https://raw.githubusercontent.com/raspberrypi/linux/rpi-3.10.y/Documentation/spi/spidev_test.c Oct 26 21:10:18 gpvs1: yep, it's described in the TRM Oct 26 21:10:53 gpvs1: I also have a spreadsheet of pruss irqs here: https://goo.gl/7YooOO#gid=785576814 Oct 26 21:11:01 obtained from the TRM Oct 26 21:11:19 note how it gives two sets of sources for events 32-55 Oct 26 21:11:33 the MII_RT_EVENT_EN bit selects between these two sets Oct 26 21:13:58 zmatt: if in doubt - (re)read the manual:) now I recall I've seen it. but assumed MII ints will be disabled by default... Could you please also point me to where in TMR is described DMA requests handling? (like when ADC issues DMA request) Oct 26 21:16:41 the EDMA chapter. for the ADC specifically the FIFO threshold events trigger edma channel 53 (for fifo 0) or 57 (for fifo 1). spreadsheet: https://goo.gl/7YooOO#gid=1709162027 (the "subarctic" column refers to am335x) Oct 26 21:19:07 I also have a header I wrote for edma (originally for baremetal C++ use though I've also used it to access from linux userspace using /dev/mem) which I used as a place to keep notes about weird/unexpected behaviours: https://liktaanjeneus.nl/edma3.h.html Oct 26 21:20:16 the edma3-tc.h header (clickable link at the top) is a good place to start if you want a basic explanation of what the transfer performed by the dma controller actually does Oct 26 21:21:35 (note: these header will not work in the pru compiler since I extensively use features of C++11 and later, which clpru does not support) Oct 26 21:24:59 zmatt: emm, 'header' here means the code used to simplify accessing its features? Oct 26 21:26:46 zmatt: or as a C header file? Sorry, I'm confused on what its function is. Oct 26 21:26:53 C/C++ header file yes Oct 26 21:27:39 zmatt: guess I need to read EDMA section of TMR first. new stuff for me. Oct 26 21:27:40 in this case declaring the structure of the EDMA controller's memory-mapped registers (as a struct) Oct 26 21:27:55 zmatt: Thank you kindly for your help! Oct 26 21:28:32 though I didn't link to it for actual use in C++ (although it can be, though not for pru), I mostly linked to it because it's also a piece of personal documentation for EDMA Oct 26 21:28:56 zmatt: oh, now I get it Oct 26 21:29:32 since I don't think the TRM is as clear as it could be, and I've definitely run into some odd behaviours when experimenting with EDMA Oct 26 21:30:11 I also don't like the TRM's tendency to give things names that look like a cat walked on your keyboard Oct 26 21:31:32 zmatt: and first key it stepped on was CAPS_LOCK_AND_IT_NEVER_STEPPED_ON_IT_AGAIN :) Oct 26 21:31:42 hehe, yes Oct 26 21:31:58 HAVE YOU EVER NOTICED HOW ALL UPPERCASE MAKES THINGS EASIER TO READ? me neither Oct 26 21:32:34 zmatt: I just with they converted all names in TMR to Sans font ;) Oct 26 21:33:15 what do you mean? most text in the TRM uses a sans serif font Oct 26 21:35:03 zmatt: there is this running joke how you don't use sans font for...well, for anything. Sort of like CAPS. Maybe it's local joke afterall. Oct 26 21:35:32 ah, woosh I guess ;) I mean, it's fine for headings Oct 26 21:36:20 though nowadays sans serif is everywhere Oct 26 22:05:10 zmatt sans font might connote without a font in other words nothing. where as sans serif refers to without serifs or the little square / pointy structures of the font (called serifs) **** ENDING LOGGING AT Tue Oct 27 02:59:57 2020