<re_irc>
Look for the bullet points below "The requirement of restoring the stack pointer and non-output registers to their original value only applies when exiting an asm! block"
dc740 has joined #rust-embedded
<re_irc>
<TimSmall> I'm periodically rebasing this PR which I made: https://github.com/stm32-rs/stm32-rs/pull/713 against upstream master. If the rebase requires some fixup, I do that, and then force-push the PR branch. If the rebase is completely automatic (i.e. no conflicts), should I still push the result? I wasn't sure whether either of the following is true if I do that:
<re_irc>
- Helpful / useful to anyone reviewing the code
<re_irc>
?
<re_irc>
- Creates unnecessary noise for repo maintainers
dc740 has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
Amadiro has joined #rust-embedded
<re_irc>
<adamgreig> TimSmall: what you're doing is great and it's helpful to have the PRs up to date, though when there's no conflicts I guess it doesn't strictly matter either way
causal has quit [Quit: WeeChat 3.5]
<re_irc>
<yruama_lairba> Hi, sorry to for the slightly off topic question: i'm considering to buy a cheap logic analyzer, have you advice for that ?
<re_irc>
<ryan-summers> Check out http://sigrok.org/wiki/Supported_hardware - I think the SigRok firmware can run on some basic dev boards? In any case, that link has a lot of possibilities
<re_irc>
<ryan-summers> Saleae's are also nice, but tend to be in the pricier range (300-500 EUR)
<re_irc>
<yruama_lairba> i'm not considering buying a Saleae, too expensive for me, especially when you can find USB-analyzer under 10€
<re_irc>
<ryan-summers> Oh wow, the contractor discount is way less than it used to be
<re_irc>
<ryan-summers> Ah nevermind, still very similar to what they used to be back in 2018
<re_irc>
<adamgreig> James Munns: If it broke I bet they'd replace it, ime their customer service has been exceptional
<re_irc>
<adamgreig> My original logic broke after like six years and they just posted me a new one
<re_irc>
<ryan-summers> Yeah, I've had wonderful experience with their customer service as well
<re_irc>
<James Munns> adamgreig: Yeah, my one was DOA, and they overnighted me a replacement
<re_irc>
<James Munns> Definitely +1 to good service, but yeah, it's expensive
iyedonhismed has joined #rust-embedded
aspe has joined #rust-embedded
dc740 has joined #rust-embedded
aspe has quit [Client Quit]
aspe has joined #rust-embedded
aspe has quit [Quit: aspe]
aspe has joined #rust-embedded
<re_irc>
<Lachlan> I'm trying to compile a binary for the second flash bank on my MCU and rust-lld complains about it being too large for the FLASH. It's definitely not, but I think the linker thinks that it should all fit in the first flash bank, when none of it is being put there.
<re_irc>
rust-lld: error: section '.text' will not fit in region 'FLASH': overflowed by 1036 bytes
<re_irc>
rust-lld: error: section '.text' will not fit in region 'FLASH': overflowed by 1318 bytes
<re_irc>
<Lachlan> Do I just need to swap the addresses assigned to "FLASH" and "FLASH1"?
<re_irc>
<James Munns> If you are treating them as the same, you could just merge the wro
<re_irc>
<James Munns> * two
<re_irc>
<ryan-summers> I think you need to tell it to link .text into FLASH and FLASH1 both. If they're contiguous and there's no additional config, then yeah just merge them
<re_irc>
<ryan-summers> But if you have to e.g. power up 1 flash bank first, that's obviously an issue
<re_irc>
<Lachlan> Yeah, that might work. I don't think there's any special configuration I need to do
<re_irc>
<James Munns> Not sure what the different flash banks do, unless you're trying to do fancy bootloader stuff (e.g. run from bank A while writing to bank B)
<re_irc>
<Lachlan> Though, it's easier for me if I say flash bank 1 is for the bootloader and flash bank 2 is for the application
<re_irc>
<Lachlan> That's exactly what I'm trying to do
<re_irc>
<dirbaio> your firmware is bigger than 1mb? 💀
<re_irc>
<Lachlan> No lol, but debug builds are pretty large
<re_irc>
<James Munns> opt-level=1 is good for debug builds IMO
<re_irc>
<ryan-summers> Rust without high optimization is pretty huge with lots of dependencies
<re_irc>
<James Munns> still mooooostly debuggable, but also inlines the silly simple stuff
<re_irc>
<James Munns> Or, optimize your deps, but not your main, with profile overrides
<re_irc>
<James Munns> Are you trying to make your bootloader + app one binary?
<re_irc>
<James Munns> If so, I probably wouldn't recommend that
<re_irc>
<Lachlan> No, not one binary
<re_irc>
<James Munns> I'd probably make two binary projects, one that "only" uses Bank A, and one that "only" uses Bank B.
<re_irc>
<Lachlan> Yeah, that was my plan, but the linker was complaining about putting stuff in bank B, but I guess if I make it contiguous and then offset it into bank B, that'll work
<re_irc>
<James Munns> "cortex-m-rt" treats the section specifically named "FLASH" as special, basically that's the only place it puts ".text" and stuff by default.
<re_irc>
<Lachlan> Ah, that explains it
<re_irc>
<James Munns> I'd probably just "lie" and pretend the other bank doesn't exist.
<re_irc>
<James Munns> IIRC, cortex-m-rt doesn't do anything at all for any sections other than "FLASH" or "RAM"
<re_irc>
<James Munns> so that's on you to manage anyway. You might be able to extend it to work without repeated boilerplate, but I don't usually mess with that.
<re_irc>
<James Munns> (the docs for this are very good, btw)
<re_irc>
<ryan-summers> No, but you can very much so do your own loading in memory.x - Quartiq does it for ITCM on the H7 for Stabilizer
<re_irc>
<James Munns> Yeah, I'm not sure if that "enable QE" code is correct, but there it is :D
<re_irc>
<willeml> Thanks :D
dc_740 has joined #rust-embedded
<re_irc>
<willeml> Still working on this silly flash thing, I would have expected it to be easier than the display...
dc740 has quit [Read error: Connection reset by peer]
iyedonhismed has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
<re_irc>
<yruama_lairba> crap, i just realized a cheap logic analyzer may too slow to analyse I2S frame
<Lumpio->
Really? How fast does sound need to go?
<re_irc>
<yruama_lairba> for 48Khz 32bits sample, the bit clock is around 3Mhz
<re_irc>
<yruama_lairba> logic analyzers i was looking for are specified to go up to 24MHz but can only go to 4Mhz in continuous mode
<Lumpio->
Where is the sound going if it needs 32 bits?
<re_irc>
<firefrommoonlight> The cheap chinese ones seem to fail reporting over ~6Mhz
<re_irc>
<firefrommoonlight> Knowing what you do about the nyquist frequency in regards to audio quality, maybe there's an inference to be had
<re_irc>
<firefrommoonlight> The cheap Chinese ones seem to fail reporting over ~6Mhz
limpkin has quit [Quit: limpkin]
<re_irc>
<yruama_lairba> inference ?
<re_irc>
<yruama_lairba> this just makes those logic analyzer almost useless for this use
<re_irc>
<firefrommoonlight> If yours will work at 6Mhz...
<re_irc>
<firefrommoonlight> (You said 4, but I recommend confirming 6)
<re_irc>
<firefrommoonlight> Obviously higher is better and you should probably get a better LA...
<re_irc>
<firefrommoonlight> Personally I've been using a scop to make sure the various audio clocks are operating at the right freq, but if you need to debug the signal, the answer really might be shell out a few hundred $ on a new LA
<re_irc>
<firefrommoonlight> *Or you could use the scope as a LA, although this can be a PITA
<re_irc>
<firefrommoonlight> Eg the Rigol DS1054 can do it, but is cumbersome compared to a LA
<re_irc>
<firefrommoonlight> Eg, if you have multiple audio channels over PCM, you can easily be working with a 12Mhz audio clock
<re_irc>
<yruama_lairba> firefrommoonlight: have you already used SPI/I2S device of stm32 chip ? i discovered some anoying thing with it
<re_irc>
<yruama_lairba> in master transmit mode, the channel status flag is sometime wrong
<re_irc>
<yruama_lairba> an disable/enable the device don't reset clock phase
<re_irc>
<yruama_lairba> this cause me issue with the hal i'm writing.
<re_irc>
<yruama_lairba> i guess i should add and use a mechanism to do a reset from RCC register
limpkin has joined #rust-embedded
<re_irc>
<willeml> Is there a way do single byte accesses to a word sized register? The ref manual for stm32f7 says that I can write single bytes to the QSPI data register if I access it as a byte register
<re_irc>
<James Munns> If you cast the address to a u8 pointer and write volatile to that, the compiler will emit a word write
<re_irc>
<James Munns> not sure how to do that specifically/safely for your platform
<re_irc>
<willeml> So I can specify the type of access by using a pointer instead of the register interface?
<re_irc>
<willeml> Probably easier for me to just convert my u8 array to a u32 array then
<re_irc>
<James Munns> uhhh, there might be other ways
<re_irc>
<James Munns> but if you do a volatile u8 write, it will translate to a word write instruction
<re_irc>
<James Munns> errr
<re_irc>
<James Munns> byte write instruction
<re_irc>
<willeml> Ohhh ok, good, I want a byte write instruction
<re_irc>
<yruama_lairba> willeml: there isn't a configuration to say the size in bits of your frame ?
<re_irc>
<willeml> As far as I can tell no
<re_irc>
<yruama_lairba> and what is the issue of reading the whole register instead of just a bytes ?
<re_irc>
<willeml> If I write to the whole register I have to convert u8 slices to u32 slices because otherwise it would just write 3 empty bytes to the flash chip before writing the actual data I want
<re_irc>
<willeml> At least, I think that's what the datasheet says
<re_irc>
<yruama_lairba> no, in think there is special instruction allowing you to retrieve bytes, half-bytes or words. it may require some assembly code
<re_irc>
<James Munns> Yeah, "STR" and "LDR" have suffixes for this
<re_irc>
<James Munns> e.g. "STRB" for storing a byte instead of a word.
<re_irc>
<James Munns> (or "STRH" for half-word)
<re_irc>
<James Munns> buuuut
<re_irc>
<James Munns> a u8-ptr volatile write should emit a STRB instruction.
aspe has quit [Quit: aspe]
<re_irc>
<firefrommoonlight> yruama_lairba: yes
<re_irc>
<firefrommoonlight> Sorry NO
<re_irc>
<firefrommoonlight> SAI
<re_irc>
<yruama_lairba> it may have the same kind of annoyance though
<re_irc>
<firefrommoonlight> I haven't checked the chan status flag
<re_irc>
<firefrommoonlight> Not familiar with it
<re_irc>
<firefrommoonlight> I've ran into lots and lots of issues, always due to soldering faults or improper config of the SAI periphs or external ones
<re_irc>
<firefrommoonlight> So many ways to configure these (for flexibility with a wire range of protocols and variants), and if you don't have it exactly right, things go wrong!
<re_irc>
<firefrommoonlight> A lot of times there are many valid config combos, but you have to make sure the 2 devices are configured the same way, which ever one of those you choose
<re_irc>
<yruama_lairba> and add interrupt and DMA to that :p
<re_irc>
<yruama_lairba> do you use only pac for your sketch ?
<re_irc>
<firefrommoonlight> No, I built a HAL lib
<re_irc>
<firefrommoonlight> DMA and interrupts are handled by methods on the "Sai" struct.
<re_irc>
<9names (@9names:matrix.org)> firefrommoonlight: Really? The cheap fx2 based LAs I've used handle 24mhz on 8 channels just fine.
<re_irc>
Host OS can be a bit picky, but I can't remember ever getting underruns at 12mhz.
gsalazar has quit [Ping timeout: 252 seconds]
iyedonhismed has quit [Remote host closed the connection]
<re_irc>
<firefrommoonlight> What I've specifically observed is if I set it above (and it is fx2 based) 6Mhz, I get no output. (I may be misremembering the specific speed?)
<re_irc>
<firefrommoonlight> On Windows
<re_irc>
<firefrommoonlight> There appeared to be a clean cutoff between "Output is fine" and "output is nothing", although I didn't troubleshoot since I didn't need the higher rate other than providing more precise edges
<re_irc>
<Catherine> is this with pulseview?
<re_irc>
<Catherine> the thing about fx2-based logic analyzers is that the fx2 has very little buffer space (2Kx8) and the moment you run out of buffers you
<re_irc>
<Catherine> +have an overflow
<re_irc>
<Catherine> which means that your host software must schedule transfers such that the host controller keeps emptying its buffers even if it experiences spikes in latency
<re_irc>
<Catherine> the best way to do this varies with the OS (and the host controller, and a few other things), and sigrok/pulseview doesn't seem to be very good at it
dc_740 has quit [Remote host closed the connection]
<re_irc>
<firefrommoonlight> Yes
<re_irc>
<firefrommoonlight> SOunds likely
<re_irc>
<Lachlan> Is it reasonable that a single flash sector on an stm32h7 takes just over 800 ms to erase?
<re_irc>
<James Munns> That seems like a lot
<re_irc>
<James Munns> but the datasheet is probably the only place with the real answer
<re_irc>
<James Munns> they should have max timings for page/sector/entire erase
<re_irc>
<firefrommoonlight> Yea...
<re_irc>
<firefrommoonlight> The H7 sectors are much larger than the pages used on some variants, but still
<re_irc>
<James Munns> What part?
<re_irc>
<Lachlan> stm32H743IIT6
<re_irc>
<James Munns> Whew, 4s max erase time for a 128KB sector
<re_irc>
<James Munns> that's, wow.
<re_irc>
<Lachlan> Yeah, I'm looking at the datasheet
<re_irc>
<Lachlan> that's insane
<re_irc>
<James Munns> Usually that's measured AFTER 10K cycles, so it's usually much faster
<re_irc>
<James Munns> Not sure if you're doing their x64 parallelism thing
<re_irc>
<Lachlan> Looking at the hal implementation, it seems like it's the x32
<re_irc>
<Lachlan> I do need to erase before writing, right?
<re_irc>
<James Munns> it takes 169ms to do a full erase (1MiB) of the nrf52840 on chip flash :p
<re_irc>
<Lachlan> :(
<re_irc>
<James Munns> yes (unless the HAL does it for you)
<re_irc>
<Lachlan> It seems it does not
<re_irc>
<James Munns> The way NAND flash works is that an erase brings all the bits back to 0xFF, and a "write" just smooshes the bits down to zero
<re_irc>
<Caleb Webber> is smoosh the technical term
<re_irc>
<James Munns> so if you erased, then wrote 0x3F, then wrote 0xF0, you'd have 0x30 (if you didn't erase in between
<re_irc>
<James Munns> Caleb Webber: Definitely, there's an ISO spec for it.
<re_irc>
<James Munns> usually there's some limit to the number of times you're able to re-write a word/page/sector without re-erasing, for example if you are writing a few bytes at a time for a running log
<re_irc>
<dirbaio> ah, the wonderful art of bitsmooshing
<re_irc>
<James Munns> bitsmooshmask
aspe has joined #rust-embedded
<re_irc>
<firefrommoonlight> Specifics, from H743 RM:
<re_irc>
> It is not recommended to overwrite a Flash word that is not virgin. The result may lead to an
<re_irc>
> inconsistent ECC code that will be systematically reported by the embedded Flash memory,
<re_irc>
> as described in Section 4.7.7: Error correction code error (SNECCERR/DBECCERR).
<re_irc>
<dirbaio> "<<" = left smoosh
<re_irc>
<James Munns> ohhh
<re_irc>
<firefrommoonlight> Preceded by
<re_irc>
> The virgin state of each non-volatile memory bitcell is 1. The embedded Flash memory
<re_irc>
> supports programming operations that can change (reset) any memory bitcell to 0. However
<re_irc>
> these operations do not support the return of a bit to its virgin state. In this case an erase
<re_irc>
> operation of the entire sector is required.
<XMPPwocky>
aww, there's ECC :(
<re_irc>
<James Munns> I wonder if that's why it's so slow
<re_irc>
<James Munns> ECC
<re_irc>
<dirbaio> stm32 flash is ... just slow
<re_irc>
<dirbaio> * slow. it's not ecc
<re_irc>
<firefrommoonlight> I wonder why this is why probe-run crashes on erase
<re_irc>
<dirbaio> ecc prevents you from writing to the same word multiple times yep
<re_irc>
<dirbaio> most stm32s don't have ecc though
<re_irc>
<dirbaio> h7 is the weird one
<re_irc>
<firefrommoonlight> I'm a fan of onboard flash for storing config data
<re_irc>
<firefrommoonlight> I guess depending on use, you can always go QSPI / memory-mapped
<re_irc>
<firefrommoonlight> Maybe faster?
<re_irc>
<firefrommoonlight> Is there a wya to do the onboard flash erase in a non-blocking way ? If not, offboard would have an advantage there
<re_irc>
<James Munns> I think that one has dual bank
<re_irc>
<James Munns> so you can run from one half while erasing or writing the other
<re_irc>
<James Munns> but you can't usually erase and program the same bank at the same time
<re_irc>
<dirbaio> you can avoid blocking if running from RAM, or if running from the other bank in dual-bank chips
aspe has quit [Client Quit]
<re_irc>
<James Munns> (nrf52840 only has a single bank for example, but they have a funny "only stall a little bit at a time" mode you can use)
<re_irc>
<James Munns> cooperative stalling?
<re_irc>
<firefrommoonlight> Oh taht makes sense. Also makes sense why you'd config an optionally-dual bank variant (Just G4 and L5?) as such
<re_irc>
<firefrommoonlight> From H7:
<re_irc>
> memory interface can drive different operations at the same time on each bank. For
<re_irc>
> write or erase operation is executed on bank 2
<re_irc>
> As the non-volatile memory is divided into two independent banks, the embedded Flash
<re_irc>
> example a read, write or erase operation can be executed on bank 1 while another read,
<re_irc>
<firefrommoonlight> Presumably the CPU can also do things during the erase or read?