Board based instantiation of chip drivers and interrupt mappings: Stm32f4

[hudson-ayers]

Pull Request Overview

This pull request ports the stm32f4xx, stm32f446re, stm32f412g, stm32f429zi chips and the boards that use them to the new peripheral instantiation approach that does not rely on global variables (first proposed in #2069).

This involved mostly the same changes as were required for the stm32f3xx chip, with some additional changes for handling DMA, because there is tons of duplicate code across those chips and boards. It would be nice if those chips and boards had an approach to code sharing more similar to that used by the nordic boards, but that would be a substantial refactor so not sure if its worth it for anyone to take that on.

This PR removes a ton of unsafe, which is nice. It also adds support for different stm chips to support different peripherals (in much the same way the nordic chips handle this) which should help for #2182 .

Testing Strategy

This pull request was tested by compiling. But there are enough changes in this PR that hardware testing would be appreciated.

TODO or Help Wanted

N/A

Documentation Updated

• No updates are required.

Formatting

• Ran make prepush.

[krady21]

Shouldn't uart still be a mutable reference?

[hudson-ayers]

It is now recreated as an owned type, which means it is still mutable.

[hudson-ayers]

Also, this particular use of UART is only for use by the panic handler

[krady21]

I was looking into io.rs because the panic handler doesn't seem to work either. I got this when I called panic!, so I thought that the problem might be related to usart. I couldn't seem to find anything wrong in the initialization procedure, the only thing different from before being the order in which setup_peripherals(), set_pin_primary_functions(), setup_dma() are called in the reset handler. I tried reordering them, but I got the same result.

[hudson-ayers]

hmm, that suggests that the usart speed might be wrong. Where were you calling panic!()? Was it panicking even when you did not call panic!()? Do normal console prints (debug!()) work?

[alexandruradovici]

I finally got the panic working, it seems to get stuck at this line

let gpio_ports = stm32f412g::gpio::GpioPorts::new(&rcc, &exti);

If loaded with apps, it fails in reset_handler at

let peripherals = static_init!(
        Stm32f412gDefaultPeripherals,
        Stm32f412gDefaultPeripherals::new(rcc, exti, dma1)
    );

It actually triggers a hard fault. Any ideas?

[hudson-ayers]

I assume you can't get the details of the hard fault because it panics too soon? Does whatever debugger you are using report any additional information about the type of fault?

When you say you got the panic working, what did you change to make it work?

I don't immediately have any ideas, as the constructor code is pretty simple. I am going to look into this more though. I'm really sorry this refactor broke things; for all the hardware I had the refactors simply worked, but I don't have an stm board and something must be different here.

[hudson-ayers]

Can you try doubling (or even tripling?) the stack size, and seeing if you still encounter the same issue? The stm32f4 chip has 6280 bytes of peripherals, which are now being lazily initialized. I suspect that because they are all being initialized in a single function call (within the static_init!() macro), that all 6280 bytes may be being allocated on the stack simultaneously as part of the initialization, thereby overflowing the stack.

If that is what is happening, it is probably a flaw with this design, and I should break the initialization into smaller pieces to avoid actually requiring a larger stack. But just increasing the stack size should be the quickest way to determine if that is in fact the issue. Generally, the kernel should report stack overflow errors as such, but I wonder if stack overflows this early in the initialization sequence lead to other issues with uninitialized peripherals.

[alexandruradovici]

Did it, this is the problem. Sent #2223