20:24 <re_irc> < (@CyReVolt:matrix.org)> Hello hackers. I am... desperate and confused. 😅 Trying to get interrupts to work on a WCH CH32V307. Here's what I have:

20:24 <re_irc> https://github.com/orangecms/ch32v307-rust/commit/e06321779a2896ee01560db9546b27e4e7089435

20:24 <re_irc> Note: The pac crate is somehow WIP. I _do_ have the "DefaultHandler" invoked here, which is fine for a start. However, I cannot figure out how to clear the interrupt pending, or whether I need to clear multiple ones. The whole code there has become a true mess for just trying to set up the interrupts to work _at all_. Any ideas? A simple "riscv::something::clear_interrupt()" is not really available... 😭

20:24 <re_irc> Here's a related issue I just filed: https://github.com/ch32-rs/ch32-rs/issues/3

20:26 <re_irc> < (@jamesmunns:beeper.com)> Does the CH23V use the PLIC?

20:30 <re_irc> < (@CyReVolt:matrix.org)> I have... no idea. They have something called PFIC...

20:30 <re_irc> < (@CyReVolt:matrix.org)> To be honest, this thing seems to be so complex, I haven't really grasped it yet.

20:31 <re_irc> < (@jamesmunns:beeper.com)> Ah, no, it looks like PFIC is a different kind of interrupt controller than the PLIC

20:31 <re_irc> < (@CyReVolt:matrix.org)> I... guess so?

20:31 <re_irc> < (@jamesmunns:beeper.com)> (interrupt controllers aren't super standard in RISC-V)

20:31 <re_irc> < (@CyReVolt:matrix.org)> The also have something they call "VTF (Vector Table Free) interrupt response mechanism"

20:32 <re_irc> < (@jamesmunns:beeper.com)> So, speaking vaguely, and guessing a bit because the CH32V are loosely based on the STM32F family:

20:33 <re_irc> < (@CyReVolt:matrix.org)> In addition to the whole complexity, the also put both all of their ARM and RISC-V MCUs in one sheet. They are very similar, but as I understand it, the RISC-V ones have the PFIC and ARM have the NVIC. I have a RISC-V. And setting up this PFIC thing sorta worked.

20:33 <re_irc> < (@jamesmunns:beeper.com)> When an interrupt occurs, you usually need to mark the the thing that caused the interrupt (such as a flag in the peripheral itself) before the end of the interrupt

20:33 <re_irc> < (@jamesmunns:beeper.com)> so that might be something like "uart.clear_bytes_received_flag()" or something

20:34 <re_irc> < (@CyReVolt:matrix.org)> So I would need to walk through all the peripheral interrupt flags in the interrupt handler, according to the IRQ, which is... yay... 😱

20:34 <re_irc> < (@jamesmunns:beeper.com)> this is in ADDITION to sometimes needing to clear the flag in the interrupt manager itself (the NVIC does this automatically, I think in the PLIC you need to do the "claim/complete" dance)

20:34 <re_irc> < (@CyReVolt:matrix.org)> yea I read about the PLIC the other day, though that seems non-existent here

20:34 <re_irc> < (@jamesmunns:beeper.com)> yeah, sadly not relevant, or I'd send you the code I use for the D1 :D

20:37 <re_irc> < (@CyReVolt:matrix.org)> In summary, it looks like

20:37 <re_irc> - I need to do a manual pending bit clearance

20:37 <re_irc> - only the "DefaultHandler" is ever called (even though there should be individual handlers?)

20:37 <re_irc> - to set the crap up, I need to

20:37 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/s4SP2iZCdIdFOYKdAbqpSENl6lebBYiL (7 lines)

20:39 <re_irc> < (@CyReVolt:matrix.org)> now with the whole peripherals take/pass model, accessing the peripherals in the interrupt handlers feels very weird; how would you do that? I would just "naturally" resort to either just "write_volatile" or define some global static mut stuff... which feels plain wrong -_-

20:40 <re_irc> < (@jamesmunns:beeper.com)> honestly, usually "let periph = unsafe { &*PERIPH::PTR };"

20:40 <re_irc> < (@CyReVolt:matrix.org)> okay, I'm unsure where "PERIPH::PTR" would come from

20:42 <re_irc> < (@jamesmunns:beeper.com)> I _think_ some interrupt controllers on RISC-V have two main modes:

20:42 <re_irc> - "only one callback" - you have a single interrupt function (for MachineExternal), which needs to determine the actual source, using interrupt-controller specific information

20:42 <re_irc> - Some interrupt controllers have a "vector table mode", which is more like the NVIC, where you make a table of function pointers, one for each interrupt handler (I have never done this)

20:42 <re_irc> < (@jamesmunns:beeper.com)> : From the PAC

20:45 <re_irc> < (@CyReVolt:matrix.org)> I mean, I see no such thing with that _exact_ name, so I am unsure what it translates to

20:45 <re_irc> < (@jamesmunns:beeper.com)> sorry, I meant for the specific peripheral you want

20:45 <re_irc> < (@jamesmunns:beeper.com)> so like the "UART0" or whatever from the PAC will have an associated constant, "PTR"

20:45 <re_irc> < (@jamesmunns:beeper.com)> (which is the address of that peripheral)

20:46 <re_irc> < (@CyReVolt:matrix.org)> 34 | let to_the_rescue = ch32v30x::Peripherals::USART1::PTR;

20:46 <re_irc> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use fully-qualified syntax: `<Peripherals as Trait>::USART1`

20:47 <re_irc> < (@CyReVolt:matrix.org)> I have no idea what this is, but it looks funny - Rust's messages always get me lost 🕳️

20:48 <re_irc> < (@CyReVolt:matrix.org)> 34 | let to_the_rescue = unsafe { &*ch32v30x::Peripherals::<Peripherals as Trait>::USART1::PTR };

20:48 <re_irc> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use fully-qualified syntax: `<Peripherals as Trait>::USART1`

20:48 <re_irc> < (@CyReVolt:matrix.org)> is getting recursive 😂

20:49 <re_irc> < (@CyReVolt:matrix.org)> it says "Peripherals" "expected 0 generic arguments"

20:50 <re_irc> < (@jamesmunns:beeper.com)> Gimme a sec, I'm looking. I think they do something else?

20:51 <re_irc> < (@jamesmunns:beeper.com)> Have you looked at https://docs.rs/riscv-rt/latest/riscv_rt/ ?

20:51 <re_irc> < (@jamesmunns:beeper.com)> that gave me a lot of the information I needed when setting up the D1

20:51 <re_irc> < (@jamesmunns:beeper.com)> It doesn't show an example of taking a parameter in the DefaultHandler?

20:52 <re_irc> < (@CyReVolt:matrix.org)> yes, it doesn't, and yes, that is what I started with, and the argument giving the IRQ number _does_ work - I am printing it, and the value is sensible, same as what I can read from the CSR

20:56 <re_irc> < (@jamesmunns:beeper.com)> So, it looks like it's SUPER not supposed to work like that?

20:56 <re_irc> < (@CyReVolt:matrix.org)> tbh I'm now wondering where I got that part with the IRQ number from 😂

20:56 <re_irc> < (@jamesmunns:beeper.com)> The ABI of that function is definitely "void fn(void)" btw

20:56 <re_irc> < (@jamesmunns:beeper.com)> You're getting... something? in that argument, which is probably popping something? off the stack?

20:57 <re_irc> < (@jamesmunns:beeper.com)> but that's SUPER gunna corrupt your stack, unless I'm looking at that incorrectly

20:57 <re_irc> < (@jamesmunns:beeper.com)> Like "DefaultHandler" is a weak symbol binding to https://github.com/rust-embedded/riscv-rt/blob/master/src/lib.rs#L497-L503

20:58 <re_irc> < (@CyReVolt:matrix.org)> ah I took it from here:

20:58 <re_irc> https://docs.rust-embedded.org/book/start/exceptions.html#the-default-exception-handler

20:58 <re_irc> < (@CyReVolt:matrix.org)> > It's possible to override this DefaultHandler using the exception attribute:

20:58 <re_irc> #[exception]

20:58 <re_irc> fn DefaultHandler(irqn: i16) {

20:58 <re_irc> }

20:58 <re_irc> // custom default handler

20:58 <re_irc> < (@jamesmunns:beeper.com)> You aren't using the "exception" attribute :D

20:58 <re_irc> < (@jamesmunns:beeper.com)> you're just telling the linker "this "fn(i16)" function is definitely a "fn()" function" :D

20:58 <re_irc> < (@CyReVolt:matrix.org)> I can assure you that I tried it at least and couldn't find it

20:59 <re_irc> < (@jamesmunns:beeper.com)> It probably doesn't exist in riscv-rt

20:59 <re_irc> < (@CyReVolt:matrix.org)> and now the argument there remained :D

20:59 <re_irc> < (@jamesmunns:beeper.com)> lemme type something longer up, then point you to my _sort of_ related PLIC code

20:59 <re_irc> < (@CyReVolt:matrix.org)> I can also assure you that I tried like 100 different things because I got so lost 😂

21:00 <re_irc> < (@jamesmunns:beeper.com)> Gotta be careful with linker commands, it will happily say "job done!" while blowing off your foot

21:00 <re_irc> < (@CyReVolt:matrix.org)> yea, I sorta hate that linker stuff, I never truly got behind it...

21:01 <re_irc> < (@CyReVolt:matrix.org)> I was happy enough that I could just define this "memory.x" instead of writing a "link.ld" by hand.....

21:01 <re_irc> < (@CyReVolt:matrix.org)> ... which is how I started and that didn't work at all, of course

21:02 <re_irc> < (@CyReVolt:matrix.org)> I'm confused though that getting the IRQ number from the function argument works

21:02 <re_irc> < (@jamesmunns:beeper.com)> uh

21:03 <re_irc> < (@jamesmunns:beeper.com)> you are probably taking whatever HAPPENS to be in register 0 (or however the riscv abi works), masking off the lower 16 bits, and running with it

21:03 <re_irc> < (@jamesmunns:beeper.com)> I'd take "works" as more of a "happens to work" sorta thing

21:03 <re_irc> < (@CyReVolt:matrix.org)> yea I guess "a0" just happened to have that value :)

21:04 <re_irc> < (@jamesmunns:beeper.com)> My mental image of interrupt handling (single entry) on RISC-V (again, this is PLIC, not PFIC, so take it with a grain of salt):

21:04 <re_irc> 1. Set up peripherals you want to generate the interrupt (e.g. "set up UART0")

21:04 <re_irc> 2. Enable "event generation" for that peripheral (e.g. "enable interrupt on byte received")

21:04 <re_irc> 3. Set the priority for the interrupt in your interrupt controller (e.g. "set UART0 interrupt to prio 1 in PLIC")

21:04 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/jVFA54kxtiBbgU67teCiPrdl9KB63OiB (11 lines)

21:04 <re_irc> < (@CyReVolt:matrix.org)> I'll switch to using "mcause.code()"

21:04 <re_irc> < (@jamesmunns:beeper.com)> https://github.com/tosc-rs/mnemos/blob/james/d1-support/source/platforms/allwinner-d1/src/main.rs and https://github.com/tosc-rs/d1-playground/blob/main/src/plic.rs#L61-L76 might be useful

21:04 <re_irc> < (@CyReVolt:matrix.org)> re the return from IRQ: do I _just_ "return", or do I need to somehow "mret"?

21:05 <re_irc> < (@jamesmunns:beeper.com)> even if you need to tweak it to be PFIC

21:06 <re_irc> < (@jamesmunns:beeper.com)> Again, sample size of one, I just return: https://github.com/tosc-rs/mnemos/blob/james/d1-support/source/platforms/allwinner-d1/src/main.rs#L292-L376

21:06 <re_irc> < (@CyReVolt:matrix.org)> and do I get it right that peripheral interrupts are considered to be event interrupt, and _not_ software or machine external? (those are the categories in the manual)

21:06 <re_irc> < (@jamesmunns:beeper.com)> They are probably (???) wired up to MachineExternal

21:07 <re_irc> < (@jamesmunns:beeper.com)> at least that's how the D1 works - I have no idea in the CH32V family

21:07 <re_irc> < (@jamesmunns:beeper.com)> IIRC event interrupts are for inter-core comms?

21:08 <re_irc> < (@CyReVolt:matrix.org)> well I have no idea either; just out of despair put "0xffffffff" in all of the interrupt enable registers 😂

21:09 <re_irc> < (@CyReVolt:matrix.org)> I will try to walk again from this point, thank you a lot for picking me up from the floor!

21:09 <re_irc> < (@CyReVolt:matrix.org)> I owe you. Gotta come to Berlin again at some point. ^^

21:11 <re_irc> < (@jamesmunns:beeper.com)> Good luck!

21:13 <re_irc> < (@CyReVolt:matrix.org)> Thank you, I'll need it! 🙏

21:18 <re_irc> < (@jamesmunns:beeper.com)> misc note, re: https://github.com/orangecms/ch32v307-rust/blob/main/src/main.rs#L19-L38

21:19 <re_irc> < (@jamesmunns:beeper.com)> I _think_ some serial emulators on linux won't always print lines without a newline

21:19 <re_irc> < (@jamesmunns:beeper.com)> or I've had "cat /dev/ttyUSB0" or "screen" or something do that to me

21:20 <re_irc> < (@jamesmunns:beeper.com)> don't quote me on that, but something to try if you aren't getting the output you expect