Sender | Message | Time |
---|---|---|
10 Dec 2023 | ||
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 | |
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 | |
So 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 | |
0005801c <$d.2257>: 5801c: 60 be 02 20 .word 0x2002be60 58020: 25 80 05 00 .word 0x00058025 | 02:34:57 | |
If that's actually the culprit, it appears to be used in rtt_target::print::print_impl::write_str... | 02:35:28 | |
Hmm.. 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 | |
I assume lots of people are using rtt-target successfully with nightly beyond 2023-08-08... | 02:52:38 | |
(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 | |
In reply to @grantm11235:matrix.orguhhh how do i do this? i'm not good at assembly | 03:10:32 | |
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!
The connection to rtt-target was a red herring. I have the | 04:02:46 | |
* 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!
The connection to rtt-target was a red herring. I have the | 04:03:37 | |
Cool: so this insta-hardfaults anywhere I put it:
| 04:14:59 | |
Redacted or Malformed Event | 04:52:04 | |
07:57:11 | ||
08:03:23 | ||
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 interrupts? Any ideas on approach are also appreciated. | 08:46:19 | |
* 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 | |
Or should I be looking at the PAC level for this kind of thing | 08:58:03 | |
11:10:53 | ||
New PR: initial support for avr | 13:49:14 | |
In reply to @giugiaro:matrix.org 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 | |
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 | |
* 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 | |
In reply to @djdisodo:matrix.orga 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 | |
In reply to @djdisodo:matrix.org* 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 | |
* 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 | |
In reply to@cbruiz:matrix.orgThanks, 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 | |
New PR: stm32: usart pin inversion | 23:41:59 | |
23:49:50 | ||
PR merged: stm32: usart pin inversion | 23:53:54 |