MicroPython Forum (Archive)

I'm debugging a new platform where some outputs are wrong when I run a test micropython program, so I am wondering if the package definition could be wrong and how to double check it. The various stm32fxxx_af.csv files don't have any pin number info, just port pin names in the familiar format such as PA7, PH0, PC1, etc. Same for pins.csv files.

I'm using a 48 pin package even though all the previous platforms in boards have plenty of pin names -- 64 pins a larger. Is defining pins with pins.csv all that is needed to not use a nonexistent pin when using a small package?

For stm32F401, your mpconfigboard.mk file should have a line in it like the following: To check the pinout, you can refer to the STM32F401 datasheet.
http://www.st.com/content/ccc/resource/ ... 102166.pdf
Chapter 4 has the pinouts for the various packages, and the mapping of pin number (for a given package) to the pin function (i.e. PA2). You'll also find the Alternate function mapping there. I normally copy/paste the alternate function mapping table from the PDF to create the csv file.

Hi Dave,

My mpconfigboard.mk has the AF_FILE = boards/stm32f401_af.csv line.
I've confirmed my prototype working to load code that blinks LEDs and they correspond to the datasheet GPIOA for port A, etc,
and a number for an individual pin and together they let me see the right pins toggling. I used a libopencm3 tool for this from here: https://github.com/karlp/libopencm3-miniblink and found that USB DP, USB DM and USB ID all work as GPIOs.

I had been wondering if there was any mapping from ST Microelectronics pin names to package pin numbers embedded in micropython and now think not. libopencm3 does not have any mappings in it either. So on to debugging why USB REPL or USART REPL has not worked yet, knowing that the hardware works.

I would try writing some code which writes 0xAA or 0x55 which have alternating 0's and 1's in the bit pattern. You can then grab that on a logic analyzer and if you see the pattern measure the width of a single bit to determine what baud rate its actually using.

Thanks. The serial port is a good thing to check out, and a blinky LED first is a good thing too.

I can load programs via the SWD pins, so first thing I am doing is confirm that I can load a frozen code program along with micropython into a known good board such as one of my G30TH boards. I have not done frozen before and need a sanity check on that step. G30TH and PYFLEX_F401 are not the identical platform definition, but very close. Once I confirm my ability to load test code to G30TH boards without depending on a REPL, I will compare platform definitions and try the PYFLEX_F401 board to get a blinky LED. Then I'll test some other pins as outputs, Then I'll test serial port function.

I find there is a long file of make
#define
statements in the G30TH platform definition.
It seems to be needed. I see all the stm32f4 boards have it. So this is probably why my platform is not set up correctly. It's missing proper values in those #defines.

Note that the stm32 port doesn't support loading boot.py or main.py as frozen. You'll either need a filesytem or make a small tweak to main.c

A change like this one (i.e. call pyexec_frozen_module)
https://github.com/dhylands/micropython ... #L305-L333
should allow boot.py and main.py to come from frozen code (This was something I had to do on the Teensy 3.1 which doesn't have a filesystem).

Ah so.
No wonder many tests I did attempting to load frozen code failed to make any toggling outputs...

I looked at main.c of stm32 and don't see enough of it to try dropping that code in there.
I'll try this change below first and see if I luck out and get a filesystem:

I noticed 12.00MHz number in this section of stm32f4xx_hal_conf.h, and changed it tosuitmy 16.000MHz crystal. That could explain my USB and REPL not working because of clocks wrong:

That's the correct place to set HSE_VALUE

These are the lines that would go in the #else for boot.py
https://github.com/micropython/micropyt ... #L598-L607

And these are the lines that would go in the #else for main.py
https://github.com/micropython/micropyt ... #L661-L670

No REPL after trying that last change to the stm32f4xx_hal_conf.h file.

Without frozen code debugging is hard. What would it take for that code block from teensy to work with stm32? I see many differences in the surrounding code.

When you suggested outputting some 01010101 data on serial port I was thinking "try to get micropython to load and blink LEDs first, but now I am thinking you meant, "write some C code to output to serial port, compile that along with blinking LEDs. That would mean lots of setup in different ways that micropython setup of registers for clocks, serial port etc. So, it seems like getting frozen code to work might be easier.

You just need to call pyexec_frozen_module(boot_py); instead of the lines I highlighted for boot.py and call pyexec_frozen_module(main_py); instead of the lines I highlighted for main.py.

So something like: and change the 1 to zero to go back to the original code.