03:01 <takkaryx[m]> ooo, now I have slides to watch when I listen, this is both a blessing and a curse, I listened to it on a bike ride before, but now I can understand more about what is being talked about!

07:33 <tr09[m]> Hi, I’m bit-banging a buzzer to make some beeps and noticed pitch goes up when SWD has made a connection until power is cycled. It’s based on rtic v1 tasks and runs on nrf52. Is this overclocking supposed to happen and what other clock rates might be changing? (UART seems to become less reliable)

07:47 <JamesMunns[m]> it might not be actually raising in pitch, but the jitter might be causing harmonics. It would be interesting to look at with a scope or logic analyzer. The nrf52 definitely doesn't have any concept of overclocking, as far as I know

08:24 <tr09[m]> I’ll try to get some scope readings

08:28 <JamesMunns[m]> When you say bit-banging, are you using any peripherals at all, or just busy loops?

08:32 <JamesMunns[m]> if you can share the code, that would also help a lot. It would also be good to know:... (full message at <https://catircservices.org/_irc/v1/media/download/AQTqp7RRZzUwwHPSua8jJOlNe4za9Cpi2E5K_4gzeRVp6ZfkJBIz7UaQuzSxolt4oFtGptdF5_zSa3xn-Kwb6N1CeSLay4KwAGNhdGlyY3NlcnZpY2VzLm9yZy94Q1BoQVNtRkRra3ZyVHBBbFJUdVBDdlI>)

08:38 <JamesMunns[m]> Attaching the debugger does change some things, but not necessarily CPU speed. Off the top of my head, it does enable hfclk, and might inhibit sleep modes that could mean you do some things "faster"? Hard to tell without looking at your code tho.

08:38 <JamesMunns[m]> The things affected by the debugger aren't disabled until a power cycle, so it does somewhat match your symptoms

08:49 <JamesMunns[m]> some stuff says there might be 10us delay from a wake event (if you are sleeping waiting for a timer, which could happen if rtic is otherwise idle), for a 440hz tone (50% low, 50% high, toggle every 1136us), that could mean you are actually toggling every 1146us, which would be 0.8% slower than you expect, which would mean you are actually playing a 436.3hz tone.

08:49 <JamesMunns[m]> IF you aren't compensating for this wakeup delay (using a continuous timer), AND you do have wakeup delay without the debugger, AND the debugger inhibits sleep meaning you stop having the 10us delay, then actually I could see this being the case, if the change is only subtle. 436 -> 440hz is a noticable shift (you can hear it here, select square wave: https://onlinetonegenerator.com/)

08:52 <JamesMunns[m]> if it's a way bigger shift (2x or 4x frequency or something), then it's probably not that. The effect would be more noticable on higher frequencies, piezos usually recommend something like 4kHz, which would be 125us per toggle, so you'd be at 3.7kHz with the extra delay vs 4.0kHz without it

08:54 <JamesMunns[m]> 440 -> 436 is just a little flat, but 4.0k -> 3.7k is a little more than a semitone flat (B natural 7ish to B flat 7ish)

09:03 <tr09[m]> The code is roughly... (full message at <https://catircservices.org/_irc/v1/media/download/AbRx1usKuvn8J1hs15MIEN2iXZQcoa7dGcnWdR4HkfbqWHDp2w-kQ7vPDQXPTP5bDG-SLY9byiTBsjC0sBXxAe5CeSLckNxAAGNhdGlyY3NlcnZpY2VzLm9yZy96Q1ZVbURuRkRsUVBqeUJpcUVRc3BaR1A>)

09:05 <JamesMunns[m]> yeah, if your scope shows a difference of 10 ish us before and after, then I would bet it is that.

09:06 <tr09[m]> First one is after debugger establishes connection

09:08 <JamesMunns[m]> yep, 21.93us difference in period

09:08 <JamesMunns[m]> which is 2 x 10us, give or take

09:10 <JamesMunns[m]> the three fixes to this, imo:... (full message at <https://catircservices.org/_irc/v1/media/download/AbjZ-ym2rFyiI5vjzi1ZIBlUlSTbKoPJujcFTby1JakyKi-iV7TPRspWChdRAqO89FTvZdnqkq0YyeIzVKd1LDtCeSLc_j6AAGNhdGlyY3NlcnZpY2VzLm9yZy9KVEpaYmdFV09adUlUdHRscUp1dHlwQ0I>)

09:15 <JamesMunns[m]> oh, fourth fix: replace the idle task with loop { cortex_m::asm::nop() }, which will eliminate sleeping when idle, which means you never pay the wakeup cost

09:15 <JamesMunns[m]> but imo, using PWM is the best option, and using a hardware timer is the second best option.

09:15 <tr09[m]> The tone is just the symptom and i wanted to figure out the cause because it correlated with UART problems. Ideally yes, I should revisit PWM because I caused some panics when swapping buffers.

09:16 <tr09[m]> * swapping buffers when I first tried it.

09:17 <JamesMunns[m]> uart problem could be switching on the hfclk? that might force the 16mhz peripheral clock to be on instead of the low power 1mhz peripheral clock, which could give a slight change in error margin on the uart?

09:21 <tr09[m]> Clock setup is .enable_ext_hfosc().set_lfclk_src_synth().start_lfclk()

09:21 <tr09[m]> Wait a minute… lfclk?

09:21 <JamesMunns[m]> lfclk is the 32khz clock, usually used for low power sleeps

09:22 <JamesMunns[m]> nrf52 has two clock "kinds", hfclk (internal or external oscillator, used to generate 1/16/64mhz clock domains), and lfclk, which runs the 32khz clock domain

09:23 <JamesMunns[m]> the high frequency clocks on the nrf52 are dynamic: they run at the slowest speed they think they can get away with

09:23 <JamesMunns[m]> so if you are setting 115200, it might only enable the 1mhz lower power peripheral clock

09:23 <JamesMunns[m]> but if the debugger forces the higher power 16mhz peripheral domain on instead, then the uart will use 16mhz as the base frequency instead of 1mhz

09:24 <JamesMunns[m]> it should compensate for this correctly, but there are rounding errors in baudrate calculation (neither frequency divides by 115200 evenly), 16mhz might have a worse rounding error?

09:24 <JamesMunns[m]> idk, this is all a guess

09:25 <JamesMunns[m]> Also since you are using hfclk internal instead of hfclk external, you will already have a higher error % for PLL generated 1/16/64 clock domain numbers

09:26 <JamesMunns[m]> could be stacking tolerances? Your scope will show you the real picture though.

09:26 <tr09[m]> Yeah it seems I have some measuring to attend to.

09:26 <tr09[m]> Thanks for your help.

09:27 <JamesMunns[m]> JamesMunns[m]: ah sorry, no, you are using internal lfclk, but external hfclk. Ignore this part :)

09:28 <JamesMunns[m]> (there's still some room for error, but it's generally pretty small if you have a good external crystal circuit)

09:28 <JamesMunns[m]> baudrate error is still a potential thing tho: https://devzone.nordicsemi.com/f/nordic-q-a/79977/uart-baudrate-is-inaccurate

09:32 <tr09[m]> JamesMunns[m]: Let’s just say this has been dealt with (SPI <-> UART chip)

09:51 <tr09[m]> .im_feeling_lucky()

11:21 <chrysn[m]> Many chips have some unique IDs, and when flashing (or provisioning through flashing), it'd be handy to access them.

11:23 <chrysn[m]> Would it be fitting for probe-rs to add to the chip descriptions the memory areas of Device ID (or comparable) registers, so that a user could see in probe-rs info which precise instance is connected, and could run probe-rs attach --protocol swd --chip nrf52840_xxAA --chip-id 001122334455667788 to be sure to get the right chip by identity (without the need to create a mapping between the physical device and the precise debugger

11:23 <chrysn[m]> / USB port it is attached to)?

11:24 <JamesMunns[m]> IIRC device ID is not handled consistently, I think there's talk of building a database to get the chip ID, but that requires custom code for every kind of chip?

11:25 <JamesMunns[m]> like, I don't *think* there's a cortex-m standard for "chip id goes at this addr"

11:25 <chrysn[m]> Device ID is not handled consistently, but should be relatively straightforward to add for individual chips.

11:25 <JamesMunns[m]> iirc even on stm32, there were numerous different ways this was exposed

11:26 <JamesMunns[m]> not saying it can't be done! Just that there would be a lot of work for writing a db of all the places you have to look based on the selected --chip

11:26 <chrysn[m]> For example, for all the nRF5x chips that would be reading two consecutive registers (FICR.DEVICEID[0..=1])

11:26 <JamesMunns[m]> this has been discussed in #probe-rs:matrix.org before, I believe

11:26 <marmrt[m]> The unique IDs of ATSAME70 is in a separate flashbank, so you would need a RAM function that switches the flash bank to the ID one, read it, and then switch back

11:27 <JamesMunns[m]> the rp2040 doesn't have a chip id, though most tooling will use the ID of the external QSPI flash

11:28 <JamesMunns[m]> but that also requires custom blocking flash commands to obtain

11:29 <chrysn[m]> I didn't find any discussion of it in probe-rs issues, but happy to ask there.

11:29 <chrysn[m]> I did expect that it'll be more difficult on other chips; RAM functions and reading external flash does however sound tedious.

11:29 <chrysn[m]> (It just so happens that my favorite chips over time, EFM32 series and nRF52, all have it similarly easy…)

11:29 <JamesMunns[m]> I do agree it would be extremely cool to have that ability :)

11:30 <JamesMunns[m]> and it could be worth doing it progressively: add a db of "how to do it", and fill out all the easy ones, and tackle the hard ones later?

11:30 <JamesMunns[m]> and if you ask for a chip that the db doesn't know, it can just say "that chip isn't supported yet, see tracking issue for how to add support"

15:32 <dirbaio[m]> you can't know the chip id without attaching first

15:32 <dirbaio[m]> while you can know the probe vid:pid:serial

15:33 <dirbaio[m]> so to make probe-rs attach --chip-id 001122334455667788 work it'd have to try attaching to every single probe it sees

15:34 <dirbaio[m]> and attaching is a somewhat disruptive operation

15:37 <JamesMunns[m]> (this conversation has moved over to #probe-rs:matrix.org, might be good to follow there so we don't end up talking in two places)

19:42 <i509vcb[m]> I've heard of embeddedworld-na, is it worth going just for the expo part? Considering currently

19:43 <i509vcb[m]> I live close enough in Texas where it isn't an issue to go (2 hour drive)

22:20 <explodingwaffle1> https://blog.rust-lang.org/inside-rust/2024/09/26/rtn-call-for-testing.html 👀