Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Support 512K "RCT6" in BTT SKR Mini #15890

Conversation

thisiskeithb
Copy link
Member

@thisiskeithb thisiskeithb commented Nov 13, 2019

Description

BigTreeTech's SKR Mini line of boards with STM32F103RCT6 MCUs can use 512k of flash (and potentially 64k of ram, but is untested/implemented in this PR) as if they were fitted with an STM32F103RET6.

This is similar to the double flash "feature" of STM32F103C8T6/bluepill boards.

USB is also now enabled by default since we don't have to worry about space.

*Thanks to @AletheianAlex via this video & addendum, @steenerson via this reddit thread , and reddit user yuchen_ting for initially posting about this.

Benefits

image

Related Issues

#15254, #15398

@damvcoool
Copy link

damvcoool commented Nov 13, 2019

the SKR Mini E3 v1.2 actually has 256k, since it uses STM32F103RCT6, according to the STMicroelectronics product site.

I believe some SKR Mini E3 were shipped with STM32F103RE variant which does have 512k, but that's the exception not the rule.

Edit: forgot to add the link to STMicroelectronics product site.
https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html#products

@thisiskeithb thisiskeithb force-pushed the pr/aleix_isnt_wearing_pants_btt_512k branch from 9573029 to c947ca8 Compare November 13, 2019 14:50
thisiskeithb and others added 2 commits November 13, 2019 06:51
Co-authored-by: AletheianAlex <6373527?+AletheianAlex@users.noreply.github.com>
Co-authored-by: steenerson <13660022?+steenerson@users.noreply.github.com>
@thisiskeithb thisiskeithb force-pushed the pr/aleix_isnt_wearing_pants_btt_512k branch from c947ca8 to 2544618 Compare November 13, 2019 14:51
@thisiskeithb thisiskeithb changed the title BigTreeTech SKR Mini has 512k Flash BigTreeTech SKR Minis have 512k Flash Nov 13, 2019
@TheZoker
Copy link

TheZoker commented Nov 13, 2019

@damvcoool Yes but the point is, that version 1.2 with the F103RC still has 512kb, have a look at this Reddit thread where the guys confirmed this:
https://www.reddit.com/r/ender3/comments/dsmf6x/512k_flash_working_on_skr_mini_e3_v12/

@thisiskeithb thisiskeithb force-pushed the pr/aleix_isnt_wearing_pants_btt_512k branch from f82d6c8 to f24b3ee Compare November 13, 2019 16:08
@thisiskeithb thisiskeithb force-pushed the pr/aleix_isnt_wearing_pants_btt_512k branch from f24b3ee to 8c1974d Compare November 13, 2019 17:09
@sjasonsmith
Copy link
Contributor

@damvcoool Yes but the point is, that version 1.2 with the F103RC still has 512kb, have a look at this Reddit thread where the guys confirmed this

It seems risky to use more than the documented amount of flash by default. It is the equivalent of overclocking a CPU. It might work for some chips, but isn't guaranteed to work for all.

For example, they may allow failures in half their flash and bin those parts to the RC part number, even though the chip is otherwise the same as an RE. Some users might have a perfectly reliable 512k, while other users may have a reliable 256k and a flaky 256k.

They might even design their chip to allow either half of the flash to fail testing, and they choose which half to enable when they package the die. Depending on which half is enabled you may or may not even have the other half connected.

Maybe none of this is happening, but it is a risk we take by using these chips off-spec.

@sjasonsmith
Copy link
Contributor

I do support giving people the option to build with 512k if they choose, without making it the default for RC chips. Both my mini boards have RE chips on them, so it would be nice to easily make use of the space, or allow users with RC chips to attempt it if they choose.

@TheZoker
Copy link

@sjasonsmith I totally agree

@steenerson
Copy link

Thanks for prettying this up!

This has been done with bluepill F103C8 boards going back years, and I spent 20 minutes searching last week and couldn't find a single example of anyone posting that they didn't have the doubled space available or that it didn't work correctly. I personally think ST would have fully masked these to 256K chips and not just left it available but undocumented if they weren't sure the full 512K was working, there's just too much downside to shipping unverified hardware. They even report the full size if you connect to the USART bootloader instead of st-link.

That being said, I tend to agree that 256K vs 512K should still be left as an option. I was thinking about making 256K default but adding a compile error for >224K program size that suggests trying 512K and making the change to 512K be a single config option somewhere. But haven't gotten anywhere with it.

@thisiskeithb
Copy link
Member Author

thisiskeithb commented Nov 13, 2019

This has been done with bluepill F103C8 boards going back years,

I'm usually one for being cautious with things affecting lots users, but this is why I made it default. We can always make it an option if it becomes an issue.

@swilkens
Copy link
Contributor

swilkens commented Nov 13, 2019

Enable SKR Mini USB by default

It is wise to switch to this if the OEM manuals assume we default to non-usb? (i.e. the last section of this https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/tree/master/firmware/V1.2)

Unless I misunderstand the implication of USB by default. As I understand it, this uploads the firmware over USB ready for flash on reboot as part of the PlatformIO build?

@thisiskeithb
Copy link
Member Author

It is wise to switch to this if the OEM manuals assume we default to non-usb? (i.e. the last section of this https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/tree/master/firmware/V1.2)

That guide is out of date since you no longer have to add in BigTreeTech's custom stepper library. It was also probably conservative about space since enabling USB on 256k chips ate up a lot of storage.

@swilkens
Copy link
Contributor

It is wise to switch to this if the OEM manuals assume we default to non-usb? (i.e. the last section of this https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/tree/master/firmware/V1.2)

That guide is out of date since you no longer have to add in BigTreeTech's custom stepper library. It was also probably conservative about space since enabling USB on 256k chips ate up a lot of storage.

While that's certainly true, I also no longer use it, everybody buying this board is still being directed there.

@thisiskeithb
Copy link
Member Author

BigTreeTech’s repo lags behind this one, so hopefully the guide will be updated once they pull in upstream changes.

@tpruvot
Copy link
Contributor

tpruvot commented Nov 14, 2019

all the shops show RCT6 chip, i dont agree forcing to 512K by default without ability to easily swap (.ld etc) its a mistake imo

@thinkyhead
Copy link
Member

all the shops show RCT6 chip

One point of the OP is that the chips marked "RCT6" on these boards have been found to actually have 512K. So the markings on the chip are not meaningful.

@sl1pkn07
Copy link
Contributor

#15254

Related

Still need more info about bootloader

@thinkyhead
Copy link
Member

So, simplest approach here is to make an extra environment, and use -DSTM32_FLASH_SIZE=256 or -DSTM32_FLASH_SIZE=512 to specify the flash space for each. If added to the linker flags, the .ld file can get this value and use #if/#endif too.

@tpruvot
Copy link
Contributor

tpruvot commented Nov 14, 2019

i fear read/write to upper 256Ks on RCT6 might overwrite first bytes.. like the fake SD cards....

seems very weird to me if that is true... may be fake/chinese STM32 chips else

@thinkyhead
Copy link
Member

Please watch the linked video in which it is tested so we all are on the same page. https://www.youtube.com/watch?v=EBIahC1P2e0

@b-desconocido
Copy link

i fear read/write to upper 256Ks on RCT6 might overwrite first bytes.. like the fake SD cards....

seems very weird to me if that is true... may be fake/chinese STM32 chips else

I'm using 128K of flash memory on legit STM32F103C8T6 for years without any issues, although datasheets specified 64K of flash memory. Many of Chinese manufacturers exploited this "feature" too, for example some smart soldering stations and transceiver modules for RC remote controllers. Original ST-Link V2 + STM32 ST-Link Utility indicated 128K of memory too, you could write whatever you want to upper memory region and read it back again. Someone could attach ST-Link V2 to SKR mini e3 v1.2, which has RCT6 chip on-board to confirm STM32 ST-Link Utility displays 512K instead of 256K of flash and post a photo + screenshot here. I'm way too lazy to disassemble my printer again

@saeugetier
Copy link
Contributor

saeugetier commented Nov 19, 2019

So it would be really nice if you would provide the patch, or a short guide on how to do this with radare2. :)

I'll just provide my patched bootloader plus my custom firmware (sorry, I haven't truncated this file):
bootloader.zip

For anybody, who want's to figure out, what I have done: I looked for places, where the values 0x08007000 (start address of application) and 0x08040000 (end address of memory) are located. Then I looked where the addresses of that places are used and disassembled the source in that locations. I saw that 0x08040000 was subtracted by 0x08007000. So I assumed that this is a length calculation. Changing the value 0x08040000 to 0x08080000 unlocked flashing up to 512kb. That was quite easy.

I don't write down, what commands I have used in radare2. You can look them up in the r2 manual.

@sl1pkn07
Copy link
Contributor

So it would be really nice if you would provide the patch, or a short guide on how to do this with radare2. :)

I'll just provide my patched bootloader plus my custom firmware (sorry, I haven't truncated this file):
bootloader.zip

also not works for me

└───╼  openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c "program bootloader.bin reset exit 0x08000000"
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v21 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.274332
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800014c msp: 0x20000098
** Programming Started **
auto erase enabled
Info : device id = 0x10036414
Info : flash size = 512kbytes
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20000098
wrote 262144 bytes from file bootloader.bin in 10.823650s (23.652 KiB/s)
** Programming Finished **
** Resetting Target **
shutdown command invoked

put my firmware firmware.zip in the SD. restart the unit, sound the speaker fast, and then white screen :S

@thisiskeithb
Copy link
Member Author

also not works for me

This is why the feature is optional. It doesn't work for everyone, unfortunately.

@mark078
Copy link

mark078 commented Nov 20, 2019

I'll just provide my patched bootloader plus my custom firmware (sorry, I haven't truncated this file)

Thanks first @saeugetier for providing the FW or bootloader.
I will try this on my STM32F103RET6 skr e3 dip board tomorrow, then I get the stlink v2 clone.

radare2 is already hard, if you have never done anything in this direction before. :-D
Am I on the right way?

$ r2 -a arm -b 16 -w bootloader-bigtreetech-e3-dip.bin -m 0x08040000
[0x08040000]> e asm.cpu = cortex
[0x08040000]> aaaa
[0x08040000]> s fcn.08040000
[0x08040000]> pd $r

My ra2 Screenshots

What surprises me is that your FW has a value "9800" and mine (bootloader-bigtreetech-e3-dip.bin) "981c", so from the right of 0x08040000 in the screenshot.

And you read out the range from (Value from 0x08080000 to 0x080842c8) and overwritten it to (0x08040000 to 0x080442c8), is it right?

I still have to figure out how to do that. But first, I test your FW...
...and sorry for the little off topic.

@sl1pkn07 have you tried to flash the Marlin firmware via stlink without touching the bootloader?

@sl1pkn07
Copy link
Contributor

sl1pkn07 commented Nov 20, 2019

Yes, zero problems (flash step) in all cases, except one bootloader pasted in the BTT issue bigtreetech/BIGTREETECH-SKR-E3-DIP-V1.0#2 (comment)

@brew99
Copy link

brew99 commented Nov 20, 2019

Through all of the posts here I was able to get my E3 V1.0 with RCT6 unlocked above the 224kB threshold. With the use of the STlink V2 I was able to read a full 512kB, but the bootloader appeared to have it locked down so it wouldn't look at firmware.bin above 228kB.

With STlink I was able to find that near address 0x000012B8 the value was set to 08040000 (256kB), so I changed that to 08080000 (512kB), saved and programmed. Took a firmware.bin at 230kb and it loaded as per normal. Not sure if this is a valid way, but it was interesting.

IMG_0021

Also tried @steenerson V1.2 bootloader and that also worked (which I'm running now).

Thanks all

@saeugetier
Copy link
Contributor

With STlink I was able to find that near address 0x000012B8 the value was set to 08040000 (256kB), so I changed that to 08080000 (512kB), saved and programmed. Took a firmware.bin at 230kb and it loaded as per normal. Not sure if this is a valid way, but it was interesting.

Sounds legit. I changed the value at this address, too. That unlocked the bootloader to accept 512kb.

@sl1pkn07
Copy link
Contributor

is strange. open the bootloader 1.2 in STM32 st-link utility (windows), in the direction 12B8, in the 8 colum, say cleary 0808000. but i'm really sure NOT works for me.

@mark078
Copy link

mark078 commented Nov 21, 2019

I received stlink today and the value under 0x000012B8 is already entered under 08080000.
Maybe it's because I have one RET6, the other RCT6.

And @sl1pkn07 seems to have a RET6, too?

Screenshot 2019-11-21 12 30 10

@sl1pkn07
Copy link
Contributor

I have RET6, yes

@mark078
Copy link

mark078 commented Nov 21, 2019

A larger (244KB) firmware over stlink flash works for me too.

Flashing over the SD card doesn't work for me anymore.
Why I don't know. But it is not so important for me, because stlink is sufficient.
The SD card slot still works, so that's not the reason.

Can anyone tell me how to address the second UART port in Marlin?
So RX2 and TX2? Would like to try ESP3D with an ESP32.

Is this enough?

#define SERIAL_PORT 1 
#define SERIAL_PORT_2 2 

https://github.com/bigtreetech/BIGTREETECH-SKR-E3-DIP-V1.0/blob/master/Hardware/SKR-E3-DIP-V1.0-SCH.pdf

@wieltar
Copy link

wieltar commented Nov 22, 2019

I have an e3 dip (ordered quite a while ago when it came out) How would I validate that the memory of it extends to 512? I have the rct6 variant of the chip so before i start flashing anything I'd like to know im not going to break anything. Preferably without ordering anything new.

I know it's from Malaysia but that's about it.
the markings on the chip are as follows
ARM3
STMT32F103
RCT6
99222 98
MYS 99 837

@brew99
Copy link

brew99 commented Nov 22, 2019

@wieltar The easiest way is to compile a firmware.bin file that is bigger than 224kb using one of the 512K default env. in platformio file. If the bootloader reads the firmware file, it will take the approx. 15 sec before you get the regular Marlin screen. If the bootloader doesn't, then it will just start up as per normal. You cannot hurt/brick it by trying firmware.

If it is one of the early runs, then it more than likely has the "locked to 256" bootoloader, and you would then need additional hardware (i.e. STlink V2) to be able to read/write to the bootloader. I have the same early run DIP unit (and also an early run E3), and both of mine were locked down.

@Hukuma1
Copy link

Hukuma1 commented Nov 25, 2019

I'm confused on which env to use. BTT official just updated their readme and it states to use _NOUSB variant (https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/tree/master/firmware/V1.2). Can someone please explain what the difference is? Is this if you do not plan on using the USB port the board comes with? Any penalty (besides the memory space) from enabling the USB?

@swilkens
Copy link
Contributor

swilkens commented Nov 25, 2019

I'm confused on which env to use. BTT official just updated their readme and it states to use _NOUSB variant (https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/tree/master/firmware/V1.2). Can someone please explain what the difference is? Is this if you do not plan on using the USB port the board comes with? Any penalty (besides the memory space) from enabling the USB?

The _NOUSB variant gives you only a serial port when you connect the board to the PC using a USB cable. This is the classic setup you are used to.

The other variant (without the _NOUSB tag) gives you a serial port AND gives you a removable storage drive of your printer's SD card when you connect to the board with a USB cable. This lets you use the serial port as well as transfer over files to the SD card over the USB cable.

The naming is a little unclear, I agree.

@Hukuma1
Copy link

Hukuma1 commented Nov 25, 2019

Ah thank you! So all the bells and whistles (with plenty of memory to spare) would be: STM32F103RC_bigtree_512K

@sl1pkn07
Copy link
Contributor

sl1pkn07 commented Dec 1, 2019

anyone can test this?

https://github.com/sl1pkn07/SKR_E3_DIP_Bootloader

i'm not coder, only just edit to build in actual systems

builded with STM32CubeIDE 1.1.0

philippniethammer pushed a commit to philippniethammer/Marlin that referenced this pull request Dec 21, 2019
christran206 pushed a commit to christran206/Marlin2.0-SKR-Mini-E3-1.2 that referenced this pull request Dec 30, 2019
@wieltar
Copy link

wieltar commented Jan 18, 2020

I just got my stlink clone in the mail and i looked into flashing a new bootloader for my e3 dip 1.0 since it is "locked down" but it does have the 64k of ram available.

I have no clue on how to "unlock" the bootloader and verify a flashed firmware.bin without accidentally overriding the bootloader since it's all hex mumbo to me. Can anyone tell/guide me, how to use st link utility and flash the new firmware/bootloader?

thisiskeithb referenced this pull request in bigtreetech/BIGTREETECH-SKR-mini-E3 May 3, 2020
Floppy added a commit to Floppy/Marlin that referenced this pull request Jun 28, 2021
Some boards have 512k of available memory, not 256k, and need the RE build to make use of it. See MarlinFirmware#22050 for discussion and testing, and MarlinFirmware#15890 for the original discussion of 1.2 RET6 boards.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet