search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.22k stars 19.22k forks source link

[BUG] Bugfix - Auto Build Upload via ST-Link overwriting bootloader #18101

Closed Bob-the-Kuhn closed 4 years ago

Bob-the-Kuhn commented 4 years ago

The latest bugfix overwrites the first 100-200 bytes of the secondary bootloader when using Auto Build's Upload option via the ST-Link.

This happens with both Atom and VSCode.

This has been observed on a BTT SKR-PRO-V1.1 and a BTT SKR-E3-DIP-V1.0

The ST-Link upload writes the application at the correct location but it also overwrites the beginning of the secondary bootloader at 0x0800 0000. Restoring just the bootloader results in a fully functional Marlin installation.

Here is a snapshot of the locations that are being overwritten. The secondary bootloader area had been written to 00 before the Auto Build Upload was done. boot corrupted

thisiskeithb commented 4 years ago

I thought that was fixed on the SKR Pro in https://github.com/MarlinFirmware/Marlin/pull/17657, but apparently not?

sjasonsmith commented 4 years ago

I have been uploading through PIO without issues. Could Auto Build be doing something different than me selecting “Upload” in the PIO task list.

Bob-the-Kuhn commented 4 years ago

How old is your bugfix?

I think this is a recent problem. I had been uploading without problems until a few days ago. I can't find the PR right now but I think Auto Build underwent a rewrite a week or two ago.

thisiskeithb commented 4 years ago

Auto Build Marlin is in it's own repo if you wanted to see what's been updated.

sjasonsmith commented 4 years ago

How old is your bugfix?

It is a week or two old. I'll update it and see if it is still working today.

Bob-the-Kuhn commented 4 years ago

Thanks for the pointer. I've bookmarked it. Now if I can remember ...

I looked through the code & didn't see anything other than the standard PlatformIO upload command. Apparently the issue is in how the ELF file is generated.

Bob-the-Kuhn commented 4 years ago

Looks like the ELF file is the issue.

I just downloaded STM32cubeProgrammer. It is showing data being loaded at 0x0800 0000.

Bob-the-Kuhn commented 4 years ago

I just looked at the ELF file format. It's the ELF file header and program header that is being written to the start of FLASH.

sjasonsmith commented 4 years ago

I cannot find a way to corrupt my bootloader on my SKR Pro using the latest bugfix-2.0.x (as of a few minutes ago), and Auto Build 2.1.12.

I can upload either through AutoBuild or through the PIO task Window. In either case Marlin boots fine afterward, and I can still use the bootloader to update firmware from an SD card.

Perhaps this has been fixed for the SKR Pro, but is still an issue for the STM32F1 boards?

Bob-the-Kuhn commented 4 years ago

I am also now uploading the the SKR Pro via the ST-Link with no problems.

I noticed that we have switched ST32duino platform to 4.1. Perhaps that is why the SKR PRO upload is now behaving properly.

On to the E3 DIP.

Bob-the-Kuhn commented 4 years ago

E3 DIP is still having problems.

No surprise since it uses a different platform than the one that was changed.

Bob-the-Kuhn commented 4 years ago

Just did several ELF uploads via JLink and Ozone to the E3 DIP. All went well.

Switched back to an ST-Link and immediate boot corruption.

Definitely a tool chain problem.

Bob-the-Kuhn commented 4 years ago

I think that the version of Python affects this.

I deleted the Maple platform and did a new build. Still blows away the bootloader.

Changed from Python 2.7 to 3.8.3 and several E3 DIP uploads went without a problem.

I noticed that I had several versions of Python installed so I uninstalled them all and re-installed 3.8.3. The problem came back.

After trying several Python 3.x versions I gave up and write protected the bootloader sectors.

github-actions[bot] commented 4 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.