dkm[m] has quit [Ping timeout: 248 seconds]
barafael[m] has quit [Ping timeout: 248 seconds]
sbe2021[m] has quit [Ping timeout: 248 seconds]
TeXitoi[m] has quit [Ping timeout: 248 seconds]
DerFetzer[m] has quit [Ping timeout: 248 seconds]
wallacejohn[m] has quit [Ping timeout: 248 seconds]
javier_varez[m] has quit [Ping timeout: 248 seconds]
theJPster has quit [Ping timeout: 248 seconds]
jhillyerd[m] has quit [Ping timeout: 248 seconds]
dkm[m] has joined ##stm32-rs
wallacejohn[m] has joined ##stm32-rs
theJPster has joined ##stm32-rs
javier_varez[m] has joined ##stm32-rs
jhillyerd[m] has joined ##stm32-rs
barafael[m] has joined ##stm32-rs
sbe2021[m] has joined ##stm32-rs
TeXitoi[m] has joined ##stm32-rs
DerFetzer[m] has joined ##stm32-rs
<peauters[m]> hi all, super basic question (again), when selecting an input option, pull down or pull up, does that use the one board resistors to tie the input down or up?
<dirbaio[m]> it uses resistors inside the chip
<peauters[m]> cool, so no need to add external ones
<peauters[m]> thanks
<wallacejohn[m]> peauters: If you need the specific pull-up/down values, they're in the device datasheets.
<firefrommoonligh> For many things like buttons, the internal ones work and save board space
<firefrommoonligh> But doesn't make much diff. Can make routing slightly cleaner etc
<dirbaio[m]> stm32f4?
<peauters[m]> f411
<peauters[m]> I just moved it to PA1 and its acting as i think it should
<peauters[m]> is there something special about the EXTI15_10 interrupts?
<dirbaio[m]> it spams "rotate" in the logs right from boot? or it only starts when you press the button the first time?
<peauters[m]> from boot
<dirbaio[m]> strange, the code looks OK to me
<dirbaio[m]> afaik the only special thing about lines 10-15 is they share a single interrupt, so it should still work the same
<dirbaio[m]> HAL bug?
<peauters[m]> not sure how I'd track that down
<peauters[m]> so looking at this: https://stm32-rs.github.io/stm32-rs/STM32F411.html#EXTI it should just be setting the bit on the pr register for the corresponding pin, right?
<peauters[m]> and looking at the macro, it "should" be doing that? https://docs.rs/stm32f4xx-hal/0.8.3/src/stm32f4xx_hal/gpio.rs.html#264
<dirbaio[m]> yea, was looking thorugh the hal code, looks OK to me
<dirbaio[m]> the damn macros are a bit hard to follow but yea
<dirbaio[m]> can you print result of check_interrupt both before and after doing clear_interrupt_pending_bit?
<firefrommoonligh> Ie it's repeating the ISR indefinitely? What if you use raw pointers in PAC to clear the bit?
<peauters[m]> i will give that a try later
<peauters[m]> I'm stumbling into very unknown territory =oD
<BobMcWhirter[m]> loose connection maybe/
<BobMcWhirter[m]> * loose connection maybe?
<peauters[m]> maybe, but I used the same setup with PA1 and it worked fine
<peauters[m]> but I should prob check my solder joints on the board I'm using, just in case
<therealprof[m]> peauters: I don't follow. What are you doing with the EXTI, actually using it to trigger or is this just a proxy interrupt?
<therealprof[m]> If you actually want to use EXTI, then the pin number needs to line up with the interrupt name: EXTI15_10 means it'll cover all pins which have the numbers 10 to 15 in ther name.
<therealprof[m]> If it's a proxy interrupt then you must not actually use it.
<dirbaio[m]> he's using PC14, it should work
<therealprof[m]> But I'm reading it works only with PA1?
<dirbaio[m]> aiui
<dirbaio[m]> works with PA1 + EXTI1
<dirbaio[m]> fails with PC14 + EXTI15_10
<therealprof[m]> I see.
<therealprof[m]> Maybe the button is connected to Vcc instead of ground?
<therealprof[m]> If so you'd need the inverse configuration, e.g. use pull_down and a rising edge.
<dirbaio[m]> what would cause the irq to fire continuously though?
<therealprof[m]> Hm, for an edge triggered interrupt that's indeed weird.
<peauters[m]> hey, sorry just getting back to this
<peauters[m]> @dirbaio is correct
<peauters[m]> i'll prob have another look at the interrupts later
<peauters[m]> and will let you know what I find
<henrik_alser[m]> Strange, i use that very pin and exti15_10 all the time with the f4 hal and haven’t had a problem....
<henrik_alser[m]> Here’s a working example with pc13 if you wanna compare: https://github.com/kalkyl/f411-rtic/blob/main/src/bin/exti.rs
<henrik_alser[m]> Is it your own board or something off the shelf?
<henrik_alser[m]> If it’s a black pill i think maybe LSE is connected to pc14 which would explain the behaviour
<henrik_alser[m]> * If it’s a black pill (or some other board with LSE) i think maybe LSE is connected to pc14 which would explain the behaviour
<henrik_alser[m]> If i’m not mistaken
<henrik_alser[m]> * If it’s a black pill, nucleo or some other board with LSE, i think maybe LSE is connected to pc14 which would explain the behaviour
<peauters[m]> it is a black pill
<peauters[m]> LSE?
<henrik_alser[m]> The low frequency crystal
<peauters[m]> ahhhh i see
<peauters[m]> cool
<peauters[m]> so can't use those pins =o)
<peauters[m]> thanks, that helps a lot
<peauters[m]> I also got a logic analyser to debug my i2c ssd1306 issue
<peauters[m]> seems that when it fails, sclk goes low and doesn't come back up again
<peauters[m]> it sends a 3 bits for an address read, and then sclk goes low
<dirbaio[m]> wow so the blackpill exposes the LSE pin as a board pin? that's a nice footgun
<peauters[m]> can see it now I know what I'm looking for
<henrik_alser[m]> Can you post a picture? Are you sure it’s not SDA? If it was clock stretching it should happen after the full address....
<peauters[m]> I'm just adding some pull up resistors (removed them to start with) and see if that makes a different
<agg> dirbaio[m]: you just have to develop the stm32 user's natural aversion to using pc13-15 for anything :p
<dirbaio[m]> hhahahaha 😂
<dirbaio[m]> welp very good to know, I could totally see myself fucking that up otherwise...
<agg> I mean, the pin is a GPIO, if you didn't have an LSE fitted or removed it from the blackpill you might want to use it otherwise
<agg> but it's powered by a different power switch in many/most stm32s which means it can do at most 2mA or something like that
<agg> so not a great choice for LEDs
<peauters[m]> that is what happens when I plug in the usb
<peauters[m]> thats what it looks like when it is successful
<peauters[m]> but its weird one is doing a read, the other a right
<henrik_alser[m]> * Can you post a picture? Are you sure it’s not SDA?
<agg> can you increase the sample rate beyond 1MHz? how fast is your i2c meant to be running?
<peauters[m]> 400Khz
<agg> if I'm reading the screenshot right, the i2c clock seems to be toggling at about half your sample rate - maybe 400kHz?
<agg> you'll want to sample way way faster, 10MHz or more if you can
<peauters[m]> let me see if I can bump it up
<agg> assuming it's one of the cheap usb logic analysers you can probably go up to 24Mbps if your usb bus is good, but 16 would be a big improvement anyway
<peauters[m]> ok, 16mhz it is
<agg> just ensures you have multiple samples per bit, you can see in your screenshots how the clock is very irregular because of it
<peauters[m]> thanks
<peauters[m]> ok, resampled and the start is the same
<peauters[m]> it writes to 3c, 7 bits, starts another write with 1 bit and then the clock goes low and doesn't come back up
<peauters[m]> until I hit the reset button
<peauters[m]> then when I reset i can see something different now
<peauters[m]> bad start
<peauters[m]> good start
<TimSmall> Bit of a long shot, but have you got a scope? If-so, are the supply voltages OK, and what does the i2c waveform look like?
<peauters[m]> i dont I'm afraid, ones on the way
<peauters[m]> I grabbed an hantek mso, but got too impatient and picked up a cheap £10 logic analyser to hold me over
<peauters[m]> I've gotta be a parent for a bit, but will check back in if anyone has any thoughts =o)
<adamgreig-m> i only have spi oleds so can't really try it out but maybe it would be worth checking with a lower i2c clock speed in case it's a signal integrity problem? probably see if anyone who actually has one of these has ideas though
<TimSmall> peauters: What pull-up resistor values are you using?
<henrik_alser[m]> Also double check for intermittent connections
<henrik_alser[m]> Does it only happen during start-up or anytime?
<therealprof[m]> <adamgreig-m "i only have spi oleds so can't r"> I have tested this exact same combination a few days ago. Works fine.
<peauters[m]> <TimSmall "peauters: What pull-up resistor "> 2k I believe
<peauters[m]> <henrik_alser[m] "Also double check for intermitte"> It might be this if plugging in the usb moves something. I’ll try plugging in the other end so I touch the board as little as possible.
<henrik_alser[m]> 👍
<peauters[m]> <therealprof[m] "I have tested this exact same co"> 100% it user error =o)
<peauters[m]> Thanks all for your help. Really appreciate it.
<TimSmall> You could also try dropping to 1k pull-ups.
<therealprof[m]> Or no external pull-ups, the internal ones are just fine...
<firefrommoonligh> My understanding is hardware PUs are preferred for I2C lines, to prevent undefined behavior when the MCU is off or in low-power modes
<adamgreig-m> also the built in ones tend to be quite weak so might not recharge the bus capacitance fast enough at high clock rates
<henrik_alser[m]> Yeah on the f411 they are around 40k i believe, so very limited
<henrik_alser[m]> Some of those oled modules have onboard pullups however
<henrik_alser[m]> (I prefer to put them on the controller device side of the link though)
<therealprof[m]> Yeah, but we're not talking about best design practises for a custom board but MVP here. The internal PUs are perfectly fine for this purpose, no need to go overboard, especially when something is not working...
<henrik_alser[m]> <therealprof[m] "Yeah, but we're not talking abou"> Sorry, but no-one was talking of going overboard here? Just that the pullups is more often than not the problem, so would be good to be able to rule that one out to begin with, since I’ve never had reliable results using the internal pull-ups at > 100k myself. I’d even estimate the input capacitance of the SSD1306 alone would be too high for this to compute at
<henrik_alser[m]> 400k, not counting the breadboard, but theory only gets you so far and i'm happy to be proven wrong IRL :)
<therealprof[m]> I've never had a single problem with the built-in pull-ups on a STM32 and I've done a ton of tests with different chips. When looking for problems I'd always go for the simplest possible setup and that is using the internal pull-ups before starting to look at other stuff. If necessary you could also reduce the speed but unless you're running crazy long lines, capacitance should not be a problem at all. Using
<therealprof[m]> external pull-ups could cause a ton of other problems which are annoying to debug, especially if you don't have the tools and/or knowhow to do measurements. It seems quite possible that in this particular case the hardware was fried by trying to use external pull-ups.
morgan[m]3 has joined ##stm32-rs
<henrik_alser[m]> Great, then nevermind my ramblings :) Good night!
<jhillyerd[m]> Internal pullups have worked fine for me on and off breadboard for stmf103 + ssd1306, but only a sample size of two boards and two displays.