<hnv>
I'm trying to do `ret = request_irq(responder->from_pruss_irq, responder_serve_irq, IRQF_ONESHOT, dev_name(dev), responder);` but I get `genirq: Flags mismatch irq 22. 00002000 (4802a000.i2c) vs. 00000080 (TI-am335x-adc.0.auto)`... my implementation is based on BeagleLogic
brook has quit [Remote host closed the connection]
<ayjay_t>
god you get to a point where you really want to stop writing tests because you're on test case 500 or something but you cant stop because they're still leading you to fix things
buzzmarshall has quit [Quit: Konversation terminated!]
Shadyman has joined #beagle
brook has joined #beagle
brook has quit [Ping timeout: 256 seconds]
hnv has quit [Quit: Client closed]
mvaittin has joined #beagle
ikarso has joined #beagle
brook has joined #beagle
brook has quit [Ping timeout: 255 seconds]
ft has quit [Quit: leaving]
mvaittin has quit [Remote host closed the connection]
mvaittin has joined #beagle
mvaittin has quit [Ping timeout: 268 seconds]
Stat_headcrabed has joined #beagle
hnv has joined #beagle
Shadyman has quit [Quit: Leaving.]
<hnv>
ayjay_t: In my case, I feel like I'm Achilles chasing the turtle. Progressing but not reaching the goal
<hnv>
I temporarily fixed `genirq: Flags mismatch`, just matching the flags but doing `LDI R31, (1<<5) | (SYSEV_PRU0_TO_ARM_A - 16)` cannot trigger IRQ 22, ( `SYSEV_PRU0_TO_ARM_A = 22` )
mvaittin has joined #beagle
hnv has quit [Quit: Client closed]
hnv has joined #beagle
brook has joined #beagle
Siegurd has joined #beagle
<Siegurd>
Why when I touch the AGND pin with the oscilloscope probe does the program on the PRU freeze (RPMSG also stops working) even after rewriting the program in the PRU? Only restarting the BBB helps.
<hnv>
Siegurd: If you have common mode noise (e.g. by using a floating psu), shorting that noise to mains earth can make all sort of issues
<hnv>
(floating psu but with a small leakage from mains through some capacitors)
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook has joined #beagle
Siegurd has quit [Quit: Leaving]
hnv has quit [Quit: Client closed]
hnv has joined #beagle
ft has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
hnv has quit [Quit: Client closed]
hnv has joined #beagle
vagrantc has joined #beagle
mvaittin has joined #beagle
Stat_headcrabed has quit [Quit: Stat_headcrabed]
vagrantc has quit [Quit: leaving]
Siegurd has joined #beagle
hnv has quit [Quit: Client closed]
hnv has joined #beagle
russ has quit [Ping timeout: 252 seconds]
russ has joined #beagle
russ has quit [Read error: Connection reset by peer]
russ has joined #beagle
mvaittin has quit [Ping timeout: 256 seconds]
<zmatt>
Siegurd: any chance that stuff connected to your beaglebone causes its ground potential to be different from the ground potential of your scope? (the latter of which is typically on protective earth)
<zmatt>
Siegurd: try making sure the power supply ground of the beaglebone is solidly connected to a ground terminal on the scope
<Siegurd>
this also happens with battery-powered multimeter probes
<zmatt>
Siegurd: I'm assuming your PRU program uses the ADC ?
<Siegurd>
yes
<zmatt>
okay so presumably PRU hangs because the ADC hangs, presumably as a result of getting electrically glitched up somehow
<zmatt>
lemme try putting a multimeter on a beaglebone's AGND here to see if anything happens
<zmatt>
e.g. between AGND and VDD_ADC
<Siegurd>
yes, but why echo 'stop' > /sys/class/remoteproc/remoteproc2/state
<Siegurd>
and start does not return it to working state?
<zmatt>
I mean, define "working state" ? stopping and restarting the PRU obviously won't do anything to fix a problem with the ADC
<zmatt>
depending on the severity of the issue it's also conceivable the ADC is causing register access to hang, in which case it would cause PRU to lock up in a way I'm not sure is recoverable
<Siegurd>
yep, everything in my PRU program is based on register event
<zmatt>
I'm cancelling my plan to try probing a beaglebone here, it seems a bit too fiddly for me right now :P
<Siegurd>
))
<zmatt>
it seems unlikely the mere act of probing it with a multimeter really shouldn't cause a problem unless you maybe accidently short it to something
<hnv>
Siegurd: If you are using a floating switching supply, usually there is an Y capacitor between primary and secondary that causes common mode noise with respect to mains earth. Any path, the osc probe, you, etc... will make a voltage glitch at the point you are probing.
<zmatt>
hnv: "Siegurd> this also happens with battery-powered multimeter probes"
<zmatt>
hnv: your hypothesis was my guess too, but it doesn't explain the same happening with a portable multimeter
<zmatt>
hnv: what exactly is your driver for btw?
<Siegurd>
is there a way to reset R30/R31 PRU registers system?
<zmatt>
what do you mean?
<Siegurd>
I use PYBE20-Q24-S5 DC/DC for 24 to 5V and Lab. power source 220VAC to 24V
<Siegurd>
I mean that if it hangs it should have some mechanism to be restored
<zmatt>
hnv: your interrupts property is definitely wrong btw, each interrupt is supposed to be a 3-tuple <event channel irq>
<hnv>
zmatt: Any path :P, you can act as a very poor capacitor, skin, floor etc.. I did some research on a similar problem on a raspberry pi, and the only solution was to put an Y capacitor, or a direct short, between GND and mains earth, to avoid those glitches https://github.com/HN-Vignolles/R-Pi/tree/main/RUN-Reset
<zmatt>
yeah actually grounding the beaglebone ground sounds like a good idea to at least try
<zmatt>
Siegurd: again, since presumably it's the ADC that's locked up and PRU is merely locking up as a side-effect of trying to access the ADC, resetting PRU is not going to solve anything
<Siegurd>
oh, got it now
<Siegurd>
so the ADC system should be reseted then
<hnv>
zmatt: The interrupt part of my driver was taken from BeagleLogic, I'm plain noob with respect to Linux interrupts
<zmatt>
Siegurd: I don't recall it having a reset
<zmatt>
hnv: oh that's curious.... I know remoteproc-pru has had multiple incompatible changes over time so I may be comparing with DT for a different kernel version
<zmatt>
hnv: just curious, what's your driver doing exactly?
<zmatt>
and what kernel version are you using?
<zmatt>
ah yeah, pruss_intc interrupt specification changed between kernel 5.4 and 5.10
<zmatt>
so that's something to watch out for I guess
<hnv>
zmatt: Linux BeagleBone 5.10.168-ti-r72 #1xross SMP PREEMPT Mon Nov 20 14:43:28 -03 2023 armv7l GNU/Linux
<hnv>
The driver configures the i2c1 module, and one PRU (shared mem, firmware, etc). The PRU then manages the I2C as slave. The PRU should notify the ARM once all data was received
<zmatt>
sounds like it could be done just as easily from userspace with uio :P
* zmatt
likes uio
<zmatt>
(apart from the hacky thing they did with interpreting mmap page offset)
<hnv>
yeah... it was fun though. Is the `resource_table_empty.h` okay?
<zmatt>
depends on whether you have any resources to declare :P
<zmatt>
the resource table is a data structure used to enable the program to declare certain stuff to the loader and/or for the loader to provide the program with some data only known at load time, such as the location of allocated memory regions
<zmatt>
hnv: btw, the name "to_pruss" suggests to me your driver shouldn't be declaring it as an interrupt
<zmatt>
the interrupts property declares interrupts to be delivered to your driver
brook has joined #beagle
<zmatt>
I guess that's also just something bogus they did in kernel 5.4 remoteproc-pru that was fixed in 5.10 ?
<hnv>
in that gist, and BeagleLogic, apparently `SYSEV_PRU0_TO_ARM_A` -> Ch4 -> Host 4. But just as declaration, and no actual mapping? The mapping is done in the DT?
brook_ has quit [Ping timeout: 260 seconds]
<zmatt>
dunno how or where mapping was done in 5.4, but in 5.10 it appears you indeed declare it in DT, at least for irqs delivered to linux... are irqs to the program maybe declared via the resource table?
brook has quit [Remote host closed the connection]
<zmatt>
I'm not sure how I feel about these mappings being made part of the interrupt spec since all interrupts that use a particular channel do need to agree on which irq that channel should be mapped to
<Siegurd>
I connected SPI CLK (8MHz) to P9.31 but it makes noise to P9.33 AIN4 channel. When I disable SPI device - noise disappears. Pins 31 and 33 are very close to each other. Any ideas how to solve this problem?
brook has joined #beagle
<zmatt>
hnv: note: I don't actually use remoteproc-pru so my knowledge of it is pretty limited, I use uio instead
<zmatt>
hnv: with pruss_intc I don't really understand why they even bother with using more than one host_irq since regardless of which host irq line is being used it's going to get decoded and dispatched by pruss_intc anyway
<zmatt>
and if a single host_irq is used the problem of consistent mappings disappears too