Search Results
7/9/2025, 1:18:36 AM
>>2929798
>Is it something where an oscilloscope would have helped?
I already have a DSO. I'm not a complete novice here, though perhaps only just barely this side of it. That's part of the problem. I feel like I shouldn't be fucking up in ways this stupid at this point, at least not for this long.
>>2929887
>Are you using debugging via GDB or otherwise through your IDE?
GDB via the STM32 extension for VScode. Which actually was what ended up being part of the problem: It didn't occur to me that the peripheral registers have no way of knowing whether they're being read/written by the MCU itself or by the debug...meaning that flags that are set/reset on register read are flipped "at random" when the debugger pauses the MCU and checks register values.
IDK, I guess I'm mostly just looking for confirmation that either failing this hard is semi-normal or that I am, in fact, retarded.
Just for reference: Picrel for what ended up being the root of the problem. I couldn't figure out why the timeout for the first byte always worked fine, but the second wouldn't time out. USART_WaitForAck() would always return true (transfer received in time) even with impossibly short wait times...unless the receiving MCU was held under reset and not responding at all, at which point it would time out as expected. I eventually set the receiving MCU to just never send the second ACK and measured how long the timeout actually took, which was suspiciously close to 65535µs. Turns out, when I wrote the TimeoutSetup_uSec() routine at the core of the delay, I had implicitly assumed that the counter would be stopped at the start of that function. But, if the delay is long enough that it can be called again BEFORE the counter hits the set AutoReload (maximum/top) value, setting another, lower AutoReload value will cause the counter to dodge the original and the new timeout value won't be hit until the counter overflows.
>Is it something where an oscilloscope would have helped?
I already have a DSO. I'm not a complete novice here, though perhaps only just barely this side of it. That's part of the problem. I feel like I shouldn't be fucking up in ways this stupid at this point, at least not for this long.
>>2929887
>Are you using debugging via GDB or otherwise through your IDE?
GDB via the STM32 extension for VScode. Which actually was what ended up being part of the problem: It didn't occur to me that the peripheral registers have no way of knowing whether they're being read/written by the MCU itself or by the debug...meaning that flags that are set/reset on register read are flipped "at random" when the debugger pauses the MCU and checks register values.
IDK, I guess I'm mostly just looking for confirmation that either failing this hard is semi-normal or that I am, in fact, retarded.
Just for reference: Picrel for what ended up being the root of the problem. I couldn't figure out why the timeout for the first byte always worked fine, but the second wouldn't time out. USART_WaitForAck() would always return true (transfer received in time) even with impossibly short wait times...unless the receiving MCU was held under reset and not responding at all, at which point it would time out as expected. I eventually set the receiving MCU to just never send the second ACK and measured how long the timeout actually took, which was suspiciously close to 65535µs. Turns out, when I wrote the TimeoutSetup_uSec() routine at the core of the delay, I had implicitly assumed that the counter would be stopped at the start of that function. But, if the delay is long enough that it can be called again BEFORE the counter hits the set AutoReload (maximum/top) value, setting another, lower AutoReload value will cause the counter to dodge the original and the new timeout value won't be hit until the counter overflows.
Page 1