<RobinMueller[m]>
* "unflipped" ones.. any ideas how to further debug this?
<RobinMueller[m]>
s/When building binaries with flip-link, I have issues to run programs properly. there seems to be some sort of memory corruption and some release call inside the defmt library panics. If I see the RAM size to 0x7FF8, it works.. I have a map file here I generated with `-Clink-args=-Map=app.map"`, but the addresses here seem to be the "unflipped" ones../When building binaries with flip-link, I have issues to run programs
<RobinMueller[m]>
properly. there seems to be some sort of memory corruption and some release call inside the defmt library panics. If I set the RAM size to 0x7FF8, it works.. I have a map file here I generated with `-Clink-args=-Map=app.map"`, but the addresses here seem to be the "unflipped" ones.. any ideas how to further debug this?/
<RobinMueller[m]>
I am not too familiar with flip-link internals, but maybe the .data/.bss section overflows into SRAM1 because of some alignment issue?
<boru>
You could do some prelimiary probing with binutils; `arm-none-eabi-size thing.elf` (for output section sizes) and `arm-none-eabi-objdump -h thing.elf` to see the output section LMA/VMAs. At runtime with a debugger, you could set some write watchpoints on the things being corrupted to see if something is clobbering them
<boru>
Generally, using a linker script with some heavy `ASSERT` usage is a good idea to detect overflows at link time is a good idea.
<boru>
Since you have a cortex-m4, the MPU can also help you with interrupting when something attempts to write into some range e.g. a guard area between your stack top and heap or .bss in the absence of a heap.
<boru>
I haven't used this flip-link thing, but that's where I'd start.
<RobinMueller[m]>
it just keeps getting more mysterious, now I manged to make it work for probe-rs flashing by setting SRAM1 alignment, but debugging/flashing with GDB still fails
<RobinMueller[m]>
* SRAM1 alignment to 4, but
<RobinMueller[m]>
and now it has started working even with GDB. OH well, I want to move to probe-rs anyway.. and another weird bug came back, I have to "activate" retrieval of RTT frames with JLinkRTTViewer first before I can grab the defmt frames with defmt-print. I guess its going back to printout debugging with probe-rs for most stuff 😅
<RobinMueller[m]>
* and now it has started working even with GDB. OH well, I want to move to probe-rs anyway.. and another weird bug came back, I have to "activate" retrieval of RTT frames with JLinkRTTViewer first before I can grab the defmt frames with defmt-print (for debugging/flashing with GDB). I guess its going back to printout debugging with probe-rs for most stuff 😅
<JamesMunns[m]>
I'd probably agree that you should use binutils, specifically `nm`, to see what flip-link is doing
<JamesMunns[m]>
`cargo nm --release -- -nS` will dump the address and size of every item, I'd look at particularly the vector table and defmt log location
<JamesMunns[m]>
Is your stack going in SRAM or SRAM_1?
<JamesMunns[m]>
I don't know if flip-link really handles multiple RAM sections correctly
<RobinMueller[m]>
SRAM0/SRAM. SRAM1 is not accessible for the instruction/data bus of the CPU interconnect
<JamesMunns[m]>
I'd probably open a flip-link issue! It's possible their linker script parser gets confused.
<RobinMueller[m]>
yeah.. maybe it's a bug. I don´t see why the alignment directive there should be an issue
<RobinMueller[m]>
reducing a bootloader from 7,1kB to 4,8 kB with defmt is also very neat.😀
<RobinMueller[m]>
s/,/./, s/,/./
<RobinMueller[m]>
s/,/./, s/,8/.4/
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hi @room, meeting time again! especially if, like me, you've just had a public holiday and now it feels like monday but you realised just in time that it's actually tuesday... agenda is https://github.com/rust-embedded/wg/discussions/834, as usual please add anything you'd like to announce or discuss and we'll start in a few minutes
<JamesMunns[m]>
It's finally the time of year where the sun is still out when the meeting starts :D
<adamgreig[m]>
finally
<adamgreig[m]>
right, let's start! the only thing I've got to talk about is the member cleanup, so if anyone else has any announcements or topics first, please go ahead
zeenix[m] has joined #rust-embedded
<zeenix[m]>
<zeenix[m]> "Hi, didn't we say that heapless..." <- ^
<zeenix[m]>
Punished -> published, obviously
Divya[m] has joined #rust-embedded
<Divya[m]>
<adamgreig[m]> "hi @room, meeting time again..." <- Hello, this is my first time, where is the meeting happening, how can I join?
<zeenix[m]>
Divya[m]: Right here, right now
<adamgreig[m]>
Divya: it's just typing in here, so you've already joined!
<Divya[m]>
Oh, I thought it was a call or something. Apologies.
<adamgreig[m]>
zeenix[m]: ah yep, I guess that's one for newam/ dirbaio/ reitermarkus
<adamgreig[m]>
though if you wanted you could probably open a pr for a 0.9 release (bumping the version number etc) to help it along :p
newam[m] has joined #rust-embedded
<newam[m]>
It's still something I want to do, just got buried at $WORK
<zeenix[m]>
adamgreig: ah ok. Crates.io blames you too so i thought you can do it. 😊
<zeenix[m]>
adamgreig[m]: Can certainly do that. I just didn't know if maintainers wanted to cut a release
<adamgreig[m]>
if no one has any other thoughts on it today then I'll put the list together this evening
<cr1901>
I was about to say... "where is the checklist"?
<adamgreig[m]>
heh, "coming soon"
<adamgreig[m]>
that's actually all I had for this week, so floor's open to anything else anyone would like to discuss :)
<JamesMunns[m]>
Just a note to take notes for anything we might want to discuss with project teams at the all hands :)
<Divya[m]>
If it's not too much, I was going to ask, how can I start with getting involved? Are there any particular projects with "good-first-issue" tickets that I can pick on?
<cr1901>
adamgreig[m]: To be clear, I'm still active. Just have not been at the last few meetings b/c "sleep schedule out of sync". Seems to be fine today
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Divya: I think it depends a lot on what your interests are. The best way is to pick something you want to do/work on and dive in, I think? We're a friendly lot and you are welcome to ask about things here.
<bartmassey[m]>
Got to go to class. Peace.
<Divya[m]>
bartmassey[m]: Okay! Thank you. But at least can one provide some map for which projects are at which timeline and so on? Looking at the GitHub organization is a bit confusing, to be honest.
<JamesMunns[m]>
Yeah, @Divya the best way to get started is to build the things you're interested in! Especially if you're new to embedded Rust, the best way to start is to build things and share, and usually help ask questions and improve docs along the way.
<JamesMunns[m]>
The embedded-wg is mostly for coordination on ecosystem-wide stuff, sometimes that's libraries, docs, etc.
<JamesMunns[m]>
embedded rust is quite a bit less of a "top down" project, like Zephyr, or other monolithic projects. There's a lot of people building lots of different things, the embedded-wg is usually where we coordinate on things that are valuable to standardize, or collaborate directly on.
<Divya[m]>
I see, I understand. I am working on some Wifi firmware chips, and doing their firmware reverse engineering. And the tools I have at hand aren't really that good at disassembly, so I was planning to work on a disassembler + assembler for 8051 and some other architectures.
<Divya[m]>
Would that be similar or interesting?
<JamesMunns[m]>
8051 isn't really supported in Rust, so it seems interesting, but probably not related to the stuff we're doing at the moment!
<JamesMunns[m]>
(cortex-m and rv32 are most common in embedded Rust, with some rv64, cortex-a, cortex-r, msp430, avr, and a few others)
<Divya[m]>
JamesMunns[m]: I meant something like this:
<JamesMunns[m]>
It looks interesting! Feel free to share here, there's probably folks that would want to follow along, even if it isn't something the wg itself would work on :)
<Divya[m]>
JamesMunns[m]: Got it.
<zeenix[m]>
Wow, people still do 8051? 😯
<zeenix[m]>
I had my first taste of embedded baremetal programming with that on 2002
<JamesMunns[m]>
I would be surprised if the largest portion of chips in the world shipped every year WASN'T still 8051 :D
jannic[m] has joined #rust-embedded
<jannic[m]>
Looks like I didn't miss much by being late to the meeting today :-)
<JamesMunns[m]>
new designs, maybe not so much, but when you need just enough CPU to poke DMA transfers, an 8051 will probably do the job :D
esden[cis] has joined #rust-embedded
<esden[cis]>
What does it entail to be part of the Embedded WG?
<adamgreig[m]>
the gist is there's a bunch of teams maintaining various projects, and if you are interested in helping maintain some of them, and ideally have done a couple of issues or PRs etc already, you can ask that team to join, and they can vote to approve, and then you're a member
<adamgreig[m]>
there's not currently any way to be part of the wg without being in one or more teams
<esden[cis]>
Ok that sounds good. I will pass this time around and work towards contributing the stuff that is slowly piling up over here. :)
<JamesMunns[m]>
We should probably add this discussion to the list for the unconf :D
<JamesMunns[m]>
(I gotta run, have a good week all!)
<Divya[m]>
<zeenix[m]> "Wow, people still do 8051? 😯..." <- It's not that I wish to do it, but some old wifi chips are 8051.
<adamgreig[m]>
JamesMunns[m]: yep, I think "what structure of membership do we have" and how do people join and do you have to be in a team and such are all worth (re)considering, especially with the rustsoc stuff
<adamgreig[m]>
I'd quite like a more open membership but right now any membership also involves write access and publish rights to a bunch of crates
<jannic[m]>
It's an art to organize a group of open source contributors in a way that scales well. If there are too many people with too far-reaching rights, it gets chaotic and bad actors might get in. If you build it too hierarchic, you demotivate contributors which have to wait for their work to be accepted, while burning out the group with the elevated rights.
<adamgreig[m]>
yea, indeed
<adamgreig[m]>
right now I think we probably have an ok number of people with rights, but it's not easy to welcome new people, and lots of PRs wait a long time for review
<adamgreig[m]>
so I wonder if having an open membership and managing write/publish rights separately might be better
<adamgreig[m]>
anyway, it will be a good thing to discuss at rustweek for sure
<adamgreig[m]>
that's all for this week's meeting, thanks everyone!
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
<JamesMunns[m]> "8051 isn't really supported in..." <- I've thought about the 8051 before, but I get the feeling that there is no single 8051 architecture
<i509vcb[m]>
I don't know if it is LLVM just not having added an 8051 backend yet or something else
<jannic[m]>
I'm always surprised that the organization of Debian works so well. There are >1000 members that do have very far reaching rights. AFAIK everyone can upload updates for every package, and the rules who maintains which package are not enforced by any access rights but only by some code of conduct. Sure, there's are _lot_ of arguments and some drama, but that's to be expected with such a large group. And such an old project where you