<re_irc>
<@walstib-alex:matrix.org> My work includes doing these things and an hour of my time for them is usually comparable to the cost of buying new things, so I may assume some ridiculous thingd 😅
<re_irc>
<@walstib-alex:matrix.org> * things
<re_irc>
<@rjmp:matrix.org> Silent mode will definitely not fix your problem. If you lift the pin, how would you do CAN comms then?
<re_irc>
<@rjmp:matrix.org> A buffer with an enable/tristate between the xcvr RX pin and the MCU could work
<re_irc>
<@firefrommoonlight:matrix.org> Lifting the pin would let me bodge-wire it to a GPIO or high to test the theory
<re_irc>
<@rjmp:matrix.org> Ah. Sorry i must have missed something in backscroll then :)
<re_irc>
<@firefrommoonlight:matrix.org> Yea; idea proposed by alexandra
<re_irc>
<@firefrommoonlight:matrix.org> : Yea that would def work
<re_irc>
<@firefrommoonlight:matrix.org> Probably a transistor + resistor etc
<re_irc>
<@walstib-alex:matrix.org> : Coming back to this, I think the idea is to solder a gpio to said pin. Still valid though, I think the silent mode won't do it
<re_irc>
<@walstib-alex:matrix.org> * pin while in the air.
vancz has quit []
vancz has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
<re_irc>
<@nvsd:matrix.org> alexandra: I'm trying to flash it using cargo flash if what you said is true I'm assuming I just have a configuration.
<re_irc>
<@nvsd:matrix.org> the command I'm using is "cargo flash --release --chip ATSAMD21G18A". I've also tried "cargo run" which is suggested in the atsamd-rs repo which gives the same error.
<re_irc>
<@walstib-alex:matrix.org> Does openocd give you the same issue
<re_irc>
<@walstib-alex:matrix.org> * issue?
<re_irc>
<@nvsd:matrix.org> I havent been able to figure out how to use openocd with this board yet. The only time I've used it is in the embedded rust book. That being said hf2 and bossac both work
<re_irc>
<@nvsd:matrix.org> cargo flash isn't that important I was ultimately hoping to use cargo embed
<re_irc>
<@walstib-alex:matrix.org> I don't have the board myself, but I've worked a bit with the xpro boards of the same series.
<re_irc>
<@walstib-alex:matrix.org> I don't know what hf2 nor bossac tbh.
<re_irc>
<@walstib-alex:matrix.org> +is
<re_irc>
<@elfmimi:matrix.org> Hi. "hf2 and bossac work" means there is a bootloader resident in the very first portion of the chip's flash. and like alexandra said bootloader protect itself using NVMCTRL_BOOTPROT .
<re_irc>
<@elfmimi:matrix.org> You have to mass-erase the chip if you want to use the whole flash for rust code. or otherwise you have to shift the location of the rust code by modifying memory.x and stick with use of bootloader.
<re_irc>
<@walstib-alex:matrix.org> I can't take credit or responsibility here at all, what I meant s that some libraries will treat 0x0 as NULL and simply regard it as defined undefined memory. Sorry if I was being unclear
<re_irc>
<@walstib-alex:matrix.org> * is
<re_irc>
<@elfmimi:matrix.org> Hi. "hf2 and bossac work" means there is a bootloader resident in the very first portion of the chip's flash. and ~like alexandra said~ bootloader protect itself using NVMCTRL_BOOTPROT .
<re_irc>
<@walstib-alex:matrix.org> "Defined undefined" meaning **the null address**
<re_irc>
<@walstib-alex:matrix.org> It is protected in the sense that if you write to NULL=0x0, that should generate an error becaude it is usually insane
<re_irc>
<@walstib-alex:matrix.org> Someone in my proximity had their flash start at 0x0 and it gave a similar error, but that was >2y ago, I don't remmember what they did
<re_irc>
<@walstib-alex:matrix.org> It is protected in the sense that if you write to NULL=0x0, that should generate an error because it is usually insane
<re_irc>
<@walstib-alex:matrix.org> Someone in my proximity had their flash start at 0x0 and it gave a similar error, but that was >2y ago, I don't remember what they did
<re_irc>
<@walstib-alex:matrix.org> Actually, I'll ask around on tuesday because it was kinda fucky to begin with and I think it happened on same54p
<re_irc>
<@walstib-alex:matrix.org> * same54p20
<re_irc>
<@walstib-alex:matrix.org> Actually, I'll ask around on tuesday because it was kinda fucky to begin with and I think it happened on same54p20
<re_irc>
<@walstib-alex:matrix.org> * same5xxxx
<re_irc>
<@9names:matrix.org> alexandra: it's not insane. in fact, it is unusual to write protect that address because the cortex-m spec requires you to put the vector table there
<re_irc>
<@9names:matrix.org> i only know of one MCU that doesn't allow you to write there, because they put a ROM vector table there. it's very annoying and I'm glad that other vendors did not go that route.
<re_irc>
<@walstib-alex:matrix.org> But you should be able to connect with oocd either way, first establish that this part is working without flashing
<re_irc>
<@walstib-alex:matrix.org> : This is probably the same point of contest, I'll shut up about it but I'm sure that software bootloaders don't like writing to NULL
<re_irc>
<@9names:matrix.org> you don't actually write to the mapped address when you're programming flash anyway, and you never reference address 0 in your code so it's not really a point of contention
<re_irc>
<@walstib-alex:matrix.org> Like, if you have a good bootloader it won't be an issue
<re_irc>
<@walstib-alex:matrix.org> : Yeah
<re_irc>
<@walstib-alex:matrix.org> Not all bootloaders are created equal or something, I've seen it
<re_irc>
<@walstib-alex:matrix.org> Which is why I'll wait for sn extended holiday before asking stupid questions
<re_irc>
<@walstib-alex:matrix.org> A more urgent question would be why they are writing to 0x0 to begin with, because decent debuggers know where to start
<re_irc>
<@walstib-alex:matrix.org> At flash, that is
<re_irc>
<@walstib-alex:matrix.org> I'm now at my laptop and looking at the datasheet the internal flash starts at 0x0
<re_irc>
<@walstib-alex:matrix.org> +(actually)
<re_irc>
<@9names:matrix.org> right, this is not surprising. it's strange that the debugger is writing to that address though, because if they're using the linker script from the repo as stated, there should be nothing in the elf at this address.
<re_irc>
<@walstib-alex:matrix.org> nvsd: To get back to the actual issue, try using another debugger software and/or probe, 9names @9names:matrix.org: has some good points and the m4 chips have dual banks, so I don't know
<re_irc>
<@walstib-alex:matrix.org> : Indeed, the issue may be more easily addressed on github given that there are board-level examples and all
<re_irc>
<@9names:matrix.org> it could be something simple, like failing to copy the build.rs from the feather_m0 repo.
<re_irc>
nvsd: have you tried running the examples directly from the atsamd repo using cargo flash? that should be heavily tested, and if you were to file a bug report it would be easy for someone to reproduce your issue.
<re_irc>
<@nvsd:matrix.org> Ok yeah good points
<re_irc>
<@nvsd:matrix.org> Sorry was trying to figure out openocd and I was able to get debugging working with gdb and openocd so that's a start. Ill try to get flashing working there and then as mentioned try to flash the examples. Thanks so much for the help and alexandra
<re_irc>
<@nvsd:matrix.org> * examples in the atsamd-rs repo for the board.
<re_irc>
<@nvsd:matrix.org> Yeah I got the same error trying to flash blinky basic. Opened up an issue so we'll see if that gets any hits. Thanks again.
<re_irc>
<@vulfe:matrix.org> Hey folks! I'm new to the world of embedded systems and I'm going through the Discovery book, but for some reason, the source file in Chapter 8 (I2C) doesn't compile. I would probably have more success with troubleshooting if I had literally any idea what I was doing, but sadly I don't. The output of the cargo build command looks like this (https://pastebin.com/Tvne6CKC); to my knowledge, I haven't changed anything material...
<re_irc>
... about the source code
<re_irc>
<@thejpster:matrix.org> You appear to be Building for the nRF51 and nRF52 at the same time, resulting in duplicate definitions b
<re_irc>
<@thejpster:matrix.org> * definitions.
<re_irc>
<@thejpster:matrix.org> Do you have the full project in a public repo?
<re_irc>
<@thejpster:matrix.org> You appear to be building for the nRF51 and nRF52 at the same time, resulting in duplicate definitions.
<re_irc>
<@vulfe:matrix.org> the thing that's confusing to me is that the dependency looks like it ultimately originates from microbit-common but other chapters also use that without issue
<re_irc>
<@thejpster:matrix.org> And which feature did you enable?
<re_irc>
<@vulfe:matrix.org> v2
<re_irc>
<@thejpster:matrix.org> what does cargo tree say?
<re_irc>
<@lambdafriend:matrix.org> I'm developing a program for an RP-2040 board, but most of my logic resides in modules that do not rely on anything embedded. I'm wanting to write tests for them, but I'm getting various errors ("can't find crate for "test") because it is a no_std environment with a target of "thumbv6m-none-eabi".
<re_irc>
All of this makes sense!
<re_irc>
However, I'm hoping that there is a setup that lets me test the various modules as if they're "normal" rust since they have nothing to do with embedded libraries.
<re_irc>
Does anyone have any strategies for testing like this?
<re_irc>
<@thejpster:matrix.org> You can’t easily test binaries. Easiest to move the logic to another crate and test it the usual way, then bring it into the binary as a library. You’ll need to only enable no_std if it’s not(test) otherwise your test cases can’t print stuff to the console and other libstd things.
<re_irc>
<@thejpster:matrix.org> #![cfg_attr(not(test), no_std)] off the top of my head
<re_irc>
It’s dangerously close to Perl…
<re_irc>
<@lambdafriend:matrix.org> Cool, that was my only idea. Seems straightforward. Appreciate the help! 🙏
emerent_ has joined #rust-embedded
emerent is now known as Guest4939
emerent_ is now known as emerent
Guest4939 has quit [Ping timeout: 252 seconds]
<re_irc>
<@vulfe:matrix.org> : cargo tree confirms that both optional dependencies (nrf51-hal and nrf52833-hal) of microbit-common are being used in this case (instead of just the one, which is what happens in the other projects), which suggests that microbit-common is using the v1 feature for some reason, but I don't really know why
<re_irc>
<@vulfe:matrix.org> Aha! Okay, it looks like removing the (non-v2) microbit crate from the dev dependencies fixed the issue
<re_irc>
<@vulfe:matrix.org> thanks for your time :)
<re_irc>
<@vulfe:matrix.org> I don't know how that got there to begin with... it's not in the repo
<re_irc>
<@firefrommoonlight:matrix.org> Oh god I really do have a CAN heisenbug. Verified from Logic Analyzer. When I'm using the debugger of the transmitter to print the buffer I'm sending, everythign is well! When not using the debugger or debugging the reciever, much of the data is missing!!
<re_irc>
<@firefrommoonlight:matrix.org> Got to be something to due to buffer logevity / memory/UB etc
<re_irc>
<@firefrommoonlight:matrix.org> Oh god I really do have a CAN heisenbug. Verified from Logic Analyzer. When I'm using the debugger of the transmitter to print the buffer I'm sending, everythign is well! When not using the debugger or debugging the reciever, much of the data is missing!! (0s)
<re_irc>
<@thejpster:matrix.org> Yes I dimly recall that dev dependencies share features with normal deps. It’s frustrating.
<re_irc>
<@firefrommoonlight:matrix.org> *Strange UB etc sorted with delays inserted at startup :/
IlPalazzo-ojiisa has quit [Remote host closed the connection]