Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

make -j flash broken on esp* (will always flash the previous binary) #13492

Closed
benpicco opened this issue Feb 26, 2020 · 4 comments · Fixed by #14041 or #16307
Closed

make -j flash broken on esp* (will always flash the previous binary) #13492

benpicco opened this issue Feb 26, 2020 · 4 comments · Fixed by #14041 or #16307
Assignees
Labels
Area: build system Area: Build system Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)

Comments

@benpicco
Copy link
Contributor

Description

I'm a habitual user of make -j. It looks like the build system has developed a very reliable race condition where a make -j flash will always flash the previous binary on esp*.

Steps to reproduce the issue

  • In examples/hello-world run make BOARD=esp32-wroom-32 -j flash term.
  • change the text in main.c, better yet print it in a while(1) loop
  • run make BOARD=esp32-wroom-32 -j flash term again

Expected results

  • the new text is printed

Actual results

  • the old text is printed.
  • run make BOARD=esp32-wroom-32 -j flash term again
  • the new text is printed.

Workaround

  • run make BOARD=esp32-wroom-32 -j && make BOARD=esp32-wroom-32 flash term

Versions

xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0
GNU Make 4.2.1

@benpicco benpicco added Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Area: build system Area: Build system labels Feb 26, 2020
@gschorcht
Copy link
Contributor

gschorcht commented May 8, 2020

Hm, strange and not really clear why. I used tests/shell for my tests. main.c is definitly recompiled and the change is in ELF file tests_shell.elf. I have checked this by renaming a function in main.c.

@gschorcht
Copy link
Contributor

It seems that it starts preflash target before the tests_shell.elf has been updated. At least I can observe with QUIET=0 that the following preparation of the flash file is executed before the compilation of the ELF file tests_shell.elf has been finished:

# configure preflasher to convert .elf to .bin before flashing
PREFLASHER = $(ESPTOOL)
PREFFLAGS = --chip $(FLASH_CHIP) elf2image
PREFFLAGS += --flash_mode $(FLASH_MODE) --flash_size $(FLASH_SIZE)MB
PREFFLAGS += --flash_freq $(FLASH_FREQ) $(FLASH_OPTS)
PREFFLAGS += -o $(FLASHFILE).bin $(FLASHFILE);
PREFFLAGS += printf "\n" > $(BINDIR)/partitions.csv;
PREFFLAGS += printf "nvs, data, nvs, 0x9000, 0x6000\n" >> $(BINDIR)/partitions.csv;
PREFFLAGS += printf "phy_init, data, phy, 0xf000, 0x1000\n" >> $(BINDIR)/partitions.csv;
PREFFLAGS += printf "factory, app, factory, 0x10000, " >> $(BINDIR)/partitions.csv;
PREFFLAGS += ls -l $(FLASHFILE).bin | awk '{ print $$5 }' >> $(BINDIR)/partitions.csv;

This part is executed by the preflash target and flash depends on preflash

FLASHDEPS += preflash

So it seems to be a missing dependency of the preflash target on the ELF file. Maybe I misinterpreted the preflash target when I wrote the makefiles. I thought it is a target that is executed before an ELF file is flashed. But obviously it only depends on the BUILD_BEFORE_FLASH variable which isn't set anywhere

preflash: $(BUILD_BEFORE_FLASH)

There are two options to solve the problem. Either we move the code for the preparation of the flash binary to the flash target or we just set the variable

BUILD_BEFORE_FLASH += $(FLASHFILE)

@gschorcht
Copy link
Contributor

The fix in PR #14041 had to be reverted for the moment.

@gschorcht gschorcht reopened this May 12, 2020
@miri64 miri64 added this to the Release 2020.07 milestone Jul 6, 2020
@jenswet
Copy link
Contributor

jenswet commented Jan 8, 2021

I can reproduce the same problem on the current master.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Area: build system Area: Build system Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)
Projects
None yet
5 participants