[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:

Re: [STM32F401CE] debugging a new board definition

Post by jgriessen » Wed Apr 11, 2018 2:42 pm

Something must be wrong with my compilation. I could compile minibliink with libopencm3 to get GPIOs toggling.
with micropython compile, PB8 is low as soon as programming is done, so my LED is on, but not flashing as in my test program.
The reset button makes PB8 go hiZ and return to low in about 100 msec after button release. Seems too fast for micropython bootup.
Something seems to be stopping micropython bootup. I'm going to try my newly git cloned micropython repo compiling for G30TH now and make sure that still works by flashing from DFU mode.
John Griessen blog.kitmatic.com

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 11, 2018 11:09 pm

There is something wrong, but maybe just with my test pins python program. I've gone back to using v1.9.3 micropython
and can get a REPL on my known good G30TH, but this program will not toggle GPIOs:

Code: Select all

# boot.py -- run on boot-up
# can run arbitrary Python, but best to keep it minimal

import machine
import pyb
pyb.main('pintest.py')
My testpins program doesn't use pyb.LED(2) or pyb.LED(1)
because I have two different platforms with one pin on one of them definitely shorted to VDD, so I want to test 10 or so pins, not just standard LED pins.

Code: Select all

import pyb
import micropython

# Define pins so they can be set with a pin reference like:  pin10.value(1) on the fly.
pinA5 = pyb.Pin('PA5', pyb.Pin.OUT_PP)
pinB0 = pyb.Pin('PB0', pyb.Pin.OUT_PP)
pinB1 = pyb.Pin('PB1', pyb.Pin.OUT_PP)
pinB2 = pyb.Pin('PB2', pyb.Pin.OUT_PP)
pinB3 = pyb.Pin('PB3', pyb.Pin.OUT_PP)
pinB4 = pyb.Pin('PB4', pyb.Pin.OUT_PP)
pinB5 = pyb.Pin('PB5', pyb.Pin.OUT_PP)
pinB6 = pyb.Pin('PB6', pyb.Pin.OUT_PP)
pinB7 = pyb.Pin('PB7', pyb.Pin.OUT_PP)
pinB8 = pyb.Pin('PB8', pyb.Pin.OUT_PP)
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)


pinA5.value(1)
pinB5.value(0)
while True:
    pinA5.toggle()
    pinB5.toggle()
    pinB0.toggle()
    pinB1.toggle()
    pinB8.toggle()
    pyb.delay(200)
John Griessen blog.kitmatic.com

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

Re: [STM32F401CE] debugging a new board definition

Post by dhylands » Mon Apr 16, 2018 8:22 pm

I've updated the G30TH board definition to work on the latest micropython master.

In addition to the other changes discussed in this thread, I also noticed that you now need to add:

Code: Select all

#define MICROPY_HW_ENABLE_USB       (1)
and

Code: Select all

#define MICROPY_HW_USB_FS              (1)
in order to get USB working.

I was able to apply the following patch to ports/stm32/main.c and confirmed that using a frozen boot.py and main.py also works fine.

Code: Select all

diff --git a/ports/stm32/main.c b/ports/stm32/main.c
index fb3e843..0c429b9 100644
--- a/ports/stm32/main.c
+++ b/ports/stm32/main.c
@@ -593,6 +593,16 @@ soft_reset:
     // TODO perhaps have pyb.reboot([bootpy]) function to soft-reboot and execute custom boot.py
     if (reset_mode == 1 || reset_mode == 3) {
         const char *boot_py = "boot.py";
+#define USE_FROZEN_BOOT_AND_MAIN 1
+#if USE_FROZEN_BOOT_AND_MAIN
+        int ret = pyexec_frozen_module(boot_py);
+        if (ret & PYEXEC_FORCED_EXIT) {
+            goto soft_reset_exit;
+        }
+        if (!ret) {
+            flash_error(4);
+        }
+#else
         mp_import_stat_t stat = mp_import_stat(boot_py);
         if (stat == MP_IMPORT_STAT_FILE) {
             int ret = pyexec_file(boot_py);
@@ -603,6 +613,7 @@ soft_reset:
                 flash_error(4);
             }
         }
+#endif
     }
 
     // turn boot-up LEDs off
@@ -656,6 +667,15 @@ soft_reset:
         } else {
             main_py = mp_obj_str_get_str(MP_STATE_PORT(pyb_config_main));
         }
+#if USE_FROZEN_BOOT_AND_MAIN
+        int ret = pyexec_frozen_module(main_py);
+        if (ret & PYEXEC_FORCED_EXIT) {
+            goto soft_reset_exit;
+        }
+        if (!ret) {
+            flash_error(3);
+        }
+#else
         mp_import_stat_t stat = mp_import_stat(main_py);
         if (stat == MP_IMPORT_STAT_FILE) {
             int ret = pyexec_file(main_py);
@@ -666,6 +686,7 @@ soft_reset:
                 flash_error(3);
             }
         }
+#endif
     }
 
     // Main script is finished, so now go into REPL mode.

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 17, 2018 12:25 am

Should I use master now, or v1.9.3?

The other day I did a test and could not get a compile to make a usable binary from master.

Are there some reports to find out when it is compilable?
John Griessen blog.kitmatic.com

User avatar
dhylands
Posts: 2905
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 17, 2018 2:24 am

I tested with master. But I'd guess that it should work with 1.9.3 as well.

The bad elf has 0 sizes but it doesn't fail the build.

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 18, 2018 7:19 pm

I used master micropython and it compiles fine today, but I don't get the frozen/boot.py and frozen/main.py
showing under frozen_mpy._names in frozen_mpy.c.

Code: Select all

const char mp_frozen_mpy_names[] = {
"onewire.py\0"
"dht.py\0"
"lcd160cr.py\0"
"lcd160cr_test.py\0"
"\0"};
I applied your patch to stm32/main.c and checked the file and it looked good.

#define MICROPY_HW_USB_FS (1)
and
#define MICROPY_HW_ENABLE_USB (1)
are in the board definition and I see it putting up a mass storage popup after it resets now.

Maybe if I try this on my PYFLEX platform I'll have USB filesystem to test with...
John Griessen blog.kitmatic.com

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 18, 2018 7:41 pm

I definitely get a round trip change when I change main.py python code that is "frozen into" the compile, not moved by USB filesystem transfers. Thanks for the patch to do that and the other digging into new platform defines needed to keep up with micropython latest. Next to test my PYFLEX platform the same way.

On the G30TH platform, when using the frozen patch, the virtual filesystem main.py is unchanged -- I use rshell and do a cat /flash/main.py and it is an old version, not what is running "frozen into" the compile.
John Griessen blog.kitmatic.com

User avatar
dhylands
Posts: 2905
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 18, 2018 8:34 pm

I copied main.py and boot.py into the modules directory to get them to be frozen (which is the standard way to get modules frozen)

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 18, 2018 11:01 pm

I had thought it was the frozen directory, so specified that.
I used a script to run make:
export BOARD="PYFLEX_F401"
export FROZEN_DIR="/home/john/Documents/EEProjects/circuitboards/culture_shock/code_PYFLEX_F401/frozen"
make -j 2 V=1 BOARD=$BOARD FROZEN_MPY_DIR=$FROZEN_DIR

calling make with FROZEN_MPY_DIR= seems to have worked. The right code runs.
My blinking GPIO ports change as I change code and reload.
I just noticed that the result is the main.py on the target is unchanged by the compiling of frozen code.
John Griessen blog.kitmatic.com

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 19, 2018 2:28 pm

I've tested the PYFLEX_F401 board and it's not so good as the G30TH -- an LED blink program is running, but it blinks 4 times instead of 90, and it doesn't change when I change details of which GPIOs blink and how long, as if that program is not really getting loaded.

But I load via the same tested method, openocd via FT2232H wired to SWD pins, that loaded miniblink, a C program that gives definite confirmation of working GPIOs, working hardware. I may try a test where I copy the G30TH definition to another one for testing and change as little as possible -- only in pins.csv -- and see what that does.

I now have serial USB dongles separate from the FT2232H that I can hook to serial port. I'll be setting up something for testing serial port speed -- not sure how to generate output without a running confirmed running micropython. Another way I could test clock speed is with miniblink compile time settings for GPIO toggle time periods -- I could make a very long one, then it would be less affected by setup and such and match close to the programmed time period if ten seconds for instance.
John Griessen blog.kitmatic.com

Post Reply