05:04 <re_irc> <@tmgross:matrix.org> I've seen "release", "free", and "into_parts" for method names to give owned pins/timers/etc back. Is there any official preference?

05:16 <re_irc> <@tmgross:matrix.org> +(for HALs)

05:28 <re_irc> <@9names:matrix.org> Hi folks,

05:28 <re_irc> luojia65 has proposed moving the existing PACs for all bouffalo lab chips (bl602/b616/bl702/bl808) into a single repo at https://github.com/bouffalolab/bl-pac

05:28 <re_irc> We're currently soliciting community feedback about this process at https://github.com/sipeed/bl602-pac/issues/20

05:28 <re_irc> If you have any questions or concerns, your feedback would be appreciated.

05:28 <re_irc> Thanks!

10:08 <re_irc> <@andelf:matrix.org> : Hope the official will uncover more hidden registers. I had a glampse at the bl616 svd/pac/sdk, many important register definitions are hidden, the sdk uses many bootrom functions.

13:32 <re_irc> <@zagitta:matrix.org> Yeah not sure shuffling around the PACs matter much when they're 50% //todo comments, at least for bl808

15:01 <re_irc> <@xgroleau:matrix.org> Hey folks, I'm getting an error when running a basic blinky (or any example/project really) on the nrf52840. It runs fine for a couple seconds and logging with defmt works too, but the debugger disconnects. The code does continue to run though. I get the same error on different code, usb cable, debugger and boards and am using cortex-m-rt 0.7.3. I'm a bit confused on what is happening here since it was working fine a...

15:01 <re_irc> ... couple weeks ago.

15:01 <re_irc> RTT error: Error communicating with probe: A ARM specific error occured.

15:01 <re_irc> ────────────────────────────────────────────────────────────────────────────────

15:01 <re_irc> The weird thing is that I get two different errors from time to time, here is one

15:01 <re_irc> Error: A ARM specific error occured.

15:01 <re_irc> Caused by:

15:01 <re_irc> 0: Error using access port

15:01 <re_irc> **1: Failed to write register CSW at address 0x00000000**

15:01 <re_irc> 2: The debug probe encountered an error.

15:01 <re_irc> 3: An error specific to a probe type occurred

15:01 <re_irc> 4: USB error while writing data to device: No such device (it may have been disconnected)

15:01 <re_irc> Here the other one

15:01 <re_irc> RTT error: Error communicating with probe: A ARM specific error occured.

15:01 <re_irc> ────────────────────────────────────────────────────────────────────────────────

15:01 <re_irc> stack backtrace:

15:01 <re_irc> (HOST) WARN call stack was corrupted; unwinding could not be completed

15:01 <re_irc> (HOST) ERROR error occurred during backtrace creation: A ARM specific error occured.

15:01 <re_irc> Caused by:

15:01 <re_irc> The core needs to be halted for this operation but was not.

15:01 <re_irc> the backtrace may be incomplete.

15:01 <re_irc> Error: A ARM specific error occured.

15:01 <re_irc> Caused by:

15:01 <re_irc> 0: Error using access port

15:01 <re_irc> **1: Failed to write register TAR at address 0x00000004**

15:01 <re_irc> 2: The debug probe encountered an error.

15:01 <re_irc> 3: An error specific to a probe type occurred

15:02 <re_irc> 4: USB error while reading from device: No such device (it may have been disconnected)

15:02 <re_irc> I am using probe-run version 0.3.6. Has anyone got a basic idea or a pointer on what the issue could be?

15:10 <re_irc> <@dirbaio:matrix.org> what probe is it?

15:11 <re_irc> <@dirbaio:matrix.org> +and board?

15:11 <re_irc> <@xgroleau:matrix.org> A segger jlink on linux and the board is the nrf52840-dk

15:12 <re_irc> <@dirbaio:matrix.org> the builtin jlink in the dk?

15:12 <re_irc> <@xgroleau:matrix.org> yep, but I got another board with an external jlink with a similar result

15:12 <re_irc> <@dirbaio:matrix.org> that's odd, that one has always worked flawlessly

15:13 <re_irc> <@dirbaio:matrix.org> perhaps it's some usb issue? flaky usb hub or power?

15:13 <re_irc> <@dirbaio:matrix.org> does "dmesg" show something when the error happens?

15:13 <re_irc> <@xgroleau:matrix.org> Yea I'm very confused because I'm pretty sure it worked previously

15:14 <re_irc> <@xgroleau:matrix.org> Hmm, gonna check if dmesg has errors

15:16 <re_irc> <@rreignier:matrix.org> Hi! I am new to embedded rust.

15:16 <re_irc> I am writing my first driver for a sensor connected on UART (https://github.com/romainreignier/laser-range-finder-rs).

15:16 <re_irc> I would like to first test my driver on my computer using linux-embedded-hal (https://docs.rs/linux-embedded-hal/latest/linux_embedded_hal/index.html). I have then created an example using it.

15:16 <re_irc> I am still working on the API, but to wait for a response on the serial port, I have used a timer with the "CountDown" trait and used "fugit" for the Duration (https://github.com/romainreignier/laser-range-finder-rs/blob/70b055886ff43597494c36505085f105fd0c2b51/src/lib.rs#L38).

15:16 <re_irc> But "linux-embedded-hal" uses "std::time::Duration" as "T" for its "Systimer".

15:16 <re_irc> Some my question is how to make my linux program work? here (https://github.com/romainreignier/laser-range-finder-rs/blob/70b055886ff43597494c36505085f105fd0c2b51/examples/linux.rs#L30)

15:16 <re_irc> Thanks

15:20 <re_irc> <@xgroleau:matrix.org> : Good call! I'm getting a usb disconnect, weird because it happens with multiple cables. Maybe it's my usb port, gonna look it up.