!YoLPkieCYHGzdjUhOK:matrix.org

Embassy

856 Members
Welcome to the Embassy matrix channel! -- Next-gen async embedded Rust framework -- https://embassy.dev -- https://github.com/embassy-rs/embassy69 Servers

Load older messages


SenderMessageTime
10 Dec 2023
@peter9477:matrix.orgPeter Hansen
  1. read 0xE000ED28
    0xe000ed28 = 0x00020000

That apparently means there was an INVSTATE condition, possibly from some assembly that didn't set bit 0 of some instruction in thumb mode. (I don't have any custom assembly in here, so that could be a compiler bug I guess, if this means anything.)

02:24:13
@peter9477:matrix.orgPeter Hansen
  1. read 0xE000ED2C
    0xe000ed2c = 0x40000000

This bit in the HFSR says "FORCED - This means a configurable fault (i.e. the fault types we discussed in previous sections) was escalated to a HardFault, either because the configurable fault handler was not enabled or a fault occurred within the handler."

02:25:52
@peter9477:matrix.orgPeter HansenSo apparently the stack frame is probably r0, r1, r2, r3, r12, LR, PC, and xPSR, meaning LR=0x5606d and PC=0x58020... which seems impossible as 58020 is more .rodata, not code. Unless some of the .rodata can actually be code (like a jump table?).02:32:39
@peter9477:matrix.orgPeter Hansen0005801c <$d.2257>: 5801c: 60 be 02 20 .word 0x2002be60 58020: 25 80 05 00 .word 0x00058025 02:34:57
@peter9477:matrix.orgPeter HansenIf that's actually the culprit, it appears to be used in rtt_target::print::print_impl::write_str... 02:35:28
@peter9477:matrix.orgPeter HansenHmm.. building in release mode works, possibly because it eliminates use of rtt-target. I'm using rtt-target 0.3.1 still, but crates.io shows a 0.4.0 yet the repo doesn't have that tagged. Migrating to 0.4.0 doesn't fix it, but taking out just the rprintln!() calls appears to completely avoid the issue.02:52:15
@peter9477:matrix.orgPeter HansenI assume lots of people are using rtt-target successfully with nightly beyond 2023-08-08... 02:52:38
@peter9477:matrix.orgPeter Hansen(Or maybe pretty much everyone uses defmt, so if it doesn't use rtt-target then that might explain why I'm seeing this and possibly nobody else has.)03:01:52
@djdisodo:matrix.orgdjdisodo
In reply to @grantm11235:matrix.org
You might need to use asm to read the stack pointer. I wouldn't trust the address of an unused stack variable, I think the compiler might do weird things
uhhh how do i do this? i'm not good at assembly
03:10:32
@peter9477:matrix.orgPeter Hansen

Wow, really freaky conclusion here. The HardFault issue seems to be tied into using the Debug format on an Option<usize> when it's None. Not sure yet if it matters that it's usize. Works when it's a Some, though. Here's a set of working/failing lines. The original one that was causing this failure is listed first. At the end I have my work-alike replacement that works around the issue by not allowing None to be passed to the "{:?}" for formatting!

        // this HardFaults if start is None:
        // debug!("found {} at {:?}, {:?}", meta.name, start, index);

        // this HardFaults:
        // let start: Option<usize> = None;
        // debug!("this fails {:?}", start);

        let start: Option<usize> = Some(23);
        debug!("this works {:?}", start);

        // start: Option<usize>
        // index: usize
        debug!("found {} at {}, {:?}", meta.name,
            match start {
                None => "None".into(),
                x => format!("{:?}", x),
            },
            index);

The connection to rtt-target was a red herring. I have the log crate set up to use rtt-target for the output, that's all. Given that the issue started with nightlies after 08-08 I think this might be right in the standard lib (alloc::format) or still possibly even a compiler issue.

04:02:46
@peter9477:matrix.orgPeter Hansen *

Wow, really freaky conclusion here. The HardFault issue seems to be tied into using the Debug format on an Option<usize> when it's None. Not sure yet if it matters that it's usize. Works when it's a Some, though. Here's a set of working/failing lines. The original one that was causing this failure is listed first. At the end I have my work-alike replacement that works around the issue by not allowing None to be passed to the "{:?}" for formatting!

        // this HardFaults if start is None:
        // debug!("found {} at {:?}, {:?}", meta.name, start, index);

        // this HardFaults:
        // let start: Option<usize> = None;
        // debug!("this fails {:?}", start);

        let start: Option<usize> = Some(23);
        debug!("this works {:?}", start);

        // Workaround that does not HardFault:
        // start: Option<usize>
        // index: usize
        debug!("found {} at {}, {:?}", meta.name,
            match start {
                None => "None".into(),
                x => format!("{:?}", x),
            },
            index);

The connection to rtt-target was a red herring. I have the log crate set up to use rtt-target for the output, that's all. Given that the issue started with nightlies after 08-08 I think this might be right in the standard lib (alloc::format) or still possibly even a compiler issue.

04:03:37
@peter9477:matrix.orgPeter Hansen

Cool: so this insta-hardfaults anywhere I put it:

let _ = format!("HardFault: {:?}", None::<usize>);
04:14:59
@djdisodo:matrix.orgdjdisodoRedacted or Malformed Event04:52:04
@cschuhen:matrix.orgCorey Schuhen joined the room.07:57:11
@giugiaro:matrix.orgGeoffrey Smith joined the room.08:03:23
@giugiaro:matrix.orgGeoffrey SmithI'm fairly new to embedded and working on writing a display driver on an STM32U5 - the display requires around a 750 kHz base clock signal with 6 parallel data lines that go high or low on each tick and a variety of horizontal/vertical control signals. It seems that embassy-stm32 has the best implementation of the U5 HAL in Rust at the moment. My plan is to prototype a version without DMA or optimizations first just using timer interrupts. So far I've only found examples using peripherals like SPI - can anyone point me towards some help on running custom functions to bit bang pins on interrupts? Any ideas on approach are also appreciated.08:46:19
@giugiaro:matrix.orgGeoffrey Smith* I'm fairly new to embedded and working on writing a display driver on an STM32U5 - the display requires around a 750 kHz base clock signal with 6 parallel data lines that go high or low on each tick and a variety of horizontal/vertical control signals. It seems that embassy-stm32 has the best implementation of the U5 HAL in Rust at the moment. My plan is to prototype a version without DMA or optimizations first just using timer interrupts. So far I've only found examples using peripherals like SPI - can anyone point me towards some help on running custom functions to bit bang pins on each timer interrupt? Any ideas on approach are also appreciated.08:46:57
@giugiaro:matrix.orgGeoffrey SmithOr should I be looking at the PAC level for this kind of thing08:58:03
@geojetta:matrix.orggeojetta joined the room.11:10:53
@embassy-bot:matrix.orgbender

New PR: initial support for avr

13:49:14
@sethiam:matrix.orgsethiam
In reply to @giugiaro:matrix.org
Or should I be looking at the PAC level for this kind of thing

This could be a helpful crate: https://crates.io/crates/shift-register-driver

I'd leaf through the selection on the awesome embedded rust page, though. There's a lot there if you take some time to really look through it

17:41:18
@cbruiz:matrix.orgcbruiz

I’m trying to write a firmware and first thing I did was to explore each single problem to face and alternatives/caveats of each one. Display was not one of my primary goals, but that one is the first and happier, without any doubt 😂.

I don’t know about the mb1835 display that board seems to integrate, but worked with two ili9341; one parallel d8 and another with spi. Both worked fine with embassy and the proper crate. Maybe you can have a look at the ili9341 crate because it could be similiar (I guess). Problem is that it seems not be any async graphics library/backend, which is pretty needful if you want or need to leverage DMA

18:59:13
@cbruiz:matrix.orgcbruiz * I’m trying to write a firmware and first thing I did was to explore each single problem to face and alternatives/caveats of each one. Display was not one of my primary goals, but that one you have now is the first and happier, without any doubt 😂.
I don’t know about the mb1835 display that board seems to integrate, but worked with two ili9341; one parallel d8 and another with spi. Both worked fine with embassy and the proper crate. Maybe you can have a look at the ili9341 crate because it could be similiar (I guess). Problem is that it seems not be any async graphics library/backend, which is pretty needful if you want or need to leverage DMA
19:00:01
@vollbrecht:matrix.orgvollbrecht
In reply to @djdisodo:matrix.org
uhhh how do i do this? i'm not good at assembly
a good think to start is to get familiar with this. Are you in general aware how the architecture works, do you now about status register and the general layout of some default registers that are used?
19:16:39
@vollbrecht:matrix.orgvollbrecht
In reply to @djdisodo:matrix.org
uhhh how do i do this? i'm not good at assembly
* a good place to start is to get familiar with this. Are you in general aware how the architecture works, do you now about status register and the general layout of some default registers that are used?
19:19:43
@vollbrecht:matrix.orgvollbrecht * a good place to start is to get familiar with this. Are you in general aware how the architecture works, do you know about status register and the general layout of some default registers that are used? 19:31:23
@giugiaro:matrix.orgGeoffrey Smith
In reply to@cbruiz:matrix.org
I’m trying to write a firmware and first thing I did was to explore each single problem to face and alternatives/caveats of each one. Display was not one of my primary goals, but that one you have now is the first and happier, without any doubt 😂.
I don’t know about the mb1835 display that board seems to integrate, but worked with two ili9341; one parallel d8 and another with spi. Both worked fine with embassy and the proper crate. Maybe you can have a look at the ili9341 crate because it could be similiar (I guess). Problem is that it seems not be any async graphics library/backend, which is pretty needful if you want or need to leverage DMA
Thanks, appreciate the tips and the ili9341 crate and datasheet definitely do help on higher level approach. This display (Sharp LS021B7DD02, 64-color version of their monochrome stuff) is a little unique because there don't seem to be display drivers that use the signal format needed for the 6bpp configuration. Other products have used an FPGA which would be a better call eventually, but I think I can probably hack something together on the MCU for now which won't be efficient but at least proves the concept because of the lowish bitrate needed. Will keep tinkering.
23:32:01
@embassy-bot:matrix.orgbender

New PR: stm32: usart pin inversion

23:41:59
@lights0123:matrix.orglights0123 joined the room.23:49:50
@embassy-bot:matrix.orgbender

PR merged: stm32: usart pin inversion

23:53:54

There are no newer messages yet.


Back to Room ListRoom Version: 6