[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 » Fri Apr 20, 2018 6:10 pm

I'm figuring how to debug in main.c using the PYB_LED_RED function, which on my board is active low.
So, with led counts confirmed after ignoring a first quick blink, I get 7 flashes for my case:

Code: Select all

#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(7);
        }


Looking at the stm32 Makefile:

Code: Select all

ifneq ($(FROZEN_DIR),)
# To use frozen source modules, put your .py files in a subdirectory (eg scripts/)
# and then invoke make with FROZEN_DIR=scripts (be sure to build from scratch).
CFLAGS += -DMICROPY_MODULE_FROZEN_STR
endif

ifneq ($(FROZEN_MPY_DIR),)
# To use frozen bytecode, put your .py files in a subdirectory (eg frozen/) and
# then invoke make with FROZEN_MPY_DIR=frozen (be sure to build from scratch).
CFLAGS += -DMICROPY_QSTR_EXTRA_POOL=mp_qstr_frozen_const_pool
CFLAGS += -DMICROPY_MODULE_FROZEN_MPY
endif
I put my files in a dir called modules, and used the patch of main.c as here:
viewtopic.php?f=12&t=4596&p=27084#p27012
plus changing the flash_error() function until I could confirm it with my active low board.

frozen_mpy.c:

Code: Select all

const char mp_frozen_mpy_names[] = {
"main.py\0"
"boot.py\0"
"\0"};
const mp_raw_code_t *const mp_frozen_mpy_content[] = {
    &raw_code_main__lt_module_gt_,
    &raw_code_boot__lt_module_gt_,
};
What is still causing a return of false from main.c? -- this line:

Code: Select all

        int ret = pyexec_frozen_module(main_py);
pyexec_frozen_module from pyexec.c:
https://github.com/micropython/micropyt ... #L502-L524

frozen_mpy.c has bytecode after this comment:
// frozen bytecode for file main.py, scope main_<module>

What's missing?
John Griessen blog.kitmatic.com

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

Re: [STM32F401CE] debugging a new board definition

Post by dhylands » Fri Apr 20, 2018 7:25 pm

If you copy your main.py (that you're freezing) to a G30TH or a pyboard, and try to import it (call it something else other than main.py for this) do you get any errors?

For bringing up the board, I'd make main.py be incredibly simple and move all of your stuff that's in main.py into another file. Then once you can get a REPL, you can import the other file, and if there any errors it will be much more obvious.

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

Re: [STM32F401CE] debugging a new board definition

Post by jgriessen » Fri Apr 20, 2018 7:55 pm

I've simplified my main.py to 3 blinks, no while loop.
I'll copy it to main_test.py and import on a G30TH and report back.
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 » Fri Apr 20, 2018 9:00 pm

Before the code test for errors I thought of a way to get a baud reading on some bits coming out of the serial port pin A2. I counted 57 bit times in 4.46ms which comes to 12780 baud. That's about 4/3 of 9600 baud.

I did not have compile definitions set for repl on uart at 9600, but did have the below lines in main.py.

[code# USB not used for repl
pyb.usb_mode(None)
uart = pyb.UART(2, 9600)
pyb.repl_uart(uart)
][/code]

So, now I recompiled with the repl uart lines above commented out and no output on serial pin A2, and instant, solid flashing on pin B8, B9. The problem with frozen seems to be cured, (possibly by now using modules directory? Otherwise not sure why.). The previous version of that file must have errors that the micropython interpreter stopped on. I will check that out further, but now we have more info to debug with about clocks.

The baud rate coming out at pin A2 is 4/3 of the 9600 baud it's programmed for! Sounds like a clock oscillator problem. I'll change some picofarad caps and see if the HSE settles into a different mode. And try running on HSI also at 9600 baud...
Last edited by jgriessen on Sat Apr 21, 2018 3:41 pm, edited 1 time in total.
John Griessen blog.kitmatic.com

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

Re: [STM32F401CE] debugging a new board definition

Post by dhylands » Fri Apr 20, 2018 9:21 pm

4/3 would also happen if you were using a 16 MHz crystal but set it up for 12 MHz

Search for HSE_VALUE in your board directory to make sure it isn't being set multiple places or something. The G30TH uses a 12 MHz crystal.

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

Re: [STM32F401CE] debugging a new board definition

Post by jgriessen » Fri Apr 20, 2018 10:05 pm

That suggestion to use grep was a good one. I'd forgotten how to set clock speed and thought that
// HSE is 16MHz - F401 does 84 MHz max
#define MICROPY_HW_CLK_PLLM (16)
was all I needed to set up.
the stm32f4xx_hal_conf.h setting was as for a G30TH still. Changing that now.

The serial port out I had only happens when pyexec_frozen_modules() returns false, so it was not related to
my micrpython commands in main.py yet. (But soon probably).
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 » Fri Apr 20, 2018 10:10 pm

I stopwatch clock the flashes at 7.95 sec for 4 sets of 0 and 1 with delay(1000) between, so that matches up reality with internal clock referenced time units.
This was after I changed HSE VALUE to 16000000. No out on serial port TX pin A2 now.
Last edited by jgriessen on Sat Apr 21, 2018 3:44 pm, edited 1 time in total.
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 » Sat Apr 21, 2018 12:23 am

f you copy your main.py (that you're freezing) to a G30TH or a pyboard, and try to import it (call it something else other than main.py for this) do you get any errors?
pintest2.py imports instantly on a G30TH accessed via USB REPL and rshell.

pintest.py
import pintest
takes 16 seconds to give a
>>>
prompt.

pintest.py has
# comments in a while loop, and like on the PYFLEX platform, it causes pyexec_frozen_modules() to return false.
Not tolerating comments in a while loop could be a micropython bug, but not confirmed yet.
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 » Sun Apr 22, 2018 2:35 am

I can load code via the SWD pins via a FT2232H minimodule, and get LEDs to change reliably. I noticed some PA2 bitstream going out during some of the flash_error conditions before frozen code was completely working. I pored over the mpconfigboard.h files and simplified the main.py I am loading as frozen module bytecode, and set up the REPL on USART2. Then I see a 1/4 second of data coming out of PS2 after reset and after the delays for LEDs are done. The delays must block the REPL from getting going on reset.

So now I have the other channel of the FT2232H minimodule being a serial port and it is working at 4800 baud doing the REPL. That took a while.

A good next test to do would be to set the MCU to output the HSE clock on PA8, the MCO_1 pin.
And set up some code to toggle a GPIO at a frequency to check clock accuracy also.
The big thing to debug is why the USB does not seem to work. (The volt level is between 0 and 0.1Vduring reset and after long enough to have a REPL message go out...)
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 [solved]

Post by jgriessen » Wed Apr 25, 2018 2:53 pm

I'm close but still have a problem with USB pins not functioning as USB when using board definition from G30TH with minor changes.

Before an attempt to toggle pinA11 as GPIO output with machine.pin command, I set the USB mode with this:
pyb.usb_mode('VCP') in boot.py

Next I modified the code but could not move pinA11 off 0.0V (PA8, PA9 toggle just fine). Something is not letting the
USB pins PA11, PA12 be GPIOs it seems. ( pinA11 pinA12 have been tested as outputs with C code not using micropython)
I just redid the C code test (using miniblink and libopencm3 ), and toggle PA11 as output works just fine today.

The same machine.pin command that does not work for PA11 works for PA8 PA9 etc. so I am looking for a way to find why
the machine.pin command is disabled.

Next attempt to toggle pinA11 as GPIO output with machine.pin command, I turn off the USB with this:
pyb.usb_mode(None) in boot.py.

This time GPIO output works on PA11,

so it was disabled -- overruled by having
anything else but pyb.usb_mode(None)

What are good ways to test USB function to debug it? I see no volts on PA11 PA12 the D+ and D- USB port pins after reset.
I have not tried a USB plug in while watching with the scope, so that next. (Maybe it works now :-) ) (2018-4-25AM)
No, but I find that some extra switching parts on my must be pulling VUSB low when I plug something in, so really close to finding my hardware mistake now. turned out there was an open solder connection of the USB connector.
John Griessen blog.kitmatic.com

Post Reply