[STM32F401CE] debugging a new board definition [solved]

Discussion and questions about boards that can run MicroPython but don't have a dedicated forum.
Target audience: Everyone interested in running MicroPython on other hardware.
User avatar
jgriessen
Posts: 191
Joined: Mon Sep 29, 2014 4:20 pm
Contact:

[STM32F401CE] debugging a new board definition [solved]

Post by jgriessen » Sat Mar 31, 2018 1:17 am

When I compile I get these errors:

In file included from led.c:34:0:
build-PYFLEX_F401/genhdr/pins.h:26:19: error: ISO C99 requires whitespace after the macro name [-Werror]
#define pyb_pin_J1-7 pin_A5
^
build-PYFLEX_F401/genhdr/pins.h:27:19: error: ISO C99 requires whitespace after the macro name [-Werror]
#define pyb_pin_J1-8 pin_A4


The names in pins.csv look like this:

J1-1,VSS
J1-2,VSS
#J1-3,18V_ONBOARD
#J1-4,18V_ONBOARD
J1-5,VSS
J1-6,VSS
J1-7,PA5
J1-8,PA4

Ideas what's going wrong?
Last edited by jgriessen on Thu Apr 26, 2018 7:27 pm, edited 1 time in total.
John Griessen blog.kitmatic.com

efahl
Posts: 15
Joined: Sat Dec 23, 2017 2:02 pm

Re: [STM32F401CE] debugging a new board definition

Post by efahl » Sat Mar 31, 2018 4:14 pm

You can't use a '-' in the macro name, it's a C operator. Changing them to underscore should work.

User avatar
jgriessen
Posts: 191
Joined: Mon Sep 29, 2014 4:20 pm
Contact:

Re: [STM32F401CE] debugging a new board definition

Post by jgriessen » Tue Apr 03, 2018 5:10 pm

I have gone over my names in pins.csv, making it a map from datasheet pin names to my module names.

I get an error related to mpconfigboard.h now:

Code: Select all

arm-none-eabi-gcc -I. -I../.. -Ibuild-PYFLEX_F401 -I../../lib/cmsis/inc -I../../lib/stm32lib/CMSIS/STM32F4xx/Include/ -I../../lib/stm32lib/STM32F4xx_HAL_Driver/Inc -Iusbdev/core/inc -Iusbdev/class/inc -Wall -Wpointer-arith -Werror -std=gnu99 -nostdlib -DFFCONF_H=\"lib/oofatfs/ffconf.h\"  -DSTM32F401xE -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mtune=cortex-m4 -mcpu=cortex-m4 -DMCU_SERIES_F4 -Os -DNDEBUG -Iboards/PYFLEX_F401 -DSTM32_HAL_H='<stm32f4xx_hal.h>' -DMICROPY_FLOAT_IMPL=MICROPY_FLOAT_IMPL_FLOAT -fsingle-precision-constant -Wdouble-promotion -fdata-sections -ffunction-sections -DMICROPY_QSTR_EXTRA_POOL=mp_qstr_frozen_const_pool -DMICROPY_MODULE_FROZEN_MPY -c -MD -o build-PYFLEX_F401/usrsw.o usrsw.c
In file included from ./mpconfigport.h:31:0,
                 from ../../py/mpconfig.h:45,
                 from ../../py/mpstate.h:31,
                 from ../../py/runtime.h:29,
                 from usrsw.c:29:
usrsw.c: In function 'switch_init0':
boards/PYFLEX_F401/mpconfigboard.h:59:38: error: 'pin_B10' undeclared (first use in this function)
 #define MICROPY_HW_USRSW_PIN        (pin_B10)
                                      ^
I also get errors for these pins before commenting them out:
// #define MICROPY_HW_SPI2_SCK (pin_B13)
// #define MICROPY_HW_SPI2_MISO (pin_B14)
// #define MICROPY_HW_SPI2_MOSI (pin_B15)

Not sure where to look next. Pins B10, B13, B14, B15 are all in the datasheet...

These were enabled:
#define MICROPY_HW_HAS_SWITCH (1)
#define MICROPY_HW_HAS_FLASH (1)
#define MICROPY_HW_ENABLE_RTC (1)
#define MICROPY_HW_ENABLE_TIMER (1)

The rest were (0).

#define MICROPY_HW_ENABLE_TIMER (1) was not included for NUCLEO_F401RE platform. Why is that?

Meanwhile, I have disabled MICROPY_HW_HAS_SWITCH and testing that way shows not normal USB port functions,
so looking into REPL on serial port as way forward. DFU worked. That says USB port physically works, and two-ways.
John Griessen blog.kitmatic.com

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: [STM32F401CE] debugging a new board definition

Post by dhylands » Tue Apr 03, 2018 8:52 pm

Since you have

Code: Select all

#define MICROPY_HW_USRSW_PIN        (pin_B10)
in your mpconfig.h file, you also need to ensure that pin B10 is in your generated build-BOARDNAME/pins_BOARDNAME.c file, which means that it needs to be in your pins.csv file.

The usual convention is to call is SW. You should similarly have B13, etc in your pins.csv file. Something like:

Code: Select all

SPI2_SCK,B13
SPI2_MISO,B14
SPI2_MOSI,B15
The actual pin names (i.e. the SPI2_MOSI portion) don't really matter, but they have to be present or there won't be a pin generated.

The pins_BOARDNAME.c file only includes the pins mentioned in pins.csv and not all of the possible pins in order to reduce the amount of flash consumed.

User avatar
jgriessen
Posts: 191
Joined: Mon Sep 29, 2014 4:20 pm
Contact:

Re: [STM32F401CE] debugging a new board definition

Post by jgriessen » Tue Apr 03, 2018 9:19 pm

it needs to be in your pins.csv file.
Oh, thanks Dave.
Control-C doesn't work on a serial REPL, you'll want to make sure that you boot to the REPL. You'll also need to use the --buffer-size=32 option.
Ah so. I'll fix the pins.csv file, then try boot to serial port via my FT2232HQ connected to PA2, PA3. That will keep me busy for a while.
On second thought, I'm reading about frozen compilation as a way to load micropython and platform code like I seem to have done, and modules that will verify pins are defined and application code runs. then figure why the REPL over USB is not working.

Any other ideas why DFU works, but lsusb shows no STM device, and no virtual filesystem and rshell finds no micropython to talk to on the USB?
John Griessen blog.kitmatic.com

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: [STM32F401CE] debugging a new board definition

Post by dhylands » Wed Apr 04, 2018 12:20 am

Does your HSE_VALUE found in stm32f4xx_hal_conf.h match the value of the crystal that you're using?

If you changed the HSE_VALUE (from whatever board file you used as a template), did you also change the MICROPY_HW_CLK_PLLx constants (found in mpconfigboard.h) to give 48 MHz output for the USB clock?

I generally find another board with the same crystal and copy the 4 values from that mpconfigboard.h file. If there isn't one, then I sit down and fill in the values according to the constraints given in the RCC_PLLCFGR register.

There is a little set of formulas at the top, and each of the 4 fields in the register (PLLQ, PLLP, PLLN, PLLM) shows the contraints.

User avatar
jgriessen
Posts: 191
Joined: Mon Sep 29, 2014 4:20 pm
Contact:

Re: [STM32F401CE] debugging a new board definition

Post by jgriessen » Wed Apr 04, 2018 1:24 pm

I used the cubemx tool to get the four values. My HSE 16MHz crystal is running confirmed by light loading active probe directly on the OSC_OUT_PH1 pin.

cubemx showed all the constraints satisfied: https://www.cibolo.com/docs/STM32cubemx-clocks.png

excerpt from mpconfigboard.h
// HSE is 16MHz - F401 does 84 MHz max
#define MICROPY_HW_CLK_PLLM (16)
#define MICROPY_HW_CLK_PLLN (336)
#define MICROPY_HW_CLK_PLLP (RCC_PLLP_DIV4)
#define MICROPY_HW_CLK_PLLQ (7)

From STM32F4xD/E ref manual, here are the constraints for double checking cubemx:

RCC PLL configuration register (RCC_PLLCFGR) This register is used to configure the PLL clock outputs according to the formulas:

• f (VCO clock) = f (PLL clock input) × (PLLN / PLLM) ================================> [ = 16 * 336 / 16 = 336]
• f (PLL general clock output) = f (VCO clock) / PLLP ================================> [ = 336 / 4 = 84]
• f (USB OTG FS, SDIO, RNG clock output) = f (VCO clock) / PLLQ =======================> [ = 336 / 7 = 48]
USB OTG FS clock frequency = VCO frequency / PLLQ with 2 ≤ PLLQ ≤ 15

So all constraints are satisfied in this calculation also.

The only thing not checked twice is define MICROPY_HW_CLK_PLLP (RCC_PLLP_DIV4)
Why not enter 4 instead of RCC_PLLP_DIV4 as in other platforms? Where does RCC_PLLP_DIV4 get defined?
John Griessen blog.kitmatic.com

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: [STM32F401CE] debugging a new board definition

Post by dhylands » Wed Apr 04, 2018 5:14 pm

RCC_PLLP_DIV4 comes from the HAL. It appears to be set to 4 for all of the platforms we're currently using.

Why this is used instead of just 4 is probably historical. It's possible that at some point in time it didn't have the value 4 (i.e. it may have held the bitmask used instead of the value).

What do you have MICROPY_HW_CLK_LAST_FREQ set to? Try setting it to zero. Setting it to 1 seems to cause the frequency to come from the RTC (just based on a quick perusal of system_stm32.c)

Otherwise, your values look reasonable to me.

What does pyb.freq() output?

User avatar
jgriessen
Posts: 191
Joined: Mon Sep 29, 2014 4:20 pm
Contact:

Re: [STM32F401CE] debugging a new board definition

Post by jgriessen » Thu Apr 05, 2018 4:00 pm

What does pyb.freq() output?
I don't have a REPL on this new hardware.

DFU seems to work, but then no USB communication.

I just redid a compile with frozen code and deploy-stlink. script below:

Code: Select all

#!/bin/bash
# make_with_frozen_PYFLEX_F401.sh

echo Building for $BOARD

export FROZEN_DIR="/home/john/Documents/EEProjects/circuitboards/culture_shock/code_PYFLEX_F401/frozen"

if [ $BOARD ]
then
    cd /home/john/micropython/ports/stm32
    if [ $1 == "--clean" ]
    then
        make BOARD=$BOARD clean
        exit
    fi
    if make -j 2 BOARD=$BOARD FROZEN_MPY_DIR=$FROZEN_DIR
    then
        sleep 1
        make BOARD=$BOARD deploy-stlink
        cd -
#        sleep 1
#        rshell
    else
        echo Build failure
    fi
else
    echo "Wrong board type."
fi
I got this output which seems good for loading since it says verified:

Code: Select all

./make_with_frozen_PYFLEX_F401.sh 
Building for PYFLEX_F401
./make_with_frozen_PYFLEX_F401.sh: line 11: [: ==: unary operator expected
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Generating build-PYFLEX_F401/genhdr/mpversion.h
CC ../../py/modsys.c
CC ../../py/../extmod/modwebrepl.c
CC ../../lib/utils/pyexec.c
CC moduos.c
LINK build-PYFLEX_F401/firmware.elf
   text	   data	    bss	    dec	    hex	filename
 297048	     28	  44000	 341076	  53454	build-PYFLEX_F401/firmware.elf
Create build-PYFLEX_F401/firmware.dfu
Create build-PYFLEX_F401/firmware.hex
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Writing build-PYFLEX_F401/firmware0.bin to the board via ST-LINK
st-flash 1.4.0-25-ge9fe4e5
2018-04-05T10:37:32 INFO common.c: Loading device parameters....
2018-04-05T10:37:32 INFO common.c: Device connected is: F4 device (Dynamic Efficency), id 0x10006433
2018-04-05T10:37:32 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x80000 bytes (512 KiB) in pages of 16384 bytes
2018-04-05T10:37:32 INFO common.c: Attempting to write 14868 (0x3a14) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2018-04-05T10:37:32 INFO common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2018-04-05T10:37:32 INFO common.c: Starting Flash write for F2/F4/L4
2018-04-05T10:37:32 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 14868
2018-04-05T10:37:33 INFO common.c: Starting verification of write complete
2018-04-05T10:37:33 INFO common.c: Flash written and verified! jolly good!
Writing build-PYFLEX_F401/firmware1.bin to the board via ST-LINK
st-flash 1.4.0-25-ge9fe4e5
2018-04-05T10:37:33 INFO common.c: Loading device parameters....
2018-04-05T10:37:33 INFO common.c: Device connected is: F4 device (Dynamic Efficency), id 0x10006433
2018-04-05T10:37:33 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x80000 bytes (512 KiB) in pages of 16384 bytes
2018-04-05T10:37:33 INFO common.c: Attempting to write 282208 (0x44e60) bytes to stm32 address: 134348800 (0x8020000)
Flash page at addr: 0x08060000 erasedEraseFlash - Sector:0x7 Size:0x20000 
2018-04-05T10:37:36 INFO common.c: Finished erasing 3 pages of 131072 (0x20000) bytes
2018-04-05T10:37:36 INFO common.c: Starting Flash write for F2/F4/L4
2018-04-05T10:37:36 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 20064
2018-04-05T10:37:40 INFO common.c: Starting verification of write complete
2018-04-05T10:37:42 INFO common.c: Flash written and verified! jolly good!
/home/john/Documents/EEProjects/circuitboards/culture_shock/code_PYFLEX_F401

After this flash loading and reset the MCU did not seem to run my simple debug program.
Since the first code I loaded to this STM32F401CE via openocd via stlinkV2.1 the PB8 pin has been going hi for 4 secs lo for 4 secs.
Loading the new code which should have had PB8 and PB9 flashing .25 secs out of every 1 second did not change this.
Summary: USB port does not work (no REPL over USB). SWD pins seem to work checked by openocd program via SWD pins.
Even though openocd claims verified load, behavior does not change.

My frozen directory python files are below, and no others:

frozen/boot.py

Code: Select all

# boot.py -- run on boot-up

import machine
import pyb
pyb.freq(84000000)
pyb.main('pintest.py')
frozen/pintest.py

Code: Select all

import pyb
from pyb import Timer
import micropython
import stm

micropython.alloc_emergency_exception_buf(100)

# Use with pyb.freq(84000000) and prescaler=20 for .25 usec timer ticks.
xfmr_pulse_period = 4000000   # = (usec * 4)   700ms
xfmr_pulse_w = 900000          # = (usec * 4)  225ms
pos_pulse_total = 0
pos_pulse_burstlen = 50007
neg_pulse_total = 0
neg_pulse_burstlen = 50007

# Timer 2 to give .25 usec timer ticks counting up:
t2 = pyb.Timer(2, prescaler=20, period=xfmr_pulse_period, mode=Timer.UP)

# xfmr pulse half_cycle timing.     (OC rollover callback)
# JP27 output and interrrupt.  Compare generates interrupt:
t2ch3 = t2.channel(3, pyb.Timer.OC_TOGGLE, compare=xfmr_pulse_period,
                   polarity=pyb.Timer.HIGH, pin=pyb.Pin.board.LED_GREEN)
t2ch2 = t2.channel(2, pyb.Timer.OC_TOGGLE, compare=xfmr_pulse_period,
                   polarity=pyb.Timer.HIGH, pin=pyb.Pin.board.LED_YELLOW)

# Define already set up pins so they can be read with a pin reference like:  pin8.value() on the fly.
pin8 = pyb.Pin.board.LED_GREEN
pin9 = pyb.Pin.board.LED_YELLOW
# Define pins so they can be set with a pin reference like:  pin10.value(1) on the fly.
pinB10 = pyb.Pin('PB10', pyb.Pin.OUT_PP)
pinB13 = pyb.Pin('PB13', pyb.Pin.OUT_PP)
pinB14 = pyb.Pin('PB14', pyb.Pin.OUT_PP)
pinB15 = pyb.Pin('PB15', pyb.Pin.OUT_PP)

for i in range(30):
    pinB10.value(1)  
    time.sleep(1.0)
    pinB10.value(0)
    pinB13.value(1)
    time.sleep(1.0)
    pinB13.value(0)
    pinB14.value(1)
    time.sleep(1.0)
    pinB14.value(0)
    pinB15.value(1)
    time.sleep(1.0)
    pinB15.value(0)
    pinB3.value(1)
    time.sleep(1.0)
    pinB3.value(0)
    pinB4.value(1)
    time.sleep(1.0)
    pinB4.value(0)
    pinB5.value(1)
    time.sleep(1.0)
    pinB5.value(0)
    pinB6.value(1)
    time.sleep(1.0)
    pinB6.value(0)
    pinB7.value(1)
    time.sleep(1.0)
    pinB7.value(0)
Last edited by jgriessen on Thu Apr 05, 2018 4:11 pm, edited 1 time in total.
John Griessen blog.kitmatic.com

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: [STM32F401CE] debugging a new board definition

Post by dhylands » Thu Apr 05, 2018 4:05 pm

Not sure if this is relevant or not, but you've got an error in your build script:

Code: Select all

./make_with_frozen_PYFLEX_F401.sh: line 11: [: ==: unary operator expected

Post Reply