Can't seem to get the latest version of Marlin to cooperate with the controller. - no USB, no LCD movement, nothing.
The Version from Aug. 29 is working just fine.
Expected behavior: Place firmware.bin on SD, hit RST, go on doing stuff.
Actual behavior: Place firmware.bin on SD, hit RST, stuck...
I have tried 2 different SD cards. Both working with the older version just fine. I also tried changing #define SERIAL_PORT -1 to 0 as thats what it is set in the latest examples file. But since not even the LCD is showing anything I think the problem lies elsewhere.
I hope the info is sufficient :)
You have a lot of changes in the configuration files and pin files. Perhaps it would help to start with a more standard configuration and work on from that adding the changes you need one at a time? If you want to use USB to talk to the board you need to set the serial port to -1.
So do you see the firmware.bin file change to firmware.cur after you reset the board?
Do you see any sort of USB device appear on your PC? If so what is the device called?
Are any of the LEDs on the board flashing? What happens as you reset the board?
Something else you could try would be to add #define LPC_SOFTWARE_SPI into your pins.h file.
i use the board, and
I had a similar problem ...
I spent a lot of time to understand that my SD card has a GUID instead of an MBR partition table
@gloomyandy As in the builds before I was using serial_port -1 and it did function flawlessly. I was just wondering why the example configuration states serial_port 0 so i gave it a try.
Yes, the .bin changes to .cur. Still, after that the LCD is dead (in fact it lights up - obviously power is good) and there is no USB com.
@setar Did it work for you 'occasionally' or not at all? I tried two different SD cards both formatted to FAT and both work with the 092818 version but not with the most recent one.
Thanks for the replies. I will go and check what you said @gloomyandy and have a look at the partition table of at least one of the cards.
GUID for SD never worked (and shouldn't), this is my mistake when formatting by default on macosx
I formatted on linux and on windows. But since both cards do happen to work I think I can say the problem is hiding somewhere else.
If I put a new .bin on the SD and hit RST (push and hold for about a sec) the red LED lights up and stays that way. The board comes up with the new firmware anyhow. If I hit RST for a second time without changing anything else the red LED turnes off but the board keeps functional.
I see the same behavior with the 'broken' version of Marlin except the board doesn't wake up. No serial, no LCD (still the .bin turnes to .cur).
As the host I got a Pi (OctoPrint) hooked up via USB. Here I see no serial device.
Adding one change at a time is a good point. Helped in the past ;)
Oh and #define LPC_SOFTWARE_SPI didn't solve the problem...
I press reset twice every time for flashing -
the first time after uploading new firmware and unmounting from a laptop, the second time about 5 sec later after that (I am guided by the time the custom logo is displayed).
a single reset doesn鈥檛 work for me either, maybe for the first time the connection with the laptop is disconnected, and the second time - boot with flashing
As long as everything is fine I SSH into octoprint and execute
sudo mount -tvfat -onoexec,nodev,noatime,nodiratime,gid=pi,uid=pi,dmask=0002,fmask=0113 /dev/disk/by-label/"name of sd card" /media/"chosen folder name to mount the card to"
Copy over the new .bin, then
sudo sync
sudo umount /media/"chosen folder name to mount the card to"
and walk downstairs to manually hit the reset button as described above.
Pretty much the procedure @foosel explained here
Only in "emergency situations" I physically remove the sdcard to copy over another .bin.
Just for the record, that's a community contributed wiki node, not my doing ;)
Oops, indeed... my bad ;)
I'm trying to find some time tomorrow to give a fresh copy with just the basics enabled a shot...
Marlin now has a binary transfer protocol that can be used to transfer binary files (and gcode files fast(er)) over the serial connection, it needs implemented in Octoprint but when it is it will simplify flashing lpc176x, I did have a quick look but haven't had time to understand how to add a custom transfer protocol to Octoprint yet.
While this is getting slightly off topic here, this sounds very interesting! I'm definitely looking forward to that :) But right now I'm pretty happy how it is (as long as nothing unexpected happens). Some sort of custom button inside octoprint to let the Pi reset the azteeg board (saves some walking) would be nice. I guess that would get obsolete as soon as the plugin you been talking about is available..
I had some time to poke around a little bit and could narrow it down to the tmc2208/soft serial implementation. While everything left as seen in the files above commenting all #define bla_DRIVER_TYPE TMC2208 does the trick.
Could it have to do with the new unified TMCStepper library? @teemuatlut ;D
@p3p does the tmc library use the LPC176X framework to provide software serial or does it have its own?
Something something with sw serial begin...
I'll bother @p3p for a bit and see how far the rabbit hole goes.
does the tmc library use the LPC176X framework to provide software serial or does it have its own?
I try to use framework resources whenever possible.
lpc176x framework is updated, should solve the lockup problem
Sorry for the late response. Lots to do the last few days (december... always...).
Unfortunately the behavior hasn't changed. This evening I'm going to grab a fresh copy, rebuild and report back.
btw.: I switched all pins from connector EXP2 to EXP3 and vice versa in order to connect the TMC serial pins to interrupt capable ones. I am not at home right now so the updated pins file will be attached later.
Thanks and greetings from germany :)
Edit: as promised my most recent pins file together with the configuration I'm using.
I am using the TMCs in standalone mode for now. But it would still be great to get this issue solved ;D
Does anyone else use some software serial on this board with a recent version of marlin and can confirm it working?
Do you have an LCD connected? Which one? Do you expect to be able to use an SD card? If the answer to either of these is yes then I'm not sure you can use P0_18, P0_16, P0_15 for your serial I/O. They are often used to talk to the SD card and/or the LCD. In particular just undefining MOSI_PIN etc is almost certainly not enough to free them up as if they are left undefined they will be set back to the "normal" values in spi_pins.h. You could try setting them to -1 instead, but I'm still not convinced it will work as they may be being shared with some other bits of hardware (without a full schematic it is hard to be sure). If at all possible I would use some other pins for your serial I/O if you can!
Yes, I have an LCD. RepRap Discount Full Graphics Display in particular. I am not using the SD and left out the buzzer as well. At first I had the Display attached to the pins on EXP2 and the TMC TX/RX on EXP3 (RX on P1_17, P1_14, P1_10 and P1_04 as seen in the pins file provided in the opening post).
The reason I moved the pins was the assumption it could make a difference to have the TMC pins on interrupt capable ones. According to the LPC1769s datasheet all pins on port 0 and 2.
Indeed I notice some strange behavior on the display but nothing thats bothering me too much (unprecise encoder input, occasional artifacts/cut off display).
I can't just define either the TX nor the RX pins as -1. This will give me a compilation error.
With the setup I mentioned in my previous post the extruder stepper isn't working anymore so I moved back to the old build for now.
Since it didn't fix my problem anyway and introduced other issues I will go back to the previous pins layout and go on from there.
OK but I wasn't suggesting you set the TX pins to -1 I was suggesting you set the MOSI etc. pins that you had commented out to -1. But anyway I think it would help everyone if started again in terms of telling us what setup you are now using and what problems you now have. In particular please post the current config files (including pins file) and tell us which version of Marlin you are using.
Good point. Got a little confusing here (my bad). I will tidy things up later as I get home.
@DyonisosHunter problem solved?
@thinkyhead i think we can close this one
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.