ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
rainingmessages1 has quit [Quit: bye]
rainingmessages1 has joined #rust-embedded
rainbyte has quit [Ping timeout: 270 seconds]
glitchy has quit [Ping timeout: 245 seconds]
glitchy has joined #rust-embedded
sroemer has joined #rust-embedded
rainingmessages1 has quit [Ping timeout: 248 seconds]
rainingmessages1 has joined #rust-embedded
sskartheekadivi has quit [Ping timeout: 248 seconds]
sskartheekadivi has joined #rust-embedded
rainingmessages1 has quit [Ping timeout: 272 seconds]
rainingmessages1 has joined #rust-embedded
jjido has joined #rust-embedded
ouilemur has quit [Quit: WeeChat 4.9.3]
ouilemur has joined #rust-embedded
RobinMueller[m] has quit [Quit: Idle timeout reached: 172800s]
rainbyte has joined #rust-embedded
<thejpster[m]> So, as an experiment, i started look at what a cortex-m crate would look like it if was modelled on the aarch32-cpu crate.... (full message at <https://catircservices.org/_irc/v1/media/download/AeDgBz3ymGVuaodY1BFsYhljiYnaBI8ce7QnTfZ0Budh8cVrZL-QiixN35UNXjFHCVyQsc1KW-UETFsrfIyT7bi_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9jUlZaTXNBTWhiRm9PZEtiV1pyc093amc>)
<thejpster[m]> it's not a stack overflow because the same code compiled for the other machines only use about 1K of stack, so there's loads free.
<JamesMunns[m]> Are you setting up with msp/psp or something in your unit code?
<JamesMunns[m]> s/unit/init/
<JamesMunns[m]> Interrupts are always taken with msp, but that's also what gets loaded from the vector table
<JamesMunns[m]> Or is it possible you are underflowing your stack somehow? Like if you start at a relatively low initial stack value?
<thejpster[m]> UGH
<thejpster[m]> it's a dual-core machine and QEMU leaves the second core spinning in a WFE.
<thejpster[m]> muggins here did a SEV in the interrupt routine, accidentally waking up the second core
<thejpster[m]> I worked this out by commenting out the SEV :/
<thejpster[m]> you know, it might be a qemu bug
<thejpster[m]> a SEV somewhere else isn't a problem. But in a SysTick exception handler it's a problem.
<thejpster[m]> and despite having two cores (and insisting that -smp 2 is the only valid option), GDB is only showing me one thread.
glitchy has quit [Ping timeout: 257 seconds]
glitchy has joined #rust-embedded
jjido has quit [Quit: Client closed]
jjido has joined #rust-embedded
crabbedhaloablut has quit [Quit: bye]
crabbedhaloablut has joined #rust-embedded
rainingmessages1 has quit [Ping timeout: 271 seconds]
jjido has quit [Ping timeout: 245 seconds]
cr1901_ is now known as cr1901