sl1pkn07 commented 5 years ago

Hi

I just discover my SKR mini E3 DIP 1.0 have a different model of MCU than the configured in the platformio.ini file

in the platformio.ini

https://github.com/MarlinFirmware/Marlin/blob/f9961ddebb125cb6cc6670b82093d25ee4477f76/platformio.ini#L295-L300

my physical SKR Mini E3 DIP:

IMG_20190914_010459

STM32F103 RET6 is a 512KB unit

https://www.mouser.es/ProductDetail/STMicroelectronics/STM32F103RET6?qs=tZXS5FmuAdnGL83bu1Xcew==

https://docs.platformio.org/en/latest/boards/ststm32/genericSTM32F103RE.html

but in the platformio is configured as STM32F103 RCT6, which is a 256KB unit

https://www.mouser.es/ProductDetail/STMicroelectronics/STM32F103RCT6?qs=sGAEpiMZZMuoKKEcg8mMKGCsvkp7Jpfjiil20HX4niM%3D

https://docs.platformio.org/en/latest/boards/ststm32/genericSTM32F103RC.html

I'm not sure if the SKR mini 1.1 and the E3 have the same problem

any througths?

greetings

tpruvot commented 5 years ago

unsure about the E3, but the mini is RCT6 https://drive.google.com/file/d/13ReQ8lGl8vKstoi3IBOo9YVQePUI_WBr/view?usp=sharing

tpruvot commented 5 years ago

else, should not be a problem unless you reach the firmware size, with some costly features like the USB composite. To fix that, remember to change the .ld script too buildroot/share/PlatformIO/ldscripts/STM32F1_SKR_MINI.ld

sl1pkn07 commented 5 years ago

with some touches

Memory Usage -> http://bit.ly/pio-memory-usage
DATA:    [==        ]  22.6% (used 11096 bytes from 49152 bytes)
PROGRAM: [========= ]  88.0% (used 230812 bytes from 262144 bytes)

(from boy in a telegram channel)

sl1pkn07 commented 5 years ago

cc @bigtreetech

tpruvot commented 5 years ago

it look like they have both models on the E3 DIP... cf their shop picture

tpruvot commented 5 years ago

well, consider you are lucky :p got a free bonus... but unfortunately, platformio cant be changed for all.. for now

sl1pkn07 commented 5 years ago

from telegram

photo_2019-09-14_01-37-43

yep. seems I have a BTT special edition :O

mvoss96 commented 5 years ago

the entry for mini e3 is also wrong. the physical baord is also ret6. I cant use eeprom and sd support at the same time for this reason even so the board should have 512k.

how can i change this?

sl1pkn07 commented 5 years ago

not tested. but:

change this

board = genericSTM32F103RC

to this

board = genericSTM32F103RE

and the LD script like said @tpruvot

sl1pkn07 commented 5 years ago

else, should not be a problem unless you reach the firmware size, with some costly features like the USB composite. To fix that, remember to change the .ld script too buildroot/share/PlatformIO/ldscripts/STM32F1_SKR_MINI.ld

any example of this?

greetings

mvoss96 commented 5 years ago

i tried to change it to genericSTM32F103RE and the256k to 512k in STM32F1_SKR_MINI.ld. It does compile, but the board doesnt flash the firmware

tpruvot commented 5 years ago

i see, maybe they didnt update their bootloader code... which do the SD update. So it could be more complicated, requires a stflash and.. basically you have to comment the .py script in the platformio.ini but... well a full backup of the chip may be required first... to rollback.

To note, the stflash should use the 3.3V wire, not 5V (SWD connector)

sjasonsmith commented 5 years ago

I have both a Mini and a DIP that I received about a week ago. Both have the same RET6 controller. Maybe they chose to upgrade their design, but it might also just be a drop-in-replacement based and they will buy whichever is cheaper or more available on any given day.

tpruvot commented 5 years ago

yep i dont know, i dont even see a comment on their multiple shops, they all show RCT6 for now.

sl1pkn07 commented 5 years ago

My unit has been purchased in BTT Ali official store in 26 Aug

sjasonsmith commented 5 years ago

My unit has been purchased in BTT Ali official store in 26 Aug

Mine were ordered from "BIG TREE TECH Store" on Aug 20. I believe that is the official store, but it can be hard to tell on AliExpress.

sl1pkn07 commented 5 years ago

this is the botloader compatible with RET6?

http://docs.leaflabs.com/static.leaflabs.com/pub/leaflabs/maple-bootloader/maple_RET6_boot.bin

taked from here http://docs.leaflabs.com/static.leaflabs.com/pub/leaflabs/maple-docs/latest/bootloader.html because BTT DIP have this https://github.com/bigtreetech/BIGTREETECH-SKR-E3-DIP-V1.0/tree/master/Firmware/mapleDrv-USBdriver

tpruvot commented 5 years ago

you dont need to build it separately... Its included in normal Marlin build/firmware by default (without .py script)

anm8tor commented 5 years ago

@tpruvot the USB composite you refer to, is that using the USB environment in VSCODE to build the firmware, so that you can communicate properly between the SKR Mini boards and say, a RPi (4 in my case) properly?

tpruvot commented 5 years ago

niuuuu.... USB composite i refer to is usb pins without dedicated usb to serial chip (ftdi/ch340cg/... whatever, its not a real problem)

But since a week, its one, i receive at least twice or twelve spams per day regarding a card i dont even own... the E3... dip or not.... which exist since a month or 2 ??

thinkyhead commented 5 years ago

Is it worth adding a special entry to platformio.ini (and extra LD script) for the boards that have a RET6?

tpruvot commented 5 years ago

it might be, but its not so simple as they didnt update their bootloader to allow to flash a bigger firmware via the SD... means you need a stflash if doing that and stop using the custom .py... i do that on my longer3D here to avoid manual copies to a SD.. to the remote printer.

What could be interesting is a generic F103RE entry (64 pins/512kb), without .py, and without .ld so

SSPW commented 5 years ago

it might be, but its not so simple as they didnt update their bootloader to allow to flash a bigger firmware via the SD...

Bootloader seems to work fine when build using RE (512K), with either STM32F103R_bigtree or STM32F103R_bigtree_USB with genericSTM32F103RE.

I also made a new new environment; STM32F103RE_bigtree_USB based on STM32F103R_bigtree_USB with board = genericSTM32F103RE extra_scripts = buildroot/share/PlatformIO/scripts/STM32F1RE_SKR_MINI.py

copy STM32F1_SKR_MINI.py to STM32F1RE_SKR_MINI.py change last line to env.Replace(LDSCRIPT_PATH="buildroot/share/PlatformIO/ldscripts/STM32F1RE_SKR_MINI.ld")

STM32F1RE_SKR_MINI.id to STM32F1_SKR_MINI.id change rom line to rom (rx) : ORIGIN = 0x08007000, LENGTH = 512K - 28K

Builds fine Flashes fine either manually putting bin on SD or dragging it to USB drive.

However, i when i get the firmware and reboot, the firmware.bin file is left on SD. It reflashes every reboot. The FIRMWARE.CUR is missing sometimes. Sometimes its there. But firmware.bin is never deleted.

I don't think this is related. It happens in any ENV i have managed to build.

tpruvot commented 5 years ago

mvoss96 commented 12 days ago

i tried to change it to genericSTM32F103RE and the256k to 512k in STM32F1_SKR_MINI.ld.It does compile, but the board doesnt flash the firmware

the .ld/.py is not required at all, its just made to match the "original" customized bootloaders/firmwares to allow SD updates.

Marlin pio builds can do the whole thing without these custom entries

sjasonsmith commented 5 years ago

However, i when i get the firmware and reboot, the firmware.bin file is left on SD. It reflashes every reboot. The FIRMWARE.CUR is missing sometimes. Sometimes its there. But firmware.bin is never deleted.

I have noticed some similar behavior on both E3 Mini and E3 DIP boards this morning, where the firmware.bin and FIRMWARE.CUR files are updated inconsistently. I don't know whether the firmware update actually occured properly in those cases, although it looked like it at least tried to update.

I'm building with the default bf2 environments, nothing modified for RE.

tpruvot commented 5 years ago

FIRMWARE.CUR is not used by marlin ... at all

SSPW commented 5 years ago

However, i when i get the firmware and reboot, the firmware.bin file is left on SD. It reflashes every reboot. The FIRMWARE.CUR is missing sometimes. Sometimes its there. But firmware.bin is never deleted.

I have noticed some similar behavior on both E3 Mini and E3 DIP boards this morning, where the firmware.bin and FIRMWARE.CUR files are updated inconsistently. I don't know whether the firmware update actually occured properly in those cases, although it looked like it at least tried to update.

I'm building with the default bf2 environments, nothing modified for RE.

i am using E3 Dip also. i tried BigTreeTech fork, genericSTMF1 env, and the SKR, and my modded RE versions. The firmware flashes, manual copy or drag and drop. But the cleanup of firmware.bin and FIRMWARE.CUR is not reliable or repeatable.

sl1pkn07 commented 5 years ago

rom (rx) : ORIGIN = 0x08007000, LENGTH = 512K - 28K

this is all OK? 0x08007000 or 28K not to be also changed?

tpruvot commented 5 years ago

all marlin stm32 firmwares include a "bootloader" code inside... these bootloader customisations are not even required... on the 256k chips, its understandable to save a few KBs.. not on 512k ones

totalretribution commented 5 years ago

it might be, but its not so simple as they didnt update their bootloader to allow to flash a bigger firmware via the SD...

Bootloader seems to work fine when build using RE (512K), with either STM32F103R_bigtree or STM32F103R_bigtree_USB with genericSTM32F103RE.

This is surprising to me as I did the same and all though the build was successful it would not boot. In the end I got a StLink and once I removed the python script from platform.ini the SKR would boot just fine.

SSPW commented 5 years ago

id file is only require for the elf file build. the bin files have no locations.

rom (rx) : ORIGIN = 0x08007000, LENGTH = 512K - 28K

this is all OK? 0x08007000 or 28K not to be also changed?

The bootloader sits at 0x08000000 and requires 0x7000 (28K). The firmware starts at 0x08007000 and is allowed to use the balance of the flast, ie 512K less the 28K (for the bootloader)

tpruvot commented 5 years ago

0x08000000 is the "0" of the flash... when using the stflash it flash from 0 by default, that replaces the "bootloader", but this init code is really short..

sl1pkn07 commented 5 years ago

i mean, that values is for the RCT6, is the same for the RET6? or is generic for all STM32 chips

greetings

tpruvot commented 5 years ago

the .ld is just made to reduce the reserved space of the bootloader... default is.. 0x0800 to 0x0801.

the .ld is only specified by the .py line... so you can remove it for bigger chips... and even "need" to remove it for the RET6 case...

totalretribution commented 5 years ago

Just want to confirm that SSPW method does work as I just tried it, not sure what I had done differently.

Also I just tried removing the python script compleatly as tpruvot suggested and it does not appear to work with the bootloader which is the reverse if using stlink.

tpruvot commented 5 years ago

to explain another case (the Alfawise U20) we only keep the .py file to allow users to flash using the original bootloader... without the need of a 3$ STFlash device so... problem is more the time to get it than the price.. if we ignore the "clones" issue

sl1pkn07 commented 5 years ago

then, yes or yes, the STlink is necessary for the RET6?

tpruvot commented 5 years ago

it is, if you want to use more than 256kb.. they cant update their bootloader as their boards are specified as RCT6.. and half or more of the users have that for now...

for me its just a joke to see that without even a blog news, or explanation on their shops

SSPW commented 5 years ago

I just tried the MAPLE RET bootloader mentioned above. I flashed in on my E3 DIP. It will not load firmware from the SD.

I tried loading my STM32F103RE_bigtree_USB firmware at 0x08007000 but that does not help.

I switched back to the bootloader posted here. https://github.com/bigtreetech/BIGTREETECH-SKR-E3-DIP-V1.0/issues/2

This bootloader is different size (17K) then any of the maple bootloaders (16K)

tpruvot commented 5 years ago

if you want to constrain you to their bootloader and 256kb, in this case, just do nothing... just ignore its a RET6 and it will work the same

sl1pkn07 commented 5 years ago

i want to use the all size

exist the bootloader source code for this board?

tpruvot commented 5 years ago

you dont need it... This board is not a printer, so there is no "standard"... well if you want/need more than 256kb, take a stflash, but marlin cant make it the "normal" case as they dont handle it in their bootloader.

In all cases you need a stflash, to use 512kb

tpruvot commented 5 years ago

take some time to receive them but: https://www.aliexpress.com/item/32277220832.html?spm=a2g0s.9042311.0.0.27424c4dmfmJo4 (tested on the mini, longer3D and even the lerdge boards with some soldering, on the last one)

so yep, you can afford that, its almost the stamp price here.. fyi

sl1pkn07 commented 5 years ago

i have already one unit, thanks :)

totalretribution commented 5 years ago

@sl1pkn07 Just follow SSPW instructions and you can build using the full 512k and the standard bootloader on the E3 dip appears to flash it just fine.

tpruvot commented 5 years ago

then, there are maybe other ways to flash.. but im not sure of that for now... seen the fysetc cheetah which is similar using a flash via the serial/usb port. explained in their wiki https://wiki.fysetc.com/Cheetah_Board/

sl1pkn07 commented 5 years ago

El cargador de arranque parece funcionar bien cuando se compila usando RE (512K), con STM32F103R_bigtree o STM32F103R_bigtree_USB con genericSTM32F103RE.

not for me

Linking .pio/build/STM32F103RE_bigtree/firmware.elf
/home/sl1pkn07/.platformio/packages/toolchain-gccarmnoneeabi@1.70201.0/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld: .pio/build/STM32F103RE_bigtree/firmware.elf section `.data' will not fit in region `rom'
/home/sl1pkn07/.platformio/packages/toolchain-gccarmnoneeabi@1.70201.0/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld: region `rom' overflowed by 31284 bytes
collect2: error: ld returned 1 exit status
*** [.pio/build/STM32F103RE_bigtree/firmware.elf] Error 1

same config as my rearm but with the E3_DIP board

También hice un nuevo entorno nuevo; STM32F103R E _bigtree_USB basado en STM32F103R_bigtree_USB con board = genericSTM32F103RE extra_scripts = buildroot / share / PlatformIO / scripts / STM32F1RE_SKR_MINI.py

copie STM32F1_SKR_MINI.py a STM32F1RE_SKR_MINI.py cambie la última línea a env.Replace (LDSCRIPT_PATH = "buildroot / share / PlatformIO / ldscripts / STM32F1RE_SKR_MINI.ld")

STM32F1RE_SKR_MINI.id a STM32F1_SKR_MINI.id cambie la línea de rom a rom (rx): ORIGIN = 0x08007000, LONGITUD = 512K - 28K

Construye bien Parpadea bien ya sea colocando manualmente bin en SD o arrastrándolo a la unidad USB.

Sin embargo, cuando obtengo el firmware y lo reinicio, el archivo firmware.bin se deja en la SD. Actualiza cada reinicio. A veces falta el FIRMWARE.CUR. A veces está ahí. Pero firmware.bin nunca se elimina.

No creo que esto esté relacionado. Sucede en cualquier ENV que he logrado construir.

this build OK for me

Memory Usage -> http://bit.ly/pio-memory-usage
DATA:    [==        ]  17.5% (used 11472 bytes from 65536 bytes)
PROGRAM: [=====     ]  50.5% (used 264756 bytes from 524288 bytes)
============================================================================================================================================== [SUCCESS] Took 21.26 seconds

SSPW commented 5 years ago

Probably going to require some changes for Flash emulation of EEPROM on F1

in the file pins_BIGTREE_SKR_E3_DIP.h

define FLASH_EEPROM_EMULATION

define EEPROM_PAGE_SIZE uint16(0x800) // 2KB

define EEPROM_START_ADDRESS uint32(0x8000000 + 256 1024 - 2 EEPROM_PAGE_SIZE)

undef E2END

define E2END (EEPROM_PAGE_SIZE - 1) // 2KB

From what i see, the code assumes that there is 256KB of Flash and places the emulated eeprom at the top of this region. This works for the RC.

If we build for the 512K RE, the emulation will overwrite firmware build larger than 252K.

Not a show stopper, but there need to be some changes to use the 512K,

SSPW commented 5 years ago

If your using my STM32F103RE_bigtree_USB build;

you should change the file pins_BIGTREE_SKR_E3_DIP.h

change line 38 that reads

define EEPROM_START_ADDRESS uint32(0x8000000 + 256 1024 - 2 EEPROM_PAGE_SIZE)

to: //#define EEPROM_START_ADDRESS uint32(0x8000000 + 256 1024 - 2 EEPROM_PAGE_SIZE) //use for F103RC

define EEPROM_START_ADDRESS uint32(0x8000000 + 256 2048 - 2 EEPROM_PAGE_SIZE) //use for F103RE

Then eeprom emulation in flash will work, and it will sit at 0x0807D000 rather than 0x0803EA00. You only have to do this if our build is larger than 256KB-28KB-4KB = 224KB If using _USB you probably need it.

sl1pkn07 commented 5 years ago

Hi

is possible, with programation, add the option in the LD file and in the pins_BIGTREE_SKR_E3_DIP.h, for use one or other, if is defined in the platformio.ini, without duplicate the files?

something like (only is a idea, is not real code)

pins_BIGTREE_SKR_E3_DIP.h

#if defined(STMF103RC)
  #define EEPROM_START_ADDRESS uint32(0x8000000 + 256 * 1024 - 2 * EEPROM_PAGE_SIZE) //use for F103RC
#elif defined(STMF103RE)
  #define EEPROM_START_ADDRESS uint32(0x8000000 + 256 * 2048 - 2 * EEPROM_PAGE_SIZE) //use for F103RE
#endif

STM32F1RE_SKR_MINI.id

#if defined(STMF103RC)
  MEMORY
{
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 48K - 40
  rom (rx)  : ORIGIN = 0x08007000, LENGTH = 256K - 28K
}
#elif defined(STMF103RE)
  MEMORY
{
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 48K - 40
  rom (rx)  : ORIGIN = 0x08007000, LENGTH = 512K - 28K
}
#endif

platformio.ini

[env:STM32F103RC_bigtree]
platform          = ststm32
framework         = arduino
board             = genericSTM32F103RC
platform_packages = tool-stm32duino
extra_scripts     = buildroot/share/PlatformIO/scripts/STM32F1_SKR_MINI.py
build_flags       = !python Marlin/src/HAL/HAL_STM32F1/build_flags.py
  ${common.build_flags} -DDEBUG_LEVEL=0 -DSTMF103RC -std=gnu++14
build_unflags     = -std=gnu++11
lib_deps          = ${common.lib_deps}
lib_ignore        = Adafruit NeoPixel, SPI
src_filter        = ${common.default_src_filter} +<src/HAL/HAL_STM32F1>
monitor_speed     = 115200
upload_protocol   = stlink
debug_tool        = stlink

[env:STM32F103RC_bigtree_USB]
platform          = ststm32
framework         = arduino
board             = genericSTM32F103RC
platform_packages = tool-stm32duino
extra_scripts     = buildroot/share/PlatformIO/scripts/STM32F1_SKR_MINI.py
build_flags       = !python Marlin/src/HAL/HAL_STM32F1/build_flags.py
  ${common.build_flags} -DDEBUG_LEVEL=0 -DUSE_USB_COMPOSITE -DSTMF103RC -std=gnu++14
build_unflags     = -std=gnu++11
lib_deps          = ${common.lib_deps}
lib_ignore        = Adafruit NeoPixel, SPI
src_filter        = ${common.default_src_filter} +<src/HAL/HAL_STM32F1>
monitor_speed     = 115200
upload_protocol   = stlink
debug_tool        = stlink

[env:STM32F103RE_bigtree_USB]
platform          = ststm32
framework         = arduino
board             = genericSTM32F103RE
platform_packages = tool-stm32duino
extra_scripts     = buildroot/share/PlatformIO/scripts/STM32F1_SKR_MINI.py
build_flags       = !python Marlin/src/HAL/HAL_STM32F1/build_flags.py
  ${common.build_flags} -DDEBUG_LEVEL=0 -DUSE_USB_COMPOSITE -DSTMF103RE -std=gnu++14
build_unflags     = -std=gnu++11
lib_deps          = ${common.lib_deps}
lib_ignore        = Adafruit NeoPixel, SPI
src_filter        = ${common.default_src_filter} +<src/HAL/HAL_STM32F1>
monitor_speed     = 115200
upload_protocol   = stlink
debug_tool        = stlink

MarlinFirmware / Marlin

[FR] Need fixes for BTT SKR Mini E3 having a different MCU #15254

define FLASH_EEPROM_EMULATION

define EEPROM_PAGE_SIZE uint16(0x800) // 2KB

define EEPROM_START_ADDRESS uint32(0x8000000 + 256 1024 - 2 EEPROM_PAGE_SIZE)

undef E2END

define E2END (EEPROM_PAGE_SIZE - 1) // 2KB

define EEPROM_START_ADDRESS uint32(0x8000000 + 256 1024 - 2 EEPROM_PAGE_SIZE)

define EEPROM_START_ADDRESS uint32(0x8000000 + 256 2048 - 2 EEPROM_PAGE_SIZE) //use for F103RE