Unable to put M8P into DFU mode

Basic Information:

Printer Model: Voron
MCU / Printerboard: Manta M8P V2
Host / SBC: CB1

Describe your issue:

My printer have been off for quite a while and when I’ve decided to finally start printing again I logon to see this:

Klipper reports: ERROR

mcu ‘mcu’: Unable to connect
Once the underlying issue is corrected, use the

Then I’ve checked the /dev/* folder and could not find a single reference to the M8P, I’m using CAN so the process might be a bit different… Anyway, I’ve decided to flash the M8P again to see if anything changes and now I simply cannot put it into DFU.
I’ve already done the BOOT0 hold + quick RESET press + release BOOT0 procedure but nothing shows in lsusb.
The M8P leds looks fine, CB1 is receiving energy from it as expected, ssh is working, so I guess there’s something specifically wrong with the CAN communication or this board got bad while transporting the printer.

While in DFU mode the board doesn’t use CAN. It should appear in lsusb - don’t remember the exact device name, but it has “in DFU mode” at the end.

This is what lsusb should return when the board is in DFU Mode:

image

The critical piece is the 0483:df11 “ID”.

I’m aware of the expect lsusb output when in the DFU mode, but whenever I try to put the M8P in DFU mode it never appear in lsusb. I suspect that either the M8P is never really switching to DFU mode or the CB1 is not able to receive the data somehow.
I’ve bought a CM5 module, when it arrives I’ll switch the CB1 and see if it can see the M8P in DFU mode.
Otherwise I might order a new M8P to see if switches to DFU as expect…
I might try to put some USB device in the current M8P USB port to see if the CB1 can find it through lsusb too, that might give us a hint about where the issue is.

I find it really annoying that the M8P does not have any LED indicating that it is in DFU mode or not, that would certainly make the debug process a bit easier

Changing to a CM5 probably won’t fix what you’re seeing/not seeing.

Can you provide more information as to what’s happening and what you are doing?

Posting the results of lsusb would be helpful.

Have you tried power cycling before putting the Manta M8P into DFU Mode?

This is the result of lsusb after performing the M8P’s procedure to put it into DFU mode. CB1 never finds it, either because M8P never really switched to DFU mode or because it is not being detected.
I’ve also tried to plug some wifi adapter into M8P to check if CB1 would be able to find it through lsusb and it always can find it

So I assume that M8P is simply never switching to DFU… This board used to work just fine before transporting the printer and leaving it off for a month.

And yes, powercycles, removing the CB1 and putting it back making sure the connectors clicked, all the basic procedures. The reason I’m trying to flash it again in principle is because it suddenly stopped working:

Looking at what you’re showing me is that the MCU is not being detected at all.

Do you have any other devices plugged into the M8P? It looks like you have another hub plugged into it.

I just checked with one of the M8Ps running on a printer and got the following:

  • Device 1d50:505f is the M8P’s MCU
  • Device 1a40:0101 is, I believe, the CM4 I’m running (CB1 in your case)
  • Device 1d6b:000# is the hub/connections - there’s nothing plugged into the USB Ports

I just checked on another system which has a USB Keyboard:

image

And, I’m seeing what I expect to see.

I’m wondering if your MCU is dead.

Could you try building some Klipper firmware with the settings:

“PA13” is the status LED attached to the MCU’s SWDIO pin and I use it as a “life detector” - if the MCU is Flashed correctly, this LED comes on.

Once you’ve done that, set up an SD Card, as per the instructions in the User Manual (I recommend using an 8GB or smaller SD Card) renaming klipper.bin to firmware.bin, saving it on the SD Card and Flash the M8P’s MCU manually. Afterwards, if the MCU is running, the file name on the SD Card should change to firmware.cur and an LED by the MCU should light.

If you don’t get that, then I fear you need to buy a new Manta M8P. Sorry.

Looks like it is really dead, the SD card flash never worked before but I gave a try anyway again and nothing happened.

I’ll remove the board from the printer and tinker a bit more with it later when the new one arrives, if I find something I’ll share

I’ve also noticed that the Klipper config that you’ve provided is for the M8P 1.*, mine is 2.0, I’ve done an equivalent configuration following this guide in case anyone reading face the same: BigTreeTech Manta M8P V2.0 | Esoterical’s CANBus Guide

Apologies for that, I did notice that you had a V2 board but I guess it didn’t process.

In any case, I’m sorry your board appears to be dead.

Good luck on the new one and let us know if you find anything of note.

I’VE FOUND IT. I’ll not bother you with the whole story but the mini12864 display is the culprit.

For some reason, if the ribbon cable is connected, the M8P plays dead. Probably it broke during transportation in a way the interferes with the M8P.

What is the “ribbon cable”?

The mini12864 can be connected to the M8P via a ribbon cable, marked as “display” in this image:

Is it the “ribbon cable” or the actual display module? Do you have any way of beeping out the lines?

I suspect that the problem is the RESET Pin (EXP2 Pin8) is being held down and I’m curious to know if that’s the cable or the module?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.