micropython / micropython

MicroPython - a lean and efficient Python implementation for microcontrollers and constrained systems
https://micropython.org
Other
19.5k stars 7.81k forks source link

STM32 build fails when using FROZEN_MPY_DIR #3601

Closed peterhinch closed 6 years ago

peterhinch commented 6 years ago

This is a recent change. When I build for Pyboard V1.1 it cross-compiles the files in my specified directory and appears to build the dfu file. But then it cross-compiles the files in stm32/modules and creates a new dfu file. So help('modules') shows the standard files rather than those in the chosen directory. This is the relevant output

CC build-PYBV11/pins_PYBV11.c
CC build-PYBV11/frozen_mpy.c
LINK build-PYBV11/firmware.elf
   text    data     bss     dec     hex filename
 408040      36   28256  436332   6a86c build-PYBV11/firmware.elf
Create build-PYBV11/firmware.dfu
Create build-PYBV11/firmware.hex

Up to here everything looks fine, but then it does:

make: warning: Clock skew detected. Your build may be incomplete.
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
MPY modules/micropower.py
MPY modules/ssd1306.py
MPY modules/upysh.py
MPY modules/radiobutton.py
MPY modules/checkbox.py
MPY modules/traffic.py
MPY modules/iconswitch.py
MPY modules/Flat_UI.py
MPY modules/upower.py
MPY modules/freeserif.py
MPY modules/lcd160cr_test.py
MPY modules/gauge.py
MPY modules/onewire.py
MPY modules/uasyncio/synchro.py
MPY modules/lcd160cr.py
MPY modules/threestate.py
MPY modules/flash.py
MPY modules/dht.py
Creating build-PYBV11/frozen_mpy.c
CC build-PYBV11/frozen_mpy.c
LINK build-PYBV11/firmware.elf
   text    data     bss     dec     hex filename
 446784      52   28256  475092   73fd4 build-PYBV11/firmware.elf
Create build-PYBV11/firmware.dfu
Writing build-PYBV11/firmware.dfu to the board
File: build-PYBV11/firmware.dfu
    DfuSe v1, image size: 447137, targets: 1
    Target 0, alt setting: 0, name: "ST...", size: 446852, elements: 2
      0, address: 0x08000000, size: 14876
      1, address: 0x08020000, size: 431960
    usb: 0483:df11, device: 0x0000, dfu: 0x011a, UFD, 16, 0x583306ac
Writing memory...
0x08000000   14876 [=========================] 100% 
0x08020000  431960 [=========================] 100% 
Exiting DFU...

The above cross-compiled files reside in stm32/modules.

dpgeorge commented 6 years ago

I can't seem to reproduce it. What is the exact invocation of make that you use? And do you have a makefile/GNUmakefile in the stm32 dir?

dhylands commented 6 years ago

Also, I noticed this message: make: warning: Clock skew detected. Your build may be incomplete. This typically means that the timestamps files on your filesystem are somehow in the future (ahead of the current time on your computer). So I'd double check your time and either fix the filesystem timestamps or try a fresh clone.

peterhinch commented 6 years ago

I always get the Clock skew detected message whenever I do a build and long ago acquired the habit of ignoring it. My source tree is on a NAS and it's possible its clock may drift fractionally relative to my PC's between timeserver syncs. Would this explain it?

The only Makefile in stm32 is as per the master: git status shows no modified files and no unaccountable untracked files. The build script first determines the board type and correctly outputs 'Building for PYBV11' for $BOARD:

echo Building for $BOARD

FROZEN_DIR='/mnt/qnap2/data/Projects/MicroPython/projects/net_analyser/frozen'

if [ $BOARD ]
then
    cd $MPDIR/ports/stm32
    if [ $# -eq 1 ] && [ $1 = "--clean" ]
    then
        make BOARD=$BOARD clean
    fi
    if make -j 8 BOARD=$BOARD FROZEN_MPY_DIR=$FROZEN_DIR && pyb_boot $MPDEVICE
    then
        sleep 1
        make BOARD=$BOARD deploy
        cd -
        sleep 1
        rshell
    else
        echo Build failure
    fi
else
    echo Incorrect board type
fi

It deploys and starts rshell but with the incorrect frozen modules.

The script has worked up to now. Another script which only differs in

FROZEN_DIR='modules'

runs normally.

dhylands commented 6 years ago

If you're using a server to host your files, then this often means that the time on the server isn't in sync with the time on your build machine,

peterhinch commented 6 years ago

I'm doubtless missing something obvious here, but I'm still foxed as to why this has stopped working. Here is my git status:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    drivers/nrf24l01/issue
    ports/esp8266/modules/aremote.py
    ports/esp8266/modules/aswitch.py
    ports/esp8266/modules/asyn.py
    ports/esp8266/modules/collections/
    ports/esp8266/modules/do_connect.py
    ports/esp8266/modules/errno.py
    ports/esp8266/modules/logging.py
    ports/esp8266/modules/mqtt_as.py
    ports/esp8266/modules/pickle.py
    ports/esp8266/modules/syncom.py
    ports/esp8266/modules/uasyncio/
    ports/esp8266/modules/umqtt/
    ports/stm32/modules/Flat_UI.py
    ports/stm32/modules/checkbox.py
    ports/stm32/modules/collections/
    ports/stm32/modules/errno.py
    ports/stm32/modules/flash.py
    ports/stm32/modules/font10.py
    ports/stm32/modules/font14.py
    ports/stm32/modules/freeserif.py
    ports/stm32/modules/gauge.py
    ports/stm32/modules/iconswitch.py
    ports/stm32/modules/logging.py
    ports/stm32/modules/micropower.py
    ports/stm32/modules/plot.py
    ports/stm32/modules/radiobutton.py
    ports/stm32/modules/ssd1306.py
    ports/stm32/modules/tft.py
    ports/stm32/modules/threestate.py
    ports/stm32/modules/touch_bytecode.py
    ports/stm32/modules/traffic.py
    ports/stm32/modules/uasyncio/
    ports/stm32/modules/ugui.py
    ports/stm32/modules/upower.py
    ports/stm32/modules/upysh.py
    tools/errno
    tools/gc
    tools/json
    tools/os
    tools/sys
    tools/tarfile
    tools/uzlib

nothing added to commit but untracked files present (use "git add" to track)
[adminpete@axolotl]: /mnt/qnap2/data/Projects/MicroPython/micropython
peterhinch commented 6 years ago

OK, I've got to the bottom of this and I guess it's simple. But the script worked previously and I'm foxed as to why it started to fail. The fix is to do

        make BOARD=$BOARD FROZEN_MPY_DIR=$FROZEN_DIR deploy

In its previous form it was causing the rebuild with the frozen modules in the default directory.