Trying to compile in 2022

[malinges]

Hi there!

Not sure if someone will read this, but I figured it was worth a try :-)

Lately I've been trying to compile myevic from source with a recent toolchain, with the idea to modify it later for a little experiment. But I've been struggling, first to compile with success at all, then to get the produced firmware image to run correctly...

First issue was to locate the Nuvoton M451 BSP / SDK. Nuvoton's website seems to have changed quite a bit since myevic's docs were written, and I couldn't find the SDK available for download on their website. So instead I used https://github.com/OpenNuvoton/M451BSP which looks like it's maintained directly by Nuvoton.

Second issue was caused by the -nostartfiles LDFLAG which is now rejected with an error by the linker:

arm-none-eabi-ld: Error: unable to disambiguate: -nostartfiles (did you mean --nostartfiles ?)

I removed the option from LDFLAGS and added it to CFLAGS instead.

Third issue was caused by the double declaration of NewMillis both in src/eh.c and src/atomizer.c:

arm-none-eabi-ld: src/eh.o:(.bss.NewMillis+0x0): multiple definition of `NewMillis'; src/atomizer.o:(.bss.NewMillis+0x0): first defined here

Removing the declaration from src/atomizer.c fixed it.

Fourth issue was caused by the (now) wrong relative paths of libnosys.a, libgcc.a, libc.a and libm.a in the linker script:

arm-none-eabi-ld: cannot find v7e-m/libnosys.a: No such file or directory
arm-none-eabi-ld: cannot find v7e-m/libgcc.a: No such file or directory
arm-none-eabi-ld: cannot find v7e-m/libc.a: No such file or directory
arm-none-eabi-ld: cannot find v7e-m/libm.a: No such file or directory

Fixing this requires selecting the right path/variant amongst v7e-m/nofp, v7e-m+fp/softfp, v7e-m+fp/hard, v7e-m+dp/softfp, or v7e-m+dp/hard, and to be honest I'm not sure which one it is. The startup file myevic.s seems to try to enable an FPU, but using the hard versions of the libs fails to compile with an error about VFP registers. The others all seem to compile with success, but the resulting firmware image doesn't run, although it could be something else...

Fifth issue was caused by the linker getting mixed up when generating the firmware image, and trying to output the .data and second .text sections at the same position in the image:

arm-none-eabi-ld: section .text LMA [0000000000018a3c,0000000000018a53] overlaps section .data LMA [0000000000018a3c,0000000000018bdf]

which I (hopefully) fixed by settings the second .text section's LMA explicitly:

@@ -89,7 +89,7 @@ SECTIONS {

        SRAMZ_Size = SRAMZ_End - SRAMZ_Start;

-       .text : {
+       .text : AT(Data_Start_ROM + Data_Size) {
                . = ALIGN(4);
                RAMInitTable = .;

With these changes the compilation now completes with success (yay!) but the resulting firmware image doesn't run properly and the display stays blank. When compiling on Arch with arm-none-eabi-gcc 12.2.0-1, plugging the device into my computer spits out USB enumeration errors in the kernel log. Here's what plugging the device once looks like:

[14587.381863] usb 3-2: new full-speed USB device number 24 using xhci_hcd
[14587.511959] usb 3-2: device descriptor read/64, error -71
[14587.748629] usb 3-2: device descriptor read/64, error -71
[14587.981779] usb 3-2: new full-speed USB device number 25 using xhci_hcd
[14588.115265] usb 3-2: device descriptor read/64, error -71
[14588.355243] usb 3-2: device descriptor read/64, error -71
[14588.463042] usb usb3-port2: attempt power cycle
[14588.865146] usb 3-2: new full-speed USB device number 26 using xhci_hcd
[14588.865659] usb 3-2: Device not responding to setup address.
[14589.075620] usb 3-2: Device not responding to setup address.
[14589.281756] usb 3-2: device not accepting address 26, error -71
[14589.405159] usb 3-2: new full-speed USB device number 27 using xhci_hcd
[14589.405541] usb 3-2: Device not responding to setup address.
[14589.612169] usb 3-2: Device not responding to setup address.
[14589.821789] usb 3-2: device not accepting address 27, error -71
[14589.822084] usb usb3-port2: unable to enumerate USB device

By tinkering with the code a little bit, I managed to display some stuff on the screen, but the firmware always seems to lock up later in the main loop (it looks like the culprit is somewhere in the 10hz tick handling code, but I'm not skilled or knowledgeable enough to be sure).

When compiling on Ubuntu with gcc-arm-none-eabi 15:10.3-2021.07-4, the display also stays blank, but USB doesn't even seem to respond at all (plugging the device into my computer doesn't generate a single log).

I've tried everything I could think of: using older versions of the M451 BSP, resetting the dataflash, making sure my device's hardware version was correct (VTC Mini v1.01), trying differents variants of libgcc.a & friends, different linker script approaches... but nothing worked. I'm stuck!

Any idea what's going on, or as a fallback, how to install a working development environment for myevic nowadays? :-P

Any help would be immensely appreciated, but in any case, thank you for your amazing work on myevic!