<re_irc>
<sajattack> usually it's offset a bit to leave room for the bootloader
<re_irc>
<sajattack> orclev:
<re_irc>
<orclev> near as I can tell yes. The bootloader seems to be located at the top of the address space. The instructions I found have an offset to allow for the proprietary BLE stack that Nordic provides (SoftDevice) but if you aren't using that it seems like the offset is in fact 0.
<re_irc>
<orclev> I'm trying to find the address of the bootloader now, I had previously found it, but I can't recall where
<re_irc>
<sajattack> it's a cargo subcommand that implements a flashing protocol most uf2 bootloaders also implement
<re_irc>
<sajattack> and I thought it had some device-specific defaults but I can't find them
<re_irc>
<orclev> that's one of the next things I was going to try, but I need to do a little work to transfer my project to another computer first. The one I'm on currently is a Windows system so not supported by that utility
<re_irc>
<sajattack> ah
<re_irc>
<sajattack> well anyway you've come to the right place because jacobrosenthal and I are both in this room
<re_irc>
<sajattack> you could also try leaving off the family specifier, it's not always necessary in my experience
<re_irc>
<orclev> when I did that the bootloader just rejected the uf2 file
<re_irc>
<sajattack> ok
<re_irc>
<orclev> I might be wrong about the offset value, but I would also expect if I was that it would be bricking the device which it isn't, I can hit the reset pin and get it back into the DFU firmware
<re_irc>
<orclev> yep, that's what I've been following (among other things). The offset recommended in there of 0x26000 and 0x27000 are based on the SoftDevice version which I'm not using. I had originally started this using 0x26000 as the originally flashed firmware included S140 v6, but when I upgraded the bootloader it started reporting no SoftDevice firmware included. In either case it doesn't work with a value of 0x26000 and I'm not sure what else to...
<re_irc>
... possibly put in there.
<re_irc>
<sajattack> ah darn
<re_irc>
<orclev> I wonder if I could use one of the pre-built uf2 files that includes SoftDevice and extract the offset that gets written to out of it (assuming it isn't 0x0)
<re_irc>
<orclev> also you'd think their bootloader would tell you what address it's expecting to find non-bootloader code at
<re_irc>
<orclev> I suppose I could try re-flashing it with a firmware image that includes SoftDevice and then upload my code at 0x26000
starblue has joined #rust-embedded
mattgirv has joined #rust-embedded
GenTooMan has joined #rust-embedded
inara has joined #rust-embedded
<re_irc>
<9names (@9names:matrix.org)> Yeah, I assume these addresses only make sense when there's a softdevice, since that is what jumps to bootloader address or application address.
starblue has quit [Ping timeout: 265 seconds]
<re_irc>
<orclev> hmm, I was assuming the boot process was basically CPU boots up and jumps to 0xF4000 and runs the bootloader, bootloader then jumps to SoftDevice at 0x0 (or straight into application code at 0x0 if no SoftDevice being used) where it does what it needs to then jumps to application code at whatever offset is appropriate for that version of SoftDevice. If that's not how it works with no SoftDevice version present on this board I'm not quite...
<re_irc>
... sure how it's getting into the boot loader.
starblue has joined #rust-embedded
<re_irc>
<orclev> the official nordic docs for the nRF52840 are frustratingly vague about the whole thing with just a blank "Flash" box showing at address 0x0 with no further elaboration about it or the boot process, or at least not that I've found so far
<re_irc>
<orclev> success! Apparently even if you aren't using it, you need to have SoftDevice present. I reflashed SoftDevice S140 v6.1.1 onto it and then rebuilt my app and generated the UF2 at offset 0x26000 and it now works after flashing it.
<re_irc>
<orclev> or at least I think it's working... need to test some more to verify
conplan has joined #rust-embedded
<conplan>
does anyone here have any expierience with the MSP432P401R platform
<conplan>
in rust?
<re_irc>
<orclev> I think I may have spoke too soon. I had assumed it had worked because I got the LED blinking like I wanted, but I now think that's just what happens when SoftDevice boots up with no application code present :|
<re_irc>
<orclev> yeah, it's definitely not running my code
conplan has quit [Remote host closed the connection]
emerent has quit [Ping timeout: 268 seconds]
emerent has joined #rust-embedded
<re_irc>
<9names (@9names:matrix.org)> @irc_libera_conplan:psion.agg.io: If you have a question, I suggest you ask it. If there's someone here with relevant experience they will try to help 🙂
emerent has quit [Remote host closed the connection]
<re_irc>
<orclev> Solved it. So, the default memory.x that gets included with the HAL crate _does not_ take into account SoftDevice, so the memory address ends up being off. I adjusted the memory.x to put the origin for FLASH at 0x26000 and it started working.
starblue has quit [*.net *.split]
mattgirv has quit [*.net *.split]
genpaku has quit [*.net *.split]
tafa has quit [*.net *.split]
Lumpio- has quit [*.net *.split]
m5zs7k has quit [*.net *.split]
rektide has quit [*.net *.split]
Lumpio- has joined #rust-embedded
starblue has joined #rust-embedded
mattgirv has joined #rust-embedded
tafa has joined #rust-embedded
m5zs7k has joined #rust-embedded
rektide has joined #rust-embedded
genpaku has joined #rust-embedded
<re_irc>
<luojia65> Bouffalo Labs has made crate bl808-pac public: https://github.com/bouffalolab/bl808-pac. This is the first semiconductor company ever have released an official embedded Rust support for their chip, it includes conventional peripherals and a framework for radio frequency peripherals.
<re_irc>
<barafael> That's some ludicrous performance numbers!
<Darius>
pretty mind boggling what you can get in what is probably a <$10 part
<Darius>
lol the whole thing is $10
<Darius>
so more like <$2
<re_irc>
<chaosprint> possible price?
<re_irc>
<9names (@9names:matrix.org)> "Pricing for the Pine64 Ox64 is not finalized, but it will be under $10, and possibly as low as $6 for the model with 16MB flash."
<re_irc>
<chaosprint> amazing
<re_irc>
<9names (@9names:matrix.org)> that's 2MB by the way, classic mbit/mbyte mixup
<re_irc>
<eldruin> > Update: The model with 16MB flash and no microSD socket will sell for $6, the model with 128MB flash and microSD socket will go for $8. Mass production is scheduled for mid November
causal has quit [Quit: WeeChat 3.6]
cr1901_ has quit [Read error: Connection reset by peer]
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
<re_irc>
<James Munns> Congrats on the release luojia65 :D
<re_irc>
<James Munns> Interesting it uses the same C906 core, which is the same used in the Allwinner D1/D1s!
<re_irc>
<James Munns> Also fun fact, we're coming up on the five year anniversary of the embedded wg (early next year). I'd be interested in compiling some stories and history if anyone is interested in writing something up from their perspective.
<re_irc>
<chaosprint> Hi, I wonder why this number can block the blink?
<re_irc>
<chaosprint> When it is 8, the blink works fine
<re_irc>
<chaosprint> Hi, I wonder why this capacity number can block the blink even if it still compiles without errors?
<re_irc>
<ryan-summers> Are you overflowing your stack and making the process do something undefined?
<re_irc>
<ryan-summers> +You might be seeing an out-of-memory condition result in strange behavior
<re_irc>
<chemicstry> pro tip: use probe-run to see panics, hardfaults, etc along with a backtrace instead of just flashing binary and hoping it shows some signs of life
<re_irc>
<chaosprint> ryan-summers: I guess it's overflowing...
<re_irc>
<ryan-summers> You can look at flip-lld as well if you're using cortex-m, which will elevate a stack overflow to a HardFault ISR
<re_irc>
<ryan-summers> Maybe flip-link nowadays, I don't recall the name
<re_irc>
<chaosprint> chemicstry: I use "cargo embed" as recommended from the rust embedded book. Can "cargo embed" be used for debugging as well?
<re_irc>
<chaosprint> I guess it's overflowing... Will get a board with 64MB RAM for testing this week.
<re_irc>
<ryan-summers> It can be used to start up a GDB stub if you'd like
<re_irc>
<ryan-summers> But probe-run is a non-interactive debug session that is likely what you're looking for
<re_irc>
<ryan-summers> It will also give you e.g. RTT output and print-like capabilities through the debug probe
<re_irc>
<ryan-summers> Check out arp | Tee-Object -FilePath c:\junk\dir.txt
<re_irc>
<dimpolo> Hi everyone, I'm facing some very strange behaviour and I'm not sure where to go with this.
<re_irc>
In short, using cargo objcopy seems to produce a wrong binary.
<re_irc>
Probe-rs flashes correctly and if I read out the flash afterwards and compare the binaries I can see that objcopy produces a couple 0 bytes to many
<re_irc>
<dimpolo> What do I do with this? 😅
<re_irc>
<dimpolo> Could there be a bug in cargo objcopy? If I understand correctly that would be a bug in LLVM?
<re_irc>
<xiugaze> Hi all, I have probably an obvious question about building drivers using stm32f4xx_hal. What's the convention for using delay inside of a driver? Do I have to pass the delay singleton to every api call that I need a delay? Is there a better way to use the delay without giving ownership to the driver instance?
cr1901 has joined #rust-embedded
<re_irc>
<Hendrik> xiugaze: what a coincidence, I'm here the first time since months and that's a thing I also wondered about
<re_irc>
<Hendrik> is anyone here using the "onewire" and/or the "ds18b20" crates?
<re_irc>
<riskable> I'm having trouble understanding the "memory.x" file... It says, "/* NOTE 1 K = 1 KiBi = 1024 bytes */" so if my flash origin is "ORIGIN = 0x10000000" and I'm using a 16 megabyte flash chip the final address would be "0x10000000+16384K" which is... 0x100000000000000. That can't be right. That's much bigger than the memory.x file would indicate is possible
<re_irc>
<riskable> Oh, _it's hex_
<re_irc>
<riskable> So the 16MB mark in flash is actually 0x11000000 👍
<re_irc>
<adamgreig> dimpolo: how's the elf built?
<re_irc>
<dimpolo> cargo build --release with the usual stm32 settings in .cargo/config
<re_irc>
<adamgreig> any chance you could also have a little example repo for that part? just in case it's also anything weird there or linker scripts or linkers or whatever
<re_irc>
<asdfuser> Hendrik: I have it reporting my central heating temperature through mqtt. There were some issues I found (and fixed).
<re_irc>
<Hendrik> @asdfuser: I can't get the "onewire" crate to find my sensors
<re_irc>
<adamgreig> i'm "rust-objcopy --version" "LLVM version 14.0.6-rust-1.64.0-stable"
<re_irc>
<adamgreig> on x86_64-unknown-linux-gnu
<re_irc>
<dimpolo> I'm on windows, but I originally noticed the problem in Linux CI
<re_irc>
"LLVM version 15.0.2-rust-1.66.0-nightly"
<re_irc>
<dimpolo> Could you try a recent nightly?
<re_irc>
<Hendrik> asdfuser: Do you use the DS18b20 on 3V or 5V? The basic wiring seems to work, at least the reset flow works, where the DS18b20 pull the signal to low to indicate its presence
<re_irc>
<Hendrik> Yes I own a logic analyzer, maybe the next step to try.
<re_irc>
<adamgreig> dimpolo: ok, with "LLVM version 15.0.2-rust-1.66.0-nightly" I get:
<re_irc>
<dimpolo> So, what do we do about this? Is this an LLVM bug?
<re_irc>
<adamgreig> seems likely something has changed in llvm 15 yea... which llvm was used to make the elf ooi?
<re_irc>
<adamgreig> GNU arm-none-eabi-objcopy agrees with probers and llvm14
<re_irc>
<adamgreig> I think start by opening a bug on rust-lang. I feel like I saw someone else have the same problem here a while back, but maybe it was you
<re_irc>
<dimpolo> adamgreig: same one
<re_irc>
<dimpolo> adamgreig: nope :)
<re_irc>
<adamgreig> hmm
<re_irc>
<adamgreig> I can't find them with a quick search and am about to have dinner but i'll see if I can find anything later
causal has joined #rust-embedded
<re_irc>
<asdfuser> Hendrik: I started with 5V, but now use 3.3V. The pullup also seems important (especially wit some clones), I think I use 1k now
<re_irc>
<dimpolo> thanks for your help, i'll link the issue here after I've created it
<re_irc>
<Hendrik> asdfuser: the start looks good, somehow
emerent has quit [Ping timeout: 264 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
dc740 has quit [Remote host closed the connection]
<re_irc>
<thebutlah> are there any good rust based alternatives to sigrok for cypress FX2LP signal analyzers (salae clones)
<re_irc>
<thebutlah> sigrok is super buggy for me
<re_irc>
<thebutlah> are there any good rust based alternatives to sigrok for cypress FX2LP signal analyzers (saleae clones)
<conplan>
I'm having some trouble with compiler error E0557 he bare metal lirary
<conplan>
*library
<conplan>
damn feature attributes
<re_irc>
<dirbaio> if you want help post the full error, nobody knows from memory what E0557 is
conplan has quit [Ping timeout: 246 seconds]
<re_irc>
<adamgreig> dimpolo: your ELF seems a bit peculiar, any chance you could share the linker script/memory.x?
<re_irc>
<adamgreig> the first section has an offset 0xf4 and a load address 08004000 with a 4 byte alignment, which is fine if a bit unusual, the next section is fine, then the third section has an offset 6924 and an alignment of 16 bytes.... so the offset isn't 16-byte aligned and then llvm15-objcopy moves it to a 16 byte alignment offset
<re_irc>
<adamgreig> but, because the first section has that 0xf4 offset, actually the 0x6924 offset of the third section ends up being 16-byte aligned
<re_irc>
<adamgreig> so I strongly suspect the problem here is llvm15-objcopy is making a mistake about alignment _or_ has a different idea about what the alignment means, but you're possibly making a lot of trouble for yourself with the weird offsets and alignments of the earlier sections
<re_irc>
<dirbaio> then edit Cargo.toml, change "my-lib = "1.2.3"" to "my-lib = { path = "/path/to/code" }"
<conplan>
re_irc: okay, I figured that out, but now my OS denied permission to execute a build script
<conplan>
do you know how I can overcome this error?
<re_irc>
<adamgreig> what OS? what error? it's not uncommon for building a rust crate to execute a build script
<conplan>
yeah. I was trying to build on a USB. moved it to main partition and it worked fine
<re_irc>
<adamgreig> dimpolo: I'm more and more sure it's https://github.com/llvm/llvm-project/issues/55246 that's the issue, and it came in in llvm15, so probably open an issue over on the llvm tracker, reference that issue and the commit that closed it, see what they think... it would be interesting to see why your elf has these offsets and alignments tho