compilation error on STM32F411DISCOVERY

Posted on
  • Hi, STM32F4DISCOVERY board is "old" and difficult to get so I want to use STM32F411DISCOVERY board to replace. after installed the toolchain on Mac and git clone the latest Espruino github repo, I'm hitting the command in terminal: $make clean && BOARD=STM32F411DISCOVERY RELEASE=1 make, the compilation error report as below:

    -->
    ......
    In file included from /Users/dp/Desktop/esptest/gen/jspininfo.­c:3:0:
    /Users/dp/Desktop/esptest/gen/jspininfo.­h:36:18: note: 'functions' declared here
    JshPinFunction functions[JSH_PININFO_FUNCTIONS];

                  ^~~~~~~~~
    

    /Users/dp/Desktop/esptest/gen/jspininfo.­c:86:12: warning: missing initializer for field 'functions' of 'JshPinInfo {aka const struct JshPinInfo}' [-Wmissing-field-initializers]
    /* PH0 */ { JSH_PORTH, JSH_PIN0+0, JSH_ANALOG_NONE, { 0, 0, 0, 0, 0 } },

            ^
    

    In file included from /Users/dp/Desktop/esptest/gen/jspininfo.­c:3:0:
    /Users/dp/Desktop/esptest/gen/jspininfo.­h:36:18: note: 'functions' declared here
    JshPinFunction functions[JSH_PININFO_FUNCTIONS];

                  ^~~~~~~~~
    

    /Users/dp/Desktop/esptest/gen/jspininfo.­c:87:12: warning: missing initializer for field 'functions' of 'JshPinInfo {aka const struct JshPinInfo}' [-Wmissing-field-initializers]
    /* PH1 */ { JSH_PORTH, JSH_PIN0+1, JSH_ANALOG_NONE, { 0, 0, 0, 0, 0 } },

            ^
    

    In file included from /Users/dp/Desktop/esptest/gen/jspininfo.­c:3:0:
    /Users/dp/Desktop/esptest/gen/jspininfo.­h:36:18: note: 'functions' declared here
    JshPinFunction functions[JSH_PININFO_FUNCTIONS];

                  ^~~~~~~~~
    

    make: *** [/Users/dp/Desktop/esptest/gen/jspininfo­.o] Error 1
    make: *** Waiting for unfinished jobs....

    ======

    I'm checking the file STM32F411DISCOVERY.py in Espruino/boards and find it seems using the revision of STM32F4DISCOVERY.py with wrong pin definitions in stm32f40x.csv file and also wrong name/alternate function offset, so I edited a new stm32f411.csv file based on the data sheet, the compilation error now becomes :

    -->
    ......
    Cleaning targets
    Generating platform configs
    Generating pin info
    Traceback (most recent call last):
    File "scripts/build_platform_config.py", line 47, in

    pins = board.get_pins()
    

    File "/Users/dp/Desktop/espmac/boards/STM32F4­11DISCOVERY.py", line 139, in get_pins

    pins = pinutils.scan_pin_file([], 'stm32f411.csv', 5, 8, 9)
    

    File "/Users/dp/Desktop/espmac/scripts/pinuti­ls.py", line 194, in scan_pin_file

    pin["csv"][head] = pindata[i].strip()
    

    IndexError: list index out of range
    Traceback (most recent call last):
    File "scripts/build_pininfo.py", line 50, in

    pins = board.get_pins()
    

    File "/Users/dp/Desktop/espmac/scripts/../boa­rds/STM32F411DISCOVERY.py", line 139, in get_pins

    pins = pinutils.scan_pin_file([], 'stm32f411.csv', 5, 8, 9)
    

    File "/Users/dp/Desktop/espmac/scripts/pinuti­ls.py", line 194, in scan_pin_file

    pin["csv"][head] = pindata[i].strip()
    

    IndexError: list index out of range
    make: *** [/Users/dp/Desktop/espmac/gen/jspininfo.­h] Error 1
    make: *** Waiting for unfinished jobs....
    make: *** [/Users/dp/Desktop/espmac/gen/platform_c­onfig.h] Error 1

    ======

    just generating the pin info, I'm stuck...so I'm checking scripts/pinutils.py to try to find some clues, but still not clear about the potential root cause.

    so I'm checking how other STM32 based boards do it, by referring to NUCLEOF401RE.py, I'm adding a new file stm32f411_af.csv based on the data sheet and use the get_pins() function as below:

    def get_pins():
    pins = pinutils.scan_pin_file([], 'stm32f411.csv', 5, 8, 9)
    pins = pinutils.scan_pin_af_file(pins, 'stm32f411_af.csv', 0, 1)
    return pinutils.only_from_package(pinutils.fill­_gaps_in_pin_list(pins), chip["package"])

    unfortunately, the compilation error is still the same, so lose clue to move forward...does someone met similar issue or some other documents to understand the pinutils.py logic behind better ? I attached stm32f411.csv and stm32f411_af.csv files for you reference.


    2 Attachments

  • Hi, I attached my STM32F411DISCOVERY.py file too.

    I revised a little bit(chip part number) as seems the original source from Espruino repo is not correct.

    I added a new startup file : startup_stm32f411xe.s from ST to replace original startup_stm32f401xx.s :
    -->
    ('PRECOMPILED_OBJS+=$(ROOT)/targetlibs/s­tm32f4/lib/startup_stm32f411xe.o' # FIXME: need change to startup_stm32f40_411xe.S ?)


    1 Attachment

  • Hi,
    one more thing, compile for STM32F4DISCOVERY is successful without touching any file:

    -->
    $make clean && BOARD=STM32F4DISCOVERY RELEASE=1 make

    CC src/jshardware_common.o
    CC /Users/dp/Desktop/esptest/gen/jswrapper.­o
    LD espruino_1v94.3381_stm32f4discovery.elf
    GEN espruino_1v94.3381_stm32f4discovery.lst
    GEN espruino_1v94.3381_stm32f4discovery.bin
    GEN espruino_1v94.3381_stm32f4discovery.hex
    bash scripts/check_size.sh espruino_1v94.3381_stm32f4discovery.bin
    PASS - size of 300720 is under 786432 bytes

  • You're actually better off using the F401 pin defs - since they're basically the same as the F411 I believe. It seems like the first build failure may have been from something else.

    The second build failure is from Python complaining about your new CSV files by the look of it -
    maybe you're referencing the wrong column number when calling scan_pin_file?

    Did you consider using the Nucleo boards? a bunch of those are properly supported.

    If not, you could maybe look at he F411 Nucleo board file which I believe does work, and see what's different.

  • Hi Gordon,

    follow your suggestion, I have changed the csv file from 'stm32f411.csv'(which created by me following the data sheet)to 'stm32f401.csv'(original) in pinutils.scan_pin_file().

    the same applied to pinutils.scan_pin_af_file() - from 'stm32f411_af.csv' to 'stm32f401_af.csv'.

    and changed the startup file from 'startup_stm32f411xe.o' to 'startup_stm32f40_41xxx.o'

    then the build work successfully.

    but I'm more confused as I do not understand the root cause.

    why the standard startup file(startup_stm32f411xe.o)is not working ?

    the pin definitions is slightly different between stm32f401 and stm32f411, why follow strictly with data sheet, without format error, the parser is not working ?

    sorry for the curious as I'm keen on understanding the principals & processes how you do it(how to build or port to new device).

    thanks for your kindness.

  • Hi Gordon,

    I attach a short screen shoot of the diff between two csv files fyi.

    without format error, the python script should work properly...

    but now just switch to f411.csv file, the compilation is broken: list index out of range

    -->

    Traceback (most recent call last):
    File "scripts/build_pininfo.py", line 50, in

    pins = board.get_pins()
    

    File "/Users/dp/Desktop/espmac/scripts/../boa­rds/STM32F411DISCOVERY.py", line 139, in get_pins

    pins = pinutils.scan_pin_file([], 'stm32f411.csv', 5, 8, 9)
    

    File "/Users/dp/Desktop/espmac/scripts/pinuti­ls.py", line 197, in scan_pin_file

    pin["csv"][head] = pindata[i].strip()
    

    IndexError: list index out of range
    make: *** [/Users/dp/Desktop/espmac/gen/jspininfo.­h] Error 1
    make: *** Waiting for unfinished jobs....
    make: *** [/Users/dp/Desktop/espmac/gen/platform_c­onfig.h] Error 1


    1 Attachment

    • Screen Shot 2017-10-27 at 13.25.43.png
  • It looks like it's not working because startup_stm32f411x.s doesn't actually exist :)

    However boards/STM32F411DISCOVERY.py actually references startup_stm32f401xx - so I guess that's something you must have changed anyway?

    I just checked up on this, and it's because the board file contains the wrong number of ADCs. If you git pull now it'll work, without modification.

    To find out what's wrong with the CSV I'd add some print statements to scan_pin_file in scripts/pinutils.py - it's likely that one of the lines that's changed just has too few commas in it?

  • Hi Gordon,

    I have pulled your latest commit and compiled it without errors without any modification. thanks for your great support :)

    but still questions and doubts:

    1.I have double checked the data sheet of STM32F411VET6, the ADC number is only 1, but if I revise the adc number to 1, the compilation error as attached screen shoot of adc-numbers.

    2.I have downloaded from ST website and put the startup_stm32f411xe.s file into targets/lib/stm32f4 folder. if use it, the build will be failed at the final link stage. switch to startup_stm32f401xx.s without issue. see attached screen shoot startup_stm32f411xe-linker-error.

    3.I find an error in stm32f411.csv(one line with eventout/adc1_9 instead of eventout,adc1_9, cause the index out of range error), after this error be corrected, I met another error, seems link to ADC, no matter put adc number as 2 or 1, switch the startup files, it's the same error message, see attached screen shoot of error-with-stm32f411-csv. switch back to stm32f40x.csv or stm32f401.csv, they are working.


    1 Attachment

    • error-with-stm32f411-csv.png
  • screen shoot of adc-number error.


    1 Attachment

    • adc-numbers.png
  • data sheet of stm32f401vet6(for stm32f411discovery)


    1 Attachment

  • screen shoot of startup_stm32f411xe linker error


    1 Attachment

    • startup_stm32f411xe-startup_stm32f401xx-link-error.png
  • Hi Gordon,

    I guess it's due to you derived the scripts for support of such boards from STM32F4DISCOVERY, which is using STM32F407xx. if the new chip has different peripheral configurations, need tune the scripts manually and seems not straight forward process.

    and also in the beginning, I'm referring to Nucleo board BOARD.py file(NUCLEOF411RE.py) and CSV file(stm32f411.csv, stm32f411_af.csv), but seems you have different scripts for Nucleo and Discovery boards(for example in BOARD.py file, Discovery board do not call the function to scan the alternate function file).

  • Do the ADCs not work with the new build then?

    Honestly you're going to have to go digging to see why the ANALOG123 error happens - it builds fine with one ADC on the Espruino WiFi, which is an F411 part. The code is designed to make porting easier - it's never going to be completely trivial.

    I can't be much help with the linker error - why not just use the f401 startup file? it works fine. It's hardly surprising that a new file from a different SDK version won't just drop in and work.

  • Hi Gordon,

    sure, it's not trivial and I will go deeper and check further by myself.

    just an open question, why not use the HAL/CMSIS files generated by ST tools directly ? I saw for STM32L4 family you are using this approach, MicroPython use this approach too, should be easier and more consistent than from scratch ? or the official library is too buggy ?

  • why not use the HAL/CMSIS files generated by ST tools directly

    The main answer is Espruino is ~5 years old, and ST didn't have any of those tools available at that time. I uses what there was.

    But also I had a go at porting to the new libraries a while back and found that the 'new' ST HAL was horribly inefficient with memory, and also was totally not suited to interpreters. The library wants you to define up-front what peripherals you want to where, and in an interpreter you want to define them when you execute the code, not at compile time.

    Basically it is Ok for micropython because it targets MCUs with more memory, but I was just unable to target the 128kB/8kB MCUs with the new library that were fine with the old library, so I stopped trying. It seemed stupid to spend weeks porting to a new library just so Espruino could be slower, more buggy and use more memory.

    ST themselves did a port to STM32L4 heavily based off the existing STM32 port, but that uses the even newer LL low level libraries, not CubeMX as far as I know.

  • Hi Gordon,

    thanks and very clear. double check again, indeed STM32L4 porting is based on LL library instead of HAL. and Espruino is more memory efficient than MicroPython.

    hope it's not offensive, many people will check both Espruino and MicroPython, at least for me MicroPython seems easier for new comer the way different vendor/board/chip/process organized. I know it's carping and unfair to you as Espruino is almost your one-man story. hope no hard feeling to you, I really enjoy and thanks for your creation :)

  • @hutu, it all depends where you come from, what is readily available... and what the problem is you try to solve.

    A long as you stay with the Arduino processing model - loops and delays - programming is easy. When exploiting what Micro-Python actually can do - events and callbacks - you have to master multi-threaded. For some makers, event and callbacks are already a challenge - that's why the simple and straight forward Arduino model is so popular. Multi-threaded programming poses challenges even to strong programmers. Espruino has events and callbacks but by the definition of JavaScript (and Espruno's implementation), multi-threading does not happen and therefore not something one has to worry about.

    Indeed, Micro-Python goes further than Espruino JavaScript, but for me the Espruino JavaScript solution gives me most bang for the buck - buck being not just $ or £

    Initially I wanted to pint out that Python despite its lead of 15+ years is nowhere near where node.js is, and JS a common ground on client and server... but going down that path is about as mature as the comparative word fight of kindergardeners shouting "...my dad is or has more xyz than yours...", with xyz changing being just anything popping in their head...

    What happen to me is that Espruino knocked me of the Arduino track in less than a blink of an eye, even though I became aware of the Micro-Python / Pyboard before the Espruino JS / board early 2014. A major reason was and still is that I can cross/emulate-develop in the browser, even though since Spring this year 2017, Micro-Python runs now 'bare metal' also in the browser (on a Cortex-M3 emulation in .js / unicorn.js).

  • MicroPython seems easier for new comer the way different vendor/board/chip/process organized

    No offense taken! It's not intentionally difficult, but at the same time I have no motivation to make it easy to port Espruino to new devices.

    I am concerned with making Espruino really easy to use on the boards that I sell, because those are the ones that actually make me money. I'd be insane to focus on making it easy for people to make competing boards.

    If ST or other manufacturers were willing to pay me to make it easier to port to their chips then that might be different. Of course if anyone wants help porting to a new device, they can always pay me to do it for them.

    Open Source means you get the software for free - it doesn't mean free support or development services :)

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

compilation error on STM32F411DISCOVERY

Posted by Avatar for hutu @hutu

Actions