I’ve hit a wall. I’ll explain. The way the snapmaker 2.0 is set up it uses a Cortex m4 chip to send can+ and can- communications to another Cortex m3 chip inside the rail to deliver direction commands to the stepper motor driver IC and limit switch condition back to the main control board. My problem is in order to alter stealth chop in the tmc chips and take full advantage of stall guard and sensorless homing I need to utilize pins that have no contact, furthermore, in order to get IC status I would need to program the Cortex m3 in the rail to relay this information to the primary controller and then program that Cortex m4 to communicate that to a pc. Something snapmaker omitted when using the Toshiba s109aftg IC was the diagnostic pin. Without diagnostic pin information you cannot see any error communication. In order to set up the SPI of the driver IC I need to get to be able to use m122 to enable/disable continuous debugging output. Has anyone flashed the snapmaker controler? Also does anyone know if the rails can be flashed through the controller without having to disassemble them?
There are tools in the forum for preparing a firmware package, and using either the touchscreen or a PC to flash it. A firmware package can contain module firmware, but there is no module firmware source available
Thanks for the information. I’ll seek out the flash tool and have a look.
I’m reaching the point of diminishing returns trying to implement a different stepper motor driver IC such as the tmc5161 with existing hardware. It’s nearly impossible to configure something that’s inside a rail. Another option with far less complexity and headaches (at least I think so) would be to utilize a SKR v1.4 turbo with dual z controlers and use a bigtreetech interface. But after that, technically, it wouldn’t be a snapmaker anymore. Hmm.
You can directly use the latest latest Snapmaker Luban version and generate the controller FW upgrade package:
You can get the official controller source from the Snapmaker Github, with instruction on how to compile the FW package. The FW from the modules is not yet open-sourced, but given they offer the possibility to create a FW package for it in Luban, it should come in the future
@Geared, do you have a debugger laying around? If not, you seem like the type who would benefit from one. Greatly speeds up test-retest cycles as it’s just seconds to download to the main controller, in addition to being able to pause and inspect the state of a running program.
Since there’s no toolhead firmware source though you might be at a wall until those are released.
Is that with JTAG? I might have a look at picking on up as well
SWD. I picked up a jlink edu mini, they are around $20, and made a plug that I friction fit into the PCB holes. IMPORTANT: This will fail/wipe the chip until security is disabled, which wipes the memory. This is not trivial to do.
You can upload from VSCode via PlatformIO (AFTER DISABLING SECURITY), make sure you’re using the current repo or it will “brick” your chip because it’ll upload to the wrong address prior to pull request #7 getting merged.
I begin to wonder if getting a tool to extract the flash from one of these chips might be a worthwhile investment.
I just downloaded Luban and I still don’t have that option.
You can’t, if it’s the same as the main controller. Any attempt to read the chip via a debugger invalidates the instruction pointer and fails. Security has to be disabled first to unlock the chip which wipes the memory. It’s possible to have the chip read out its own memory, but that requires being able to compile a custom version of the firmware in the first place.
I should note with the jlink programming will fail until you disable security which wipes the memory.
It’s under settings/firmware tool, not sure why you’re not seeing it, it’s on mine on Windows.
From the main chip manual on security, maybe the toolheads are different:
Under the security protection, the main flash can only be accessed by user code and the first 4KB flash is under erase/program protection. If a read operation to main flash in debug, boot from SRAM or boot from boot loader mode, a bus error will be generated. If program back to no protection level by setting SPC byte and its complement value to 0x5AA5, a mass erase for main flash will be performed.
I would avoid that option anyway. The touchscreen makes it own decisions about what firmware to upload to the controller, and in its current state, Luban will produce a package that the touchscreen will only accept once a day.
It will however look like its working, but will continue to flash the package previous package, not the new one.
I would recommend this instead which allows you to set a firmware version (to make the touchscreen think its new), or set the ‘force’ flag
Great. So really the only option is to set the driver IC to function as a standalone. Forget sensorless homing and stall guard and hope it functions. I don’t like that option.
Flashing chips and such isn’t one of my strong points. It’s an area I need to develop.
Well if you want to practice on the main controller, PM me and I’ll walk you through how to do it. It’s not that bad.
The firmware tool is in the latest Luban v3.11.0 release on github.
I’m a day late to a lively party. Here’s one that no one has touched on.
The documentation file
Hardware-Link.md in the controller source indicates that this is possible. All of the modules have a CAN command “upgrade module” listed; I’ve assumed that meant “change module firmware”. Source code for that firmware, however, is not currently available, so being able to upload it is, at present, mostly useless to outsiders.
It should indicate the maturity level of this whole product that there is no “firmware report” CAN command that would return version number and a hash of the binary.
IIRC if you have a serial console attached to the printer over the normal USB port, youll get a readout on different things when the printer starts up.
- “M1010 S” should get you the Status of the Enclosre (if you have one)
- “M1005” should report version and builddate of MC and Module versions (not 100% sure)
Also @Geared the step, dir, enable lines are didcated gogin over to each module. as CAN isnt fast/accurate enough to do that in sync with the dual Linear modules (i would assume). And the Maincontroller having command makes stuff simpler for GCode parsing (also a assumption) as the screen can “dump” gCode to the Controller which is then converted to step commands.
I followed the guide to build the controller bin using Visual Studio Code for MAC.
I successfully build the firmware.bin but using the Firmware Tool on Luban v3.12.3 it generate the bin file that is not equals to the Snapmaker2_V1.10.1.bin I was expected.
The official Snapmaker2_V1.10.1.bin is about 14MB but the ones I generated is about 231KB…
The update provided by Snapmaker includes the touchscreen, module, and controller firmwares. We are only able to build the controller firmware at the moment.
Ok so if I’d like to check bite/bite what I’ve built with the controller bin provided by Snapmaker… how can I extract just this module?
To be honest I was interested on the touchscreen because I’d like to understand how could be difficult to add the load/unload filament while the print is in pause state.
Thanks for response!