Marlin: [BUG] Marlin on BigTreeTech SKR PRO can't be configured to use the onboard SD-card

[eightheads]

Description

Bigtreetech SKR Pro control board(STM32F4) does not seem to hold SD-based EEPROM to the on-board card.

Steps to Reproduce

1. Load lastest Marlin 2.0 to SKR Pro
2. Make change via LCD to z-offset, etc, and Save to EEPROM
3. Power cycle board. Settings have now reverted to initial(firmware) values

Expected behavior: Settings to EEPROM should save between power cycles

Actual behavior: Settings revert to initial firmware values after power cycle
Configs.zip

[tpruvot]

if your sdcard is empty (no gcode file) it may cause an issue to save/load the eeprom.dat

[tpruvot]

But im not sure the F4/F7 can emulate that on the sdcard, seems a F1 feature

[eightheads]

if your sdcard is empty (no gcode file) it may cause an issue to save/load the eeprom.dat

The onboard SD card just has the boards firmware on it. I do not currently have an external SD in my LCD currently.

[tpruvot]

on the F4.. its emulated in the SoC flash, not on the SD

[dch1921]

I'm seeing the same issue with the SKR Pro 1.1 Does not save changes to eeprom with M500

[LinoBarreca]

why don't you just take the
Marlin/Marlin/src/HAL/HAL_STM32F1/persistent_store_sdcard.cpp which is a F1 platform feature and put it "a level UP" in the /shared features among the SpiEeprom.cpp and I2CEeprom.cpp defining it as VirtualSDEeprom.cpp?

This way you could
#define VIRTUAL_SD_EEPROM 8 (where 8 = 8*512bytes = 4kb user defined eeprom file)
in Configuration.h and use the sdcard instead of a real EEPROM chip on ANY platform/controller which has limited writes before you have to replace the whole board
For platforms which have a real EEPROM chip you can use that OR the virtual eeprom on the SD (user preference).
For platforms which don't have a real EEPROM you would force the define in the platform HAL layer.

And everyone would be happy.

Also...this could allow easy "eeprom" backup/restore from the sdcard: if your printer controller suddenly fails (I.E. a voltage regulator or a burnt IO port on the cpu) or you simply want to do an upgrade of your controller you can replace the board and have the same settings you had before the replacement (z-probe offset, bed mesh, speeds, steps, jerks and so on)

Considering this all, the only reason the user could still choose the "internal eeprom" is if he frequently swaps sd cards.

[LinoBarreca]

Apparently someone has done it at the "platform" level.
https://github.com/bigtreetech/BIGTREETECH-SKR-PRO-V1.1/pull/21/files
I wouldn't still merge this into marlin because I still think that EEPROM emulation should be handled at a global level and not at a platform level.

[TheWeakBerlin]

Any news on that Topic?

i just bought the SKR PRO Board and it runs well with Marlin 2.0.x i can store Data with M500 on a SD-Card but after shut down the Printer it will not load the Data (Mesh Data for example) but on the SD the eeprom.dat file is still there.

Do i need to implement the "platform level" solution into my version or is there something i missed?

in Configuration.h i set EEPROM_SETTINGS
and at pins_BIGTREE_SKR_PRO_V1.1.h i tried both SRAM_EEPROM_EMULATION and FLASH_EEPROM_EMULATION, with no difference in behavior.

Greetings from Germany :D

EDIT: i just saw the "Platform Level" solution is allready there

[tpruvot]

There was a config storage version change last week end.. to V69. When that happens, the SD or FLASH (or whatever) cant be loaded... need a reset

[boelle]

@eightheads still having problems?

[eightheads]

@eightheads still having problems?

As far as I know this is still an issue in the main Marlin branch.

[boelle]

@eightheads have you tested it?

[reloxx13]

still wont load config after restart.

[TheWeakBerlin]

I still have Problems too, if i use SRAM_EEPROM_EMULATION i get the version error with V69 of the EEPROM and if i use the FLASH_EEPROM_EMULATION it only loads old data but dont want to store new data.

[Evg33]

#define EEPROM_SETTINGS
#define EEPROM_CHITCHAT       // Give feedback on EEPROM commands. Disable to save PROGMEM.
#define FLASH_EEPROM_EMULATION  // Use Flash-based EEPROM emulation

no problems

[dineshvyas]

THIS SHOULD WORK

[eightheads]

THIS SHOULD WORK

This would enable Flash based EEPROM emulation, not SD card EEPROM emulation though, correct?

[dineshvyas]

THIS SHOULD WORK

This would enable Flash based EEPROM emulation, not SD card EEPROM emulation though, correct?

Correct.

[dineshvyas]

I still have Problems too, if i use SRAM_EEPROM_EMULATION i get the version error with V69 of the EEPROM and if i use the FLASH_EEPROM_EMULATION it only loads old data but dont want to store new data.

FLASH_EEPROM_EMULATION is working fine for me, stores new data too.

[AnHardt]

The last time i tried EEPROM from SD-card worked.
But only from the external card-reader on the display panel - not from the on-board-slot.
But that's not a fault of the SD-EEPROM emulation but a more general on-board SD problem.

[tpruvot]

There was a lot of changes recently on the data storage, we are at v70, but there was other changes in the structure since... each time its reset... Are you sure its not your problem ?

[dineshvyas]

SD EEPROM is not supported on STM32F4. it is only supported on STM32F1, so not on SKR PRO V1.1

[tpruvot]

some F4 seems to have it, but maybe not the SKR... due to framework differences cf #14808 & #14844

[AnHardt]

@dineshvyas
Don't be ridicules. It works on the external SD at SKR PRO 1.1!

[dineshvyas]

@dineshvyas
Don't be ridicules. It works on the external SD at SKR PRO 1.1!

I have no such intention to ridicule. i just stated what I read. it was about on board sd card. I am not an expert, I am just looking for a solution. I apologize if by any mean I made you feel bad.

[AnHardt]

The problem with "fake news" is - it spreads faster than the truth.
In a short while we will not believe in anything we read - only in our own experience.

[boelle]

@eightheads still having issues?

[boelle]

This would enable Flash based EEPROM emulation, not SD card EEPROM emulation though, correct?

correct

[dineshvyas]

Did anyone try SPI SDCARD or SPI EEPROM? SPI PINS are shared for TMC Stepper Motor Drivers, I2C EEPROM can be hooked?

[rflulling]

Just jumping in here. New addition to owners of one of these cards. The card has a bootloader.

My perception is that this is THEIR firmware that we cannot change. It managed your new firmware.bin file and changes the name of that file to FIRMWARE.CUR after it's been loaded. This bootloader also denies any direct access to the MCU. I have tried an STM programmer that should have been able to see the bootloader. No game, cant see a thing. 'It's the useless machine where when you press the switch to open the door a hand comes and flips the switch back.' I am sure there are more reasons why the bootloader is needed and or useful. For the moment I can only describe what I see. I have aksed for this booloader to be altered slightly so we can flash the Firmware or at least have access to the SD card in some way on the PC so we do not have to remove it at every tweak to the firmware. So far all contact has been ignored. So far while some user want this fix, many seem content to defend having to pull the card out without giving reason why its better.

I have read that on user was able to upload with BFU. But I was not able t confirm this. Attempts to use resulted in a port not found error.

The PlatformIO.ini spells out contact with the card as being CDC, and this is reflected in windows devices. Though so far it only accepts commands from the Slicer and nothing more.

Also keep in mind that BIQU says that their SKR PRO branch is not yet merged. While I have seen evidence that this is happening or looks like it. Certainly many changes have happened that seem to support the SKR PRO. I am not sure what all is done and how far that merger has progressed.

[rflulling]

In this case you are placing the firmware on the External SD card (SD1), by
activating Marlin support for USB transfer to the external card, correct?
You are not talking directly to the onchip flash or the built in SD card
slot (SD0)? Once you have transferred to SD1 then by use of command M997,
it is looking for the Firmware on your SD1 rather than SD0 where the
bootloader looks for it, correct?

On Fri, Oct 18, 2019 at 8:42 AM reloxx13 [e-mail] wrote:

@rflulling https://github.com/rflulling its working fine to mount the
usb with usb_composite on.

i have it mounted on my pi with octoprint and update it with the octoprint
firmware flasher plugin.
it copies the firmware to the mounted sd card and triggers a M997 update
firmware command.
it will reboot and flash.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/14684?email_source=notifications&email_token=AI2WIQXDUPOU324725MX7MTQPG4L3A5CNFSM4IFLWW6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBUQH2Q#issuecomment-543753194,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AI2WIQTDCDRUYYLHC2SV34DQPG4L3ANCNFSM4IFLWW6A
.

[AnHardt]

No.
Drawing conclusions from already deleted messages, (likely because of dealing with an other board) does not make any sense.

The BTT SKR PRO bootloder can only deal with the onboard SD. It can update the firmware for the board and the WiFi board from the onboard SD. Nothing else.

Marlin (currently) can not deal with the onboard SD. (Currently) there is no way to access the onboard SD from Marlin. There is no way to place the firmware.bin on the onboard SD other than copy the files via a PC cardreader. Neither the BTT SKR PRO bootloader nor Marlin (currently) can flash from the extarnal SD. Since some days Marlin (on the BTT SKR PRO) can reset it selfes by M997. That's a first step to conveniently flash Marlin without pressing the reset button or drawing/resetting the power plug.

To conveniently transfer any file to a accessible SDcard a USB disk device must be added to the existing USB serial device in Marlin. For the used STM core not even a example composite device exist - so it will take a while to realize this.

The fix, builtin all STM32 processors bootloader, can not flash from any SD, but from USB and one serial, but needs to previously set BOOT0 and BOOT1 pins to a patter to do anything but calling the user program (here the BTT bootloader). Only flashing via a ST-Link adapter is accepted without a special pattern on these pins.

---

Once the boot process has left both of the bootloaders the processor has the total freedom to set about any bit any where. Writing to read only memory (ROM) is still impossible (ST bootloader). Writing to flash is always a bit more complicated but possible as long the target addresses are not write protected via a register in the processor. Non of the involved bootloaders alters one of this protection bits (even if protecting the BTT bootloader would make sense when playing with a ST-Link or the ST bootloader.).

---

Back to the title of this issue.

[BUG] SD-EEPROM not with Bigtreetech SKR Pro(STM32F4) on-board SD card?

Yes there is a problem. But its likely to be not the fault of EEPROM code but Marlins current inability to access the onboard SD-card at all.

This issues title should be:
"[BUG] Marlin on BigTreeTech SKR PRO can't be configured to use the onboard SD-card"

When that problem is solved, likely the onboard SD-EEPROM problem is also solved.

[boelle]

@AnHardt thanks for the suggestion of a better title. Do you know what is wrong so it can be fixed?

[rflulling]

@AnHardt I think if this were entirely a Marlin code fault, then a person would be able to use standard ST STM32 utilities to access the chip. But we cannot. "It is locked." The bootloader placed by BTT in factory ONLY talks to the onboard SD card (SD0). I have been asking that the bootloader be modified in some way to allow the SD card to be seen externally, even of as a stand in for the onchip flash. Something, anything, so that the card does not have to be removed each and every time.

Some have reported using DFU and getting an upload, and I have seen a developer with SMSIS-DAP.
-I have not gotten DFU to work yet. I have not tested SMSIS. However I did notice that a file in a recent nightly built now included a dependency for a SMSIS as part of the serial communications. So I will be tinkering soon.

"frameworks": [ "arduino", "cmsis", "stm32cube"],
"protocols": [ "stlink", "dfu", "jlink"],

I have also read that users have been able to enable the SD card (SD1) on LCD or some other, as I have, the send the firmware file over as any uploaded G-Code. Then use the command to instruct a firmware update from SDCard.

If I can find a way to do this. All of you Devs reading can be 100% certain I will report it. I do not like to pull the SD card every time. I know I am not alone.
Although I feel often that as I am posting, most are resigned to giving up, and so I simply cannot drum up the support that I feel should be out there. The kind of noise that would get BTT to take notice and either give an explanation for the lock, or make a fix.

[Patag]

Same here 👍 @rflulling

[rflulling]

Another user/dev pointed me at this today.
https://github.com/stm32duino/Arduino_Core_STM32/pull/586?fbclid=IwAR1GvDz5HiDAWuQtkBA7rNXwxFFljfxs5uniqTEglpkzOGKOIOf2dSfIKCY

[carl1961]

your link is not working as is, so here it is. and Thanks for your work at
pushing this.
https://github.com/stm32duino/Arduino_Core_STM32/pull/586?fbclid=IwAR1GvDz5HiDAWuQtkBA7rNXwxFFljfxs5uniqTEglpkzOGKOIOf2dSfIKCY

On Sun, Oct 27, 2019 at 4:40 PM rflulling [e-mail] wrote:

Another user/dev pointed me at this today.

https://github.com/stm32duino/Arduino_Core_STM32/pull/586?fbclid=IwAR1GvDz5HiDAWuQtkBA7rNXwxFFljfxs5uniqTEglpkzOGKOIOf2dSfIKCY
http://url

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/14684?email_source=notifications&email_token=AAXKJNNEWSOHBPVSSH3IFD3QQYDDZA5CNFSM4IFLWW6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECLIZTQ#issuecomment-546737358,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXKJNN2F2F57IKQTL4B27LQQYDDZANCNFSM4IFLWW6A
.

[xC0000005]

Does someone have the SKR bootloader? I'll look and see how it accesses the SD card and what state it leaves it in.

[Evg33]

Does someone have the SKR bootloader

fw_stlink.zip
My dump via st-link
SKR Pro 1.1
Marln from 08000h

[rflulling]

observation seems to indicate that the boot loader only looks at the onboard SD card at reset. It looks for specific files. If they are not found it disconnects the card and continues with startup. If the files are found they are installed. The previous copy is replaced, and the new one is renamed from firmware.bin to FIRMWARE.CUR. After this is done the card is disconnected.

[dineshvyas]

BTT SKR_PRO is hardwired to drive developers/users crazy. My on board card reader is broken due to repeated injecting and inserting. @bigtreetech if you are reading this. Do something about it.

[Evg33]

@dineshvyas Thanks for the information ! I urgently need to add this:

[LinoBarreca]

@Evg33 it should come bundled with the board. LOL

[Evg33]

@xC0000005 https://github.com/bigtreetech/BIGTREETECH-SKR-PRO-V1.1/issues/25

[Evg33]

The bootloader also updates the ESP-01S with the esp3d.bin file.
This can be ignored.

[xC0000005]

I think the onboard SD card is attached to SPI and that PA4 is the CS pin for it, but I don’t have one of these, so I can’t modify the pins to set SS to PA4 and enable SD support (not SDIO).

On Oct 28, 2019, at 8:31 PM, DPrime [e-mail] wrote:

BTT SKR_PRO is hardware to drive developers/users crazy. My on board card reader is broken due to repeated injecting and inserting. @bigtreetech https://github.com/bigtreetech if you are reading this. Do something about it.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/14684?email_source=notifications&email_token=AHVGS4MDTIYE67X4UR25E7LQQ6VC5A5CNFSM4IFLWW6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECPDWZY#issuecomment-547240807, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4NNWJCD3JOFSKRJFQLQQ6VC5ANCNFSM4IFLWW6A.

[Evg33]

@xC0000005

https://github.com/bigtreetech/BIGTREETECH-SKR-PRO-V1.1/blob/master/Schematic/SKR-PRO-V1.1%EF%BC%88SCH%EF%BC%89.pdf

[xC0000005]

Has anyone actually tried setting the SS/SPI pins right and just using the onboard SD? We’d still need composite for access to multiple cards (or something similar to the SERIAL macros with instances of the card reader) but this kind of SD access is one of the oldest working ones on STM32.

On Oct 29, 2019, at 10:52 AM, Evgeny Zyatkov [e-mail] wrote:

https://user-images.githubusercontent.com/7160738/67794328-87f7af80-fa8d-11e9-9f6d-4aed67ce2350.png
https://user-images.githubusercontent.com/7160738/67794465-be352f00-fa8d-11e9-977f-9cc0f32f2c31.png
https://user-images.githubusercontent.com/7160738/67794532-dad16700-fa8d-11e9-91d5-f97029951c09.png
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/14684?email_source=notifications&email_token=AHVGS4IN2JOIUI2KLEKXNLDQRBZ6PA5CNFSM4IFLWW6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECRPFOA#issuecomment-547549880, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4I2DBHUKAHOZB5HCS3QRBZ6PANCNFSM4IFLWW6A.

[boelle]

@eightheads many updates have passed since your last reply, please retest with latest 2.0.x

[eightheads]

@eightheads many updates have passed since your last reply, please retest with latest 2.0.x

@boelle I am not currently running the SKR Pro on a printer so cannot test at the moment. However, as you can see multiple others have been having this issue still.

[LinoBarreca]

@xC0000005 How is it supposed to work if stm32 lacks sdio.h/cpp? I mean...The hal doesn't have the support for it.... When I get my board I'll work on it.

[xC0000005]

The HALSTM32 doesn’t have working SDIO implementation - I’ve been using it on STM32F103, STM32F070, and STM32F407 machines with the SD cards hooked up via SPI (the onboard card on the BTT SKR Pro is hooked up this way). I did get the SDIO ports on a lerdge board working using the code here -
https://github.com/xC0000005/Marlin/tree/LerdgeXAndK/Marlin/src/HAL/HAL_STM32 https://github.com/xC0000005/Marlin/tree/LerdgeXAndK/Marlin/src/HAL/HAL_STM32
the two files are the SDIO ones. It doesn’t use DMA yet and occasionally hits an error, but it would be a good start toward SDIO for the unified HAL.

On Nov 4, 2019, at 12:33 PM, Lino Barreca [e-mail] wrote:

@xC0000005 https://github.com/xC0000005 How is it supposed to work if stm32 lacks sdio.h/cpp? I mean...The hal doesn't have the support for it.... When I get my board I'll work on it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/14684?email_source=notifications&email_token=AHVGS4LNSNXZJAVTETORZE3QSCBKZA5CNFSM4IFLWW6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDATUFI#issuecomment-549534229, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4PAX7RCLNXIWRLHDE3QSCBKZANCNFSM4IFLWW6A.

[LinoBarreca]

https://github.com/stm32duino/STM32SD
We just need to use it inside marlin...maybe that's what I'll work on next.
I'll create the interface in the generic stm32 hal to use the official stm32 SD support.

[xC0000005]

That includes the parameter order fix for both F4 and F103 so that’s good a perfectly good way to use it.

On Nov 4, 2019, at 12:44 PM, Lino Barreca [e-mail] wrote:

https://github.com/stm32duino/STM32SD https://github.com/stm32duino/STM32SD
We just need to use it inside marlin...maybe that's what I'll work on next.
I'll create the interface in the generic stm32 hal to use the official stm32 SD support.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/14684?email_source=notifications&email_token=AHVGS4KRX7IYYAQZIR5Q5PLQSCCRFA5CNFSM4IFLWW6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDAUS7Q#issuecomment-549538174, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVGS4MK3A4IW5IAN3GLOHDQSCCRFANCNFSM4IFLWW6A.

[LinoBarreca]

I am working on it.
Once I'm done marlin will be able to support multiple SPI buses simultaneously and on-board sd card

[davidcgu]

following!!!!!

[tjengbudi]

I am working on it.
Once I'm done marlin will be able to support multiple SPI buses simultaneously and on-board sd card

Waiting for this...

[LinoBarreca]

It's done! :muscle: :tada:

[eightheads]

It's done! 💪 🎉

Thanks @LinoBarreca !

[eightheads]

I'm not running a SKR Pro board currently. If we can get some testing verifying this then I'm more than happy to close the issue. Thanks for all the works guys!

[cobrettee]

would like to test - so just to confirm I have to use Lino's marlin branch?

[LinoBarreca]

Hold on, everyone.
It's working but it isn't production-ready.
I had to modify lots of things in the spi subsystem.
It works but it breaks, at the moment, every other board.
It needs to be backported to other HALS/pins files.

[SkullKill]

@LinoBarreca Great work! hopefully this will be production-ready soon :)

[holgin]

Does someone have the SKR bootloader

fw_stlink.zip
My dump via st-link
SKR Pro 1.1
Marln from 08000h

Hey, Im trying to upload the file you have attached using ST-LINK Utility to a brand new MCU on SKR PRO board. As you probably expect, Im getting errors, so I wanted to ask if you could help me with that?

[LinoBarreca]

@SkullKill if you want to come to the other side and make some tests we will finish sooner.

https://github.com/LinoBarreca/Marlin/pull/7

[SkullKill]

@LinoBarreca sure, as soon as i am back, i can do some testing. will be back around end of Dec, start of Jan.

[LinoBarreca]

@LinoBarreca sure, as soon as i am back, i can do some testing. will be back around end of Dec, start of Jan.

That is awesome. By april you should have it then.

[BastR]

@LinoBarreca I can participe to test, what can I do ?

[LinoBarreca]

@BastR you found the thread yourself. so..since you have the drivers in SPI mode (that's nice) just wait for me to support them. I should have something for you later today (~16 GMT)

[BastR]

@LinoBarreca ok, I can try today 👍🏻

[boelle]

could be nice if this one is solved :-D

[LinoBarreca]

@boelle as I said I'm working on it.

[boelle]

@LinoBarreca making a PR for this one or still working on it?

[LinoBarreca]

@boelle
https://github.com/LinoBarreca/Marlin/pull/7

I am making a lot of work because I don't just fix that but I add a LOOOOOOT of things to the list.
SO yeah...definitely making a pr when it's ready and finished. I don't say something if I'm not sure.... but I want it to be perfect and ADD value, besides the fix. that was ready 15 days ago. but I'm doing way more, as you can see from the link above.

[LinoBarreca]

(also I take care of this https://github.com/xC0000005/Marlin/issues/5#issuecomment-563567564 )
I guess the depth of the work is so huge it should make it into 2.1)

[boelle]

or split it up in multple PR's ?

if one of the things later breaks something else it would be more easy to figure what did go wrong

and small pr's are more easy on @thinkyhead to check and merge in

but since i'm not a programmer nor the maintainer i will let it be up to you :-)

[LinoBarreca]

or split it up in multple PR's ?

Yeah that could have been an option but most of those are deeply linked one to the other.
The sdcard bug (this) and the multiple spi (change) are linked. They require a deep change to how marlin handles/defines SPI. This means it has to be backported to the other hals (at least at the interface level)
I am closing the hardware CRC part and I will surely make a PR to "commit it" into the marlin source code. (the hardware CRC wasn't strictly necessary, but since it will require a HAL interface change with the core I preferred to do it now, so I don't ask people to revisit things twice)
As I said somewhere in the above link I need to make that PR because I need help in adapting all the other HALS to the new "variable" spis by board. We need to adapt each pins file (most of them will be a 1 to 1 translation, easy and stupid, because most boards don't have multiple SPIs but just one) and all the hals to handle the new calls. that work is just "adapt this call to fit into what we have now" and it will be easy for the maintainers of the hals once I make the PR. I already did it for the STM32.
Problem isn't that I can't do it myself, I could indeed adapt each pins/hal to the new "dynamic" logic but I will take A LOT to do that if I'm alone. If I push that PR we can have more people working on the "multispi" branch and then merge it all at once.

Today we finished half of the Hardware CRC part. when the other half is ready I'll make the PR.
We are actually working in three (me, @Evg33 and @Patag ) on that one but the problem with board design of the SKR pro makes it harder to work on it because of a (wrong) R5 on the clock line. I sorted the problems out (with their precious testing help) and I guess that by the end of this week we will have the pr done to marlin's source.

[jgwinner]

This sounds fantastic. I have an SKR Pro and just started trying to program it. I was going to use UART, not SPI. CR-10, adding another extruder. BLTouch, 2209's and 2208's.

If I can do anything to help, let me know, I'm a long time C++ dev.

    == John ==

[Evg33]

Multiple, simultaneous, SPI buses handling and Smart SD mounting https://github.com/MarlinFirmware/Marlin/pull/16260

[LinoBarreca]

everyone having this problem, please go and test pr 16260, as linked by @Evg33

[boelle]

@eightheads is the issue still the same with all the updates in the last 27 days?

[boelle]

btw, who can confirm there is an issue? use the same configs as OP and the same hardware if possible

[m-kozlowski]

btw, who can confirm there is an issue?

You mean onboard sd on skr pro? Yes, there is an issue.
It does work with #16260 however.

[boelle]

if that is what is in https://github.com/MarlinFirmware/Marlin/issues/14684#issue-470534484 then yes

[boelle]

@thinkyhead could we get #16260 merged maybe?

[LinoBarreca]

16260 is not in a merge-able state yet. We will get there, but it is not yet complete. I will start back working on it after Christmas. Btw merry Christmas everyone.

---

From: Bo Herrmannsen [e-mail]
Sent: Tuesday, December 24, 2019 3:10:13 PM
To: MarlinFirmware/Marlin [e-mail]
Cc: Lino Barreca [e-mail]; Mention [e-mail]
Subject: Re: [MarlinFirmware/Marlin] [BUG] Marlin on BigTreeTech SKR PRO can't be configured to use the onboard SD-card (#14684)

@thinkyheadhttps://github.com/thinkyhead could we get #16260https://github.com/MarlinFirmware/Marlin/pull/16260 merged maybe?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MarlinFirmware/Marlin/issues/14684?email_source=notifications&email_token=AAG3FOZ2POXPL6QMXVJQTD3Q2IJ4LA5CNFSM4IFLWW6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHTIHQI#issuecomment-568755137, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAG3FO5DZIYVFIPADHVNZ7LQ2IJ4LANCNFSM4IFLWW6A.

[G-Pereira]

What about printing from the on board SD card @LinoBarreca? I don't want to rush you in any way, I am just wondering if that is possible and planned.
Happy Holidays!

[LinoBarreca]

That's actually working on skr pro. It's not merge-able because it needs work on other hals

[Fighter777]

good work, i will test that on my board ;)

and i will order a sd card extender ... thx @dineshvyas ^^

[G-Pereira]

That's actually working on skr pro. It's not merge-able because it needs work on other hals.

Is it in bugfix-2.0.x? and not in 2.0.x?

[LinoBarreca]

That's actually working on skr pro. It's not merge-able because it needs work on other hals.

Is it in bugfix-2.0.x? and not in 2.0.x?

Yes, actually 2.0 is out. This could go into 2.0-bugfix or 2.1-dev (I think the latter is more appropriate since the entity of changes, but there no one could use it)

[Fighter777]

that work for me

thank @LinoBarreca

USB port work ?

[jgwinner]

I'm away from my machine now, but I wasn't able to get the RepRap SD card working on the SKR Pro 1.1 nor the onboard SD card. The onboard one wasn't recognized. I also was never able to get the USB working.

I was using the Lino7 branch.

I get CRC errors on the display SD card, although it reads the directory fine.

Are there some settings that maybe I was missing?

I have an ST Link coming, I can run further diagnostics if you need.

== John ==

[LinoBarreca]

that work for me

thank @LinoBarreca

USB port work ?

Not yet. That's another hardware part...I might work on it when that will be merged. But it's unlikely since that pr opens a million of possibilities for developing more useful things.

[LinoBarreca]

@jgwinner as I said on the PR pull it again and test it again. When @thinkyhead did the forced push something broke. I did a force push again from my last knowing one and it's working now, for sure.

[jgwinner]

@LinoBarreca Oh, sorry, Missed that (bandwidth constrained ATM).

I will do that!

[boelle]

since we have not heard from OP i will mark this one as stale

Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.

[jgwinner]

Six days stale over Christmas and New Years gets it closed? Good grief.

[LinoBarreca]

there's a fix anyway for it...so it makes sense to be closed.

[Fighter777]

fix not merged ?

[LinoBarreca]

not yet. it needs work on other boards... but on skr-pro it works.

[github-actions[bot]]

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.