Hi,
I had a Creality board 1.1.5 before where I could upload the Marlin firmware without problems. I did upgrade the board (4.2.7) and changed the env to the boards specific one STM32F103RET6_creality
Since then I get a message by J-Link ''No emulators connected via USB Do you want…"
I did some research and installed the Win J-Link driver without success. Any idea why the upload doesn’t work anymore?
Firmware works with SD card upgrade. Same usb cable.
Protocol I get:>
> Archiving .pio\build\STM32F103RET6_creality\libff4\libUSBComposite.a
Archiving .pio\build\STM32F103RET6_creality\lib363\libServo.a
Archiving .pio\build\STM32F103RET6_creality\liba69\libFreeRTOS701.a
Linking .pio\build\STM32F103RET6_creality\firmware-20201115-035043.elf
Checking size .pio\build\STM32F103RET6_creality\firmware-20201115-035043.elf
Building .pio\build\STM32F103RET6_creality\firmware-20201115-035043.bin
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [== ] 17.3% (used 11336 bytes from 65536 bytes)
Flash: [===== ] 50.4% (used 264012 bytes from 524288 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, dfu, jlink, serial, stlink
CURRENT: upload_protocol = jlink
Uploading .pio\build\STM32F103RET6_creality\firmware-20201115-035043.bin
SEGGER J-Link Commander V6.52 (Compiled Sep 27 2019 17:52:04)
DLL version V6.52, compiled Sep 27 2019 17:50:11
J-Link Command File read successfully.
Processing script file...
J-Link connection not established yet but required for command.
J-Link connection not established yet but required for command.
Connecting to J-Link via USB...FAILED: Failed to open DLL
J-Link connection not established yet but required for command.
Connecting to J-Link via USB...FAILED: Failed to open DLL
Do you have a JLink connected to the STM32F103RET6 chip or explicitly want to upload via a JLink? Or does PlatformIO just want to upload to it by default? Seems to me that the firmware .pio\build\STM32F103RET6_creality\firmware-20201115-035043.bin was created and you should do a SD card upgrade.
Hm, well I would like to uploaded it like I was able to do with the older board. With the older board I wasn’t asked to use Jlink. It did just work and I didn’t ask why 
I don’t care what protocol makes the upload possible.
The new board is connected with usb on the same port. So actually I didn’t change anything other the env… The firmware gets compiled and works but I can’t upload it through VS anymore because of this JLink trouble
//Edit: Maybe good to know. I’m using the “Auto Build Marlin Extension” to build and upload and it worked with the old board
PlatformIO supports multiple upload protocols (docs), and it seems to me that in the platformio.ini of Marlin, the environment you’re using now ([env:STM32F103RET6_creality] if I understand you correctly) just sets upload_protocol = jlink, while your old environment / board you compiled for either had no such directive and thus defaulted to USB-DFU upload, or explicitly sets upload_protocol = dfu.
Can you tell me which which exact older board you used (board name / platformio environment name) with which you were able to do the normal USB upload?
Yes that was also my assumption but I’m hesitated to change those values around as I have no clue what they do.
The prior board env was “mega2560”. Board name. Hm. Creality Silent board 1.1.5. Well that’s the product name. I think you need the firmware naming but I have no idea since I followed a tutorial back then which worked out on the first try.
Okay that was an entirely different chip achirecture. The Arduino Mega2560 board is usually programmed via a serial bootloader, and with a USB-Serial convert chip on the board. Your new STM32 based board is a different beast and has a special bootloader that allows it to upgrade its firmware via an SD card. I’ll explain it in a bit more detail.
There 2 are main caveats here:
- for uploading via USB, the STM32 chip has to either be put in a special bootloader mode (via
BOOT0 pin, there’s usually a jumper, pin header or button on the mainboard that allows you to pull this signal to GND), or the firmware itself has to implement USB firmware upgrade. If you need to use the BOOT0 pin, check with the github repos of your board manufacturer what you need to change / press on the board in order to do that, or if there are instructions for that. From the PlatformIO side, you just need to go into the platformio.ini and then into your [env:x] environment you’re working on, remove the old upload_protocol = .. line and set upload_protocol = dfu, and attempt upload via the normal Upload button.
- the memory contents / flash of the STM32 chip on these 3D printer boards consist of a pre-programmed bootloader and the firmware, one after another in memory. From my understanding, Marlin is just firmware and does not contain the bootloader itself – if you were to not use the “FW upgrade via bootloader + SD card” method but directly only write the Marlin firmware to the chip (and the chip is auto-erased before flashing the firmware), you will very likely lose the bootloader. And if you have lost that, you need to go a longer route to find that bootloader and burn it back into the chip. Tedious. The Marlin firmware will very likely still work if burned directly on the chip without the bootloader, but you’ll lose the SD card upgrade functionality with out it.
Of course, using special programmer hardware (like an ST-Link clone) and tools like ST-Util allows you to fully dump the current firmware (with bootloader) stored in the STM32 chip, so if you have a backup of that, you can freely experiment and restore it if something fails horribly.
But, my recommendation would be to stick to upgrading via the SD card and the bootloader that’s currently running in your chip, without attempting a direct upload, unless you absolutely know what implications regarding overwriting the bootloader will have and you’re sure you want to do it that way. With regards to that, the board manufacturer should be able to answer the questions you might have.
PS: The reason why the uploading to the Mega2560 board isn’t breaking its bootloader (which does the SD card upgrade) is because the bootloader is also the thing that accepts the new firmware over serial and it writes it above the bootloader to not overwrite itself; With the USB-DFU upload, you’re directly overwriting all memory, including the bootloader.