Need help building for STM32F4DISCOVERY

Hello,

I'm trying to use Espruino on an STM32F4DISCOVERY board.

I searched for binaries but the newest I was able to find is 1v96.5. Although I'm using this exact binary and it's working fine, I'd like to keep up with newer versions. I understand the binaries for this board are no longer being supplied after 1v96.5, but apparently it can still be built from source. This is what I'm trying to do.

My build environment is a Mac, and the compiler has the following version string:

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1 20181213 (release) [gcc-8-branch revision 267074]

I cloned the Espruino sources from GitHub, currently at commit bca2a9c6. I tried building with the following command:

RELEASE=1 BOARD=STM32F4DISCOVERY make

This produced the file espruino_2v01.49_stm32f4discovery.bin, which I tried to flash using the st-flash utility as follows:

st-flash write espruino_2v01.49_stm32f4discovery.bin 0x08000000

I then tried to connect using the Espruino Web IDE, but the board wasn't being detected. The System Information app for the Mac confirms no COM port was detected on the board's microUSB connector.

I flashed back the binary I had downloaded from the internet, espruino_1v96.5_stm32f4discovery.bin (linked above), and it was working fine. System Information shows the "STM32 Virtual ComPort" USB device and Espruino Web IDE connects. This rules out any issues with my Mac, drivers, USB cable, board, etc.

Given the warning here in the "Finally..." section ("after flashing the latest version of Espruino to the device, it may stop booting"), I also decided to do a mass flash erase prior to each programming attempt, by running st-flash erase. That didn't seem to make a difference. Yet any time I flash back the downloaded binary corresponding to version 1v96.5, it works just fine.

I repeated the process with the commit tagged RELEASE_1V96, RELEASE_1V97, and the one which I believe would correspond to 1v96.5 (commit c7239c7d). None of these worked. In fact I have no idea if the board is even booting; externally, all I can see is that the VCP is not detected by the computer.

Given that the downloaded binary is working, and that I tried many different versions, I'm pretty sure this boils down to something stupid such as a missing argument to make, or possibly a compiler issue.

I'm looking for any pointers to get this build to work. Alternatively, if someone could point me to the exact flags used to build the linked binary above, I'm sure it'd start me in the right direction.

Thanks.

Hi,

I searched for binaries but the newest I was able to find is 1v96.5.

Where did you look? If you go to http://www.espruino.com/Download and download the ZIP it's in there too.

https://www.espruino.com/binaries/ has all the builds in, as does http://www.espruino.com/binaries/travis/master/

Honestly, I'm not sure what your build issue is, but it's probably the compiler. It looks quite new, and sometimes optimisations get added that break bits of the CPU manufacturer's libraries. For Linux builds there's a toolchain that we use for everything that gets installed if you follow the instructions in https://github.com/espruino/Espruino/blob/master/README_Building.md

So it's probably easier to just spin up and VM, do the provision.sh script shown there and build

OK, sorry, I didn't realize there was a .zip for download with firmware for all boards.

I was just looking at the dropdown box a few lines below, and the STM32F4DISCOVERY board is missing there.

Thanks.

Ahh, ok - thanks. I'll try and get that added.

An update on this situation.

Now that I've had some time, I tried going backwards through compiler versions, in addition to the one I had previously mentioned. These are the versions I tried:

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]

I can report that only the last one (6-2017-q2-update) worked. So it looks like some work is needed to make it build using the newest compilers. If I have time, I'll try to figure out what's broken.

OK, after a little investigation, I figured out the issue, which appears to be related to LTO (Link-Time Optimization).

Basically, interrupt handlers were not being correctly called -- for instance, OTG_FS_IRQHandler, rather than calling its C implementation, was calling Default_Handler which of course goes into an infinite loop. This appears to be a gcc LTO issue, and I believe this StackOverflow question may shed light into the issue.

For now I did the hackiest thing imaginable: I edited the startup file and commented out every single .weak/.thumbset block and tried compiling again. There were linking errors for the missing IRQ handlers, so I added them back only as necessary. In the end, only IRQ Handlers that are actually declared elsewhere in the code were commented out.

With this hack, Espruino correctly compiles and runs on gcc 8-2018-q4-major.

I'm researching the "correct" solution in this case, and will create a pull request when I find it.

Found a proper workaround for the issue. It is a simple matter of linking the startup file before the rest of the files. Here's a diff (commit numbers may be wrong because this is my fork):

diff --git a/Makefile b/Makefile
index 01a31191..dfd4638e 100755
--- a/Makefile
+++ b/Makefile
@@ -601,7 +601,7 @@ SOURCES += $(PININFOFILE).c
 
 SOURCES += $(WRAPPERSOURCES) $(TARGETSOURCES)
 SOURCEOBJS = $(SOURCES:.c=.o) $(CPPSOURCES:.cpp=.o)
-OBJS = $(PRECOMPILED_OBJS) $(SOURCEOBJS)
+OBJS = $(SOURCEOBJS) $(PRECOMPILED_OBJS)
 
 
 # -ffreestanding -nodefaultlibs -nostdlib -fno-common

Here is the pull request:

https://github.com/espruino/Espruino/pull/1633

I'd also like to ask for you to look at this other pull request:

https://github.com/espruino/Espruino/pull/1632

It fixes an issue where requesting an open drain output (without pullups) ends up configuring the pullup regardless.

Thanks.

Thanks for this - just merged both of them!

The whole ordering issue is a bit of a worry though. If that is really the case (with 'weak' implementations overriding non-weak ones depending on the order) I'd have said that was a pretty bad compiler bug?

Indeed. Moreover, it has been reported over a year ago. It was supposedly fixed upstream even before the report on Launchpad, but maybe nobody bothered to merge it. Weird.

By the way, can I hijack the thread to ask if there's an issue adding the USB_HID to the STM32F4DISCOVERY so I can use E.setUSBHID(), the USB keyboard/mouse examples, etc.? I patched the boards/STM32F4DISCOVERY.py file to add this library, then tested and made it work with the keyboard and mouse examples on the site, so I could make another pull request if you don't think this is an issue.

I understand it may be more of a commercial issue, since you'd like certain features to remain exclusive to your boards, but I'm teaching an undergraduate embedded systems class at my university using Espruino and I don't have the budget to buy new boards -- the STM32F4DISCOVERY is what we have.

Thanks for the info - I don't see a problem with adding the HID support, no - if you do a PR I'll pull it in.

I don't actively 'cripple' other boards, but if I add something for the boards I sell that might not work I don't generally put the effort in to test it and get it working on others, because it's just extra support headaches if there are issues :) If there's a good reason (like in your case) I'm happy to have it in though.

Done.

Hopefully this won't be a support nightmare as it's just another STM32F40x part, similar to what powers the Espruino Pico.

By the way, are there any plans for a 2v02 release?

Thanks! Yes, I will do one soon - I don't have a particular date planned but ideally I'd get some kind of automated test harness set up first, since there seems to be a bug in Nordic's NFC implementation and it's proving painful to get one single build where NFC works on all nRF52s!

Just to say thanks - I updated the compiler to GCC 8 and it seems to work pretty well. It's also knocked ~8k off the size of some firmware builds which is a great help where it's getting a bit tight!