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.)

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."

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

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.

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.

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

let _ = format!("HardFault: {:?}", None::<usize>);

New PR: initial support for avr

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

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

In reply to @djdisodo:matrix.org
uhhh how do i do this? i'm not good at assembly

In reply to @djdisodo:matrix.org
uhhh how do i do this? i'm not good at assembly

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

New PR: stm32: usart pin inversion

PR merged: stm32: usart pin inversion