FW will not upload to SKR1.3

Mostly Printed CNC - MPCNC Troubleshooting
1

I’m pretty sure this problem has been seen before, but I can’t find the info, so please forgive my redundancy.

I’ve rebuilt my Primo as part of moving it to dual endstops.

Starting with the “official” V1 version of the SKR1.3 Dual Endstop firmware which was for the TMC2209, I revised it to the TMC2208 which is what I have. (That’s also what has been running for a couple of years on the exact same board without dual endstops.)

I changed the drivers to the 2208 in that V1 version using PlatformIO, and it compiled with no errors. The jumpers on the SKR1.3 are set up for UART mode, which is the same as the board’s jumpers were set prior to this revision when there were only 3 2208’s.

Moved the “firmware.bin” file to a micro SD card, inserted that into the SKR1.3 (after changing the jumper to the USB setting) and connected to the USB of the laptop.

I believe this is the same procedure that I have used before, although it’s been a while since I last did this on the LR3 running the exact same board and drivers.

The red LED comes on, but no upload of the firmware occurs. If it is successful, the name of the file on the SD card is changed to FIRMWARE.CUR. This does not occur.

Note that there are no stepping motors or display attached. Simply the SKR1.3 board.

I also tried to load the firmware.bin that comes with V1’s 2209 version and got the same result.

I feel like I’m missing something, as this procedure should be straightforward, and the board is known good, as those of you who were at the RMRRF can attest… it was running in the non-dual-endstop condition. However, I’m sure stuck.

Can someone offer some help, please?

2

Sure thing, Dave. It was great to meet you at RMRRF.

That’s a version of firmware and a board that I’ve not worked with (I’ve used SKR Pro 1.2 and Octopus, SKR 1.3 is an entirely different board.)

Do you have the firmware.bin file that you had when you first flashed the board?

My guess is that we need to first figure out if your board will flash anything at all (Which it appears that it isn’t.)

When I deal with these kinds of issues, I usually start with a freshly FAT32 formatted SD card and put known working firmware on first. (The file you used last time) Then I try to flash my candidate build.

Can you confirm what version of V1 firmware you started with? Was it this one?
https://github.com/V1EngineeringInc/MarlinBuilder/releases/download/515/V1CNC_Skr1p3_2209-2.1.1.zip

3

I doubt the firmware has anything to do with it. It is most likely:

  • Power
  • SD card format
  • Wrong board
  • Something could be wrong with the bootloader
  • Broken Board

Can you post a picture of the board powered up?

The 2208/2209 stuff shouldn’t matter until you get past the firmware.cur step.

4

Or the .bin not being in the SD card root.

1 Like
5

Maker Jim, Jeffeb3, Mike,
Thanks for your thoughts and comments. I believe the problem has been solved, though I’ve not connected any motors yet. The endstop connections all work, according to the M119 command. There are 5 of them with the correct logic which means the new firmware is running, I think.

I’m going to respond comprehensively, in case this type of problem occurs to someone else. But, in short, I think that the micro SD card connector may be flaky. Could also be the SD card.

  1. I started with the V1CNC_Skr1p3_Dual_2209 firmware and changed it to the 2208 drivers (using UART) in all positions. This modified version of Marlin compiled with no errors.

  2. I tried several times to load this version of firmware.bin, as I mentioned in my original message.

  3. I then tried simply using the version of firmware.bin that was included in V1’s 2209 version of the code, figuring as Jeff said that the 2209/2208 issue would not stop the upload. But, there was no joy there either. (And, BTW, this file was the only file on the SD card. No subdirectories. )

That’s when your collective comments came to the rescue.

A. Power. As seen in the photo, the USB jumper is properly placed. (Ignore the main power connector. The power supply was not plugged in. ) there is a single red LED.

B. Wrong board. It’s the same exact skr1.3 that I’ve been using for several years. Since the Primo was first built.

C. Broken board. Seems unlikely, as the board was never removed from the case. But, that can’t be fully eliminated since that could be an intermittent problem.

D. Bootloader. Complete unknown. Plus, I wouldn’t know what to do if it was the issue.

So, I focused on the SD card. It’s a 128MB micro SD card which I’ve only ever used for firmware loading, so it’s not been heavily used. Nonetheless, I reformatted it as FAT32 and reloaded the firmware.bin file from my new 2208 version.

That alone didn’t seem to solve the problem.

But, in thinking about this, I remembered that to minimize the insertion and removal of the SD card that contains my gcode files, I normally use one of these extenders that has a receptacle for the SD card connected by a ribbon cable to a piece that goes into the slot on the SKR1.3 board.

And, bingo, after placing the SD card into that extender, plugging it into the SKR1.3 and powering to up through the laptop’s USB, the firmware uploaded with no further incident (evidenced by Windows 11 claiming that it couldn’t recognize the USB device. )

This was confirmed by the filename changing to FIRMWARE.CUR

I then switched the power jumper back to the INT setting, connected the power supply and using Pronterface issued the M119 command which reported all 5 of the endstops correctly. I then repeated this with a jumper on them one by one and again they were correct.

So the next step is to connect the motors and check for movement.

However, I suspect that this machine is now going to function as expected.

Thanks again for your thoughts. I’d worked on this for a couple of hours before posting, so each of your comments about the possible SD related failures together got me re-focused correctly.

1 Like
6

Forgot the photo.

20240505_080412
20240505_0804121920×2560 845 KB

7

Interesting outcome. I suspect you’re right and there’s something funky with that SD card slot. Maybe it’s just oxidized from too few insert/removal cycles… :thinking:

8

Who knows? I think I may have run into something similar with my LR3, but it was not as complete of a failure.

These things seem pretty fragile, and they must have reasonably tight tolerances. I probably could have cycled through a bunch of SD cards, but that seemed like a less appealing approach.

I guess that my next “upgrade” should be to figure out some more robust way to load files… maybe using wireless? Does the Jackpot board/environment allow that?

Somehow Octoprint handles this sort of thing smoothly on the RPi. And, the Prusa MK3.9 uses an actual USB stick, also more robust.

Running a dedicated laptop doesn’t solve the problem with 32bit Marlin, apparently, because this SD stuff is required.

At this point, assuming I can move motors, it’s at the stage of “if it works, don’t fix it”.

9

I would expect it would last well over 10k. Probably more like 1M. I don’t know how often Dave changes the card. But that seems like a stretch. I would sooner blame a loose solder blob.

The easiest way is probably attaching a pi via USB and using octoprint. But then you can’t start the file from the screen.

Or replacing it with a jackpot. You could always make something in May and you might win a jackpot from Ryan or Doug in the V1E GO maker contest. Your 3D carved grapes would be a strong contender.

10

:slight_smile: quote=“Jeffeb3, post:9, topic:43683, username:jeffeb3”]
Or replacing it with a jackpot. You could always make something in May and you might win a jackpot from Ryan or Doug in the V1E GO maker contest. Your 3D carved grapes would be a strong contender.
[/quote]

I’ve been watching the Jackpot. The controller that Maker Jim was operating at the RMRRF on the LR3 was very impressive.

And, one of the reasons for this Primo tuneup which has been pending for a long time is specifically to create the final, multi-wood version of the grapes (which has also been pending for a long time…:slight_smile:

Thanks for the comment.

1 Like
11

Glad it’s working.

Too few… Not too many.

I’ve seen that failure mode where a card or extension cable is never removed, then it is, and it has trouble.
Though in thinking about it, oxidation may be less likely than some kind of FOD accumulated which was then dislodged when removing and replacing with the extension cable.

I have a couple of spare jackpots. If you want to experiment with one, let me know.

Yes, but it’s an area that I’d consider still in development. Sometimes folks have memory errors trying to copy files.

12

Thanks for that offer. I think I’d like to start by getting that coffee we discussed. I have lots of questions.

In the meantime, the new, dual endstop Primo is, in fact, working. Motors move correctly and endstops trigger properly! I’m just cleaning up the wiring, but I’m going to possibly do some calibrating and test cutting tomorrow.

13

In re-reading this, it raised a question.

I’ve looked at some of the forum info on using the RPi, but my impression was that one needs to run cnc.js or something to get it to work.

However your comment suggests something different: that I could just connect an Octoprint- ready RPi to the SKR1.3 through the USB, and it would behave like any other printer, so I could upload the gcode generated by Estlcam, for example.

(It looks like you might have created a special version of Octoprint, but the approach would be similar? )

I have multiple RPi’s and use Octoprint routinely, so that approach, if I’m interpreting correctly, would be interesting.

Is this at least close to correct? I’ll go take another look at your github too.

14

In my experience, octoprint works fine. There is a section in the settings where it tries to disable the motors but I don’t remember any other required changes.

V1pi took a copy of the octopi image, added cncjs, and a landing page to choose between them. The only issue is that it is pretty out of date. At this point, I would choose the newest octopi image and go with that. I’m 90% sure it will just work.

15

Thanks, Jeff. After reviewing your github and a couple of other items, I did figure out what your special version actually was.

Obviously, I’m WAY behind on this for the MPCNC… I tend to take an “if it ain’t broke don’t fix it” type of approach, which, until now has been fine.

But, given the changes that are already underway, the timing is good to check out this solution. (And, the idea of not chasing the LR3 controller around the room is especially appealing… :slight_smile: )

1 Like