Support 512K "RCT6" in BTT SKR Mini

[thisiskeithb]

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

Related Issues

#15254, #15398

[damvcoool]

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

[TheZoker]

@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/

[sjasonsmith]

@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]

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]

@sjasonsmith I totally agree

[steenerson]

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]

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]

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]

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]

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]

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

[tpruvot]

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]

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]

#15254

Related

Still need more info about bootloader

[thinkyhead]

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]

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]

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]

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]

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]

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]

also not works for me

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

[mark078]

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]

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]

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.

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

Thanks all

[saeugetier]

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]

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]

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?

[sl1pkn07]

I have RET6, yes

[mark078]

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]

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]

@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]

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]

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]

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

[sl1pkn07]

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

[wieltar]

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?