@benpicco Could you rebase this PR now that #12697 is merged?

@benpicco I've tried this PR on the board, examples/default works, but examples/timer_periodic_wakeup seems to be broken. If this is an indication for broken timers on the board it could also explain why the USB peripheral appears broken as it relies on xtimer in the initialization.

Copy & paste error…
I now copy & pasted the right xtimer configuration from common/nucleo/include/board_nucleo.h…

Now USB is also working!

There is a strange persistence issue though.
The firmware flashed using dfu-util only works until the first reset.

There are two explanations that come to mind

• The CPU is in a different state depending on whether the bootloader was doing DFU or not
• The firmware was never written to flash

I somehow suspect the latter because even when I add

void pre_startup(void)
{
    gpio_init(LED0_PIN, GPIO_OUT);
    LED0_ON;
}

(and disble _gpio_init_ain() in cpu/stm32_common/cpu_init.c) the LED will only light up for the first boot.

Turns out the bootloader doesn't require any ROM offset.
After flashing it would jump to the right address, but not after reset.

With ROM_OFFSET ?= 0x0 things also work after reset.

Looks like the DEFAULT_MODULE approach from #13146 got approved, so I'm adapting this here too.

Looks like the DEFAULT_MODULE approach from #13146 got approved,

Temporarily. In the long run we should find a solution in the remodeling of stdio that does not pull in unneeded dependencies (see #13460 and #13469).

Btw: I think I have one of these as well as the F401 variant. Feel free to ping me, if testing/reviewing is needed. However, I got rid of the bootloader as I just used the matching nucleo-f* board to flash RIOT on it. But now that stdio over USB works, using DFU rather than SWD got very attractive :-)

@maribu This should already be in a good state, the only thing I need to figure out is how to get rid of those USB ID warnings when using USB for stdio by default.

Btw: Care to add an MTD conf for the SPI Flash on the un-populated U3 footprint on the back? (The modules should still be pulled in manually, as the user would have to solder in the flash. But having the config in place would be a super nice addition.)

Care to add an MTD conf for the SPI Flash on the un-populated U3 footprint on the back?

Added them.

Unfortunately RIOT doesn't detect the chip size automatically yet based on the JDEC ID, but that shouldn't be too hard to fix.

I took the timing of the AT25SF041 which was in stock at Segor, but since those are lower bounds, any flash should work. (IMHO we should just use sensible defaults if entries in mtd_spi_nor_params_t are 0 - those SPI Flashes are made interchangeable, you should be able to just drop in any old flash chip and query the parameters at run-time)

• PWM (Tested only PA15 using tests/periph_pwm. It seems the duty cycle is inverted

I think that's more a problem with the STM32 PWM driver than with the board config

Rebased to the stm32 merge.

As for SPI, I used this to test the nrf24l01p_ng driver with this config:

#define NRF24L01P_NG_PARAM_SPI      SPI_DEV(1)
#define NRF24L01P_NG_PARAM_CS       GPIO_PIN(PORT_B, 12)
#define NRF24L01P_NG_PARAM_CE       GPIO_PIN(PORT_A, 8)
#define NRF24L01P_NG_PARAM_IRQ      GPIO_PIN(PORT_A, 9)

Updated testing state:

• Flashing via dfu-util
• stdio via USB
• LED / button definitions
• RTC conf
• ADC conf
• i2c conf
• [-] PWM (Duty cycle inverted, bug in driver needs to be fix. But out of scope of this PR)
• SPI config (Tested all three devices with a logic analyzer)
• UART config
  • UART 0
  • UART 1
  • UART 2 (strange output on logic analyzer, device locks up. Tested using tests/periph_uart with a symbol rate of 9600 baud.)

If you want this in swiftly, you could drop the UART 2 config. (Can still be added and fixed later on.)

UART is strange, I just copied that from nucleo-f411re.
Dropped it for now.

UART is strange, I just copied that from nucleo-f411re.

I sadly have none of these to check there as well. I can run a second round of testing for it later on the WeAct to rule out a flanky test setup and human error. But let's get this is first; this will make my life easier when testing the bootloader_stm32 :-)

@maribu I have a branch for the F401 board too, but it sounds like you've also already flashed RIOT onto it.

Mine will get stuck if I enable the 25 MHz HSE oscillator and I can't get into the DFU bootloader - maybe this is related and it's just a case of broken hardware.

CDC ACM works fine using the HSI oscillator, so I'm not so sure - why would the bootloader rely on HSE then?

I was able to run

make BOARD=weact-f401cc -C examples/default flash
make BOARD=weact-f401cc -C examples/default term

20-06-06 06:48:54,467 # main(): This is RIOT! (Version: 2014.01-27214-g600cf-boards/wefun-f401cc)
2020-06-06 06:48:54,468 # Welcome to RIOT!

Some preliminary testing was successful. Note: A button is exposed with SAUL, but it is not present on the WeAct V1.2; there is only the NRST button and the BOOT0 button. It seemingly was only added to the WeAct V1.3.

Mine will get stuck if I enable the 25 MHz HSE oscillator

That is typical behavior if the crystal is not properly connected. RIOT loops until the clock becomes stable, which never happens in case of hardware issues.

Here is the schematic of the board. You should check the solder connects of pin 5 and 6 of the STM32F401, the crystal (it is labeled 25.000 MHz, so it is easy to find) and the capacitors C3 and C4 (those should be the two left of the crystal). I guess if you just shortly reheat the solder there with a thin solder tip, the board will start to boot :-)

Some preliminary testing was successful.

With this configuration it also works for me, but that is not using the 25 MHz oscillator.
Does it still work if you do

diff --git a/boards/weact-f401cc/include/periph_conf.h b/boards/weact-f401cc/include/periph_conf.h
index 867c737937..81a72fe0c7 100644
--- a/boards/weact-f401cc/include/periph_conf.h
+++ b/boards/weact-f401cc/include/periph_conf.h
@@ -23,8 +23,8 @@
 #define PERIPH_CONF_H
 
 #include "periph_cpu.h"
-#include "f4/cfg_clock_84_0_1.h"
-// #include "f4/cfg_clock_84_25_1.h"
+//#include "f4/cfg_clock_84_0_1.h"
+#include "f4/cfg_clock_84_25_1.h"
 #include "cfg_i2c1_pb8_pb9.h"
 #include "cfg_timer_tim5.h"
 #include "cfg_usb_otg_fs.h"

Note: A button is exposed with SAUL, but it is not present on the WeAct V1.2; there is only the NRST button and the BOOT0 button. It seemingly was only added to the WeAct V1.3.

Yea I just copied the f411ce board, mine doesn't have a button either.
But looks like they arrived at V3.0 now and always include a button.

I guess if you just shortly reheat the solder there with a thin solder tip, the board will start to boot :-)

No luck so far, but I'll keep trying :)

Does it still work if you do

yep :-) I guess you just have bad luck.