RepRapFirmware 3.0 port for LPC1768/9 based boards

I did not change anything standard, my settings are higher.
I'll try to turn off the screen, maybe it’s draining on power and the microcontroller is buggy

Hi the thing with the screen may be power, but it is also constantly talking with the main board and this generates extra load for the firmware to process (the same with the WiFi interface), it could be that the extra load is overloading the processor in some situations. Please post the m122 output if you have any more resets.

What speed should I set for sharing with the screen so that the controller is loaded less, 57600 or higher?

lower/slower is better, but really I'd try it without the display at all first and see if it makes any difference to you getting hangs.

Folks, we have had a number of reports of the firmware rebooting during prints and at other times. Some of these seemed to be caused by a watchdog timer reset when executing software PWM code. I also noticed that the LPC configuration was using a possibly invalid setting for the flash accelerator. I've created new builds that may help if you are seeing these resets so please try the following builds:
SBC: [drive.google.com]
WiFi: [drive.google.com]
Ethernet: [drive.google.com]

There is also an additional build with no network component which may be of interest to anyone trying to use a RepRap type display (we don't really have the memory to support those displays and networking). But this has had virtually zero testing:
[drive.google.com]

If you have any sort of reset please post an m122 from the system after it reboots along with brief details of what was happening when the system rebooted.

Also if the firmware seems to stop during a print, but is still responsive, please post M122 output before you reset the system.

Thanks

Two days I print with a physically disabled TFT and everything is fine. There were two long prints over 4 hours and all the rules.
I’ll test it again, if everything is fine I’ll try to connect the TFT but I’ll take the power separately. Or I’ll increase the polling interval "M408 S4" in the screen.
firmware-wifi.bin RRF3.1.1

Edited 1 time(s). Last edit at 05/27/2020 09:30AM by bcmob.

@bcmob thanks for trying that and reporting your findings. You may want to give things a try with the build I posted above. This has code which should reduce the overall load on the system which may help with your setup.

@ gloomyandy, I am running the sbc test version and had a freeze here are the diags:

=== Diagnostics ===
RepRapFirmware for LPC176x based Boards (biquskr_1.3) version 3.1.1-5 running on LPC176x at 100Mhz
Used output buffers: 1 of 16 (10 max)
=== RTOS ===
Static ram: 4216
Dynamic Memory (RTOS Heap 5): 1464 free, 1440 never used
Exception stack ram used: 284
Never used ram: 400
Tasks: HEAT(blocked,884) MAIN(running,1840) IDLE(ready,84)
Owned mutexes:
=== Platform ===
Last reset 00:04:45 ago, cause: [software]
LPC Flash Slot[3]:
Last software reset at 2020-05-28 08:23, reason: Stuck in spin loop, spinning module GCodes, available RAM 264 bytes (slot 0)
Software reset code 0x0883 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0042d80f BFAR 0xe000ed38 SP 0x2007fa1c Task MAIN
Stack: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
Error status: 0
Date/time: 2020-05-28 08:29:02
Slowest loop: 8.48ms; fastest: 0.34ms
Watchdog timer: 6243611/6250000
Step timer: target 227660568 count 285734475 delta -58073907 late 0
Interrupts: 56714; Calls 114528; fastest: 3uS; slowest 6uS adjusted 61
PWM Channels
state 0 next 31032 on 50000 off 50000 pin 2.3
state 1 next 381032 on 750000 off 500000 pin 2.4
state 2 next 81032 on 100000 off 100000 pin 2.5
state 3 next 44007 on 37025 off 62975 pin 2.7
=== Move ===
Hiccups: 0, FreeDm: 100, MinFreeDm: 99, MaxWait: 220762ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 3, completed moves: 3, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== Heat ===
Bed heaters = 0, chamberHeaters = -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is ready with "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon* is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 8ms ago
RX/TX seq numbers: 3089/9383
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.1.1
Code buffer space: 2048
Configured SPI speed: 8000000 Hz
Full transfers per second: 32.85

@Micktol Unfortunately I can't tell very much about the exact problem from that output, other than it looks like you were executing gcode at the time. Can you provide more details of what was happening? Can you reproduce the problem?

Folks, I've updated my test firmware builds to include a couple of fixes, plus the capability to capture more information if the firmware crashes/resets. So if you are running into problems please use this version to test with:
[drive.google.com]

I think the filenames make it obvious what the builds are, you will need to rename the files to firmware.bin when copying the to the SD card or uploading them via DWC.

As before if you get a crash please post the output from M122 here. If your print seems to hang, please try connecting to the printer via USB and if you can get the output from M122 before you reset.

With the firmware-wifi 3.1.1-6 on the command M122 the web interface restarts, while the printer itself works fine. Perhaps the output of the command is too large.
In the browser console I see that the answer is "buff: 255"

Edited 1 time(s). Last edit at 05/28/2020 12:05PM by bcmob.

@gloomyandy, I have a gcode file which stopped every time i ran it at the same place on the first layer. I looked at the gcode ant it was no different from others that had no problem. The only difference was it was using a different part of the bed.
As a debug measure I ran it without G29 S1 bed compensation it then ran fine! I renewed the mesh compensation to try a new bed map but it still stopped. I have no idea if this is relevant to the problems.

Edited 1 time(s). Last edit at 05/28/2020 11:10AM by Micktol.

@micktol

Are you running this with an SBC by any chance?

---

Based in Darlington, North East

@jay_s, Yes SBC on a pi3b. Is it a known problem?

Edited 1 time(s). Last edit at 05/28/2020 11:26AM by Micktol.

M122 at the 3.1.1-6 works via a USB terminal. The Webinterface restarts like bcmob said

@micktol

I also had this issue and we are aware of it and it should be fixed soon.

In the mean time, when you run the mesh compensation probing, are all points that you are specifying being probed or are some being missed?

---

Based in Darlington, North East

Hmm nothing is ever simple, works fine on the SBC version. Oh well, I've reduced the output a little and it works fine on my test WiFi setup now. I've uploaded new versions of the files (to the same place), new version is 3.1.1-7.

Just tried 3.1.1.6 SBC version and the same file runs now. My bed probe does skip a few because they are out of range, I changed the probe position I need to update the file.

@gloomyandy can confirm works now (The M122 command) !

@micktol

gloomyandy must've included a fix for this then.

basically, any missed probe points in the height map aren't getting an interpolated value and are instead being filled with a junk value. Its ultimately a bug in the RRF firmware.
I managed to overcome it by adjusting my probe points used to ensure they could all be reached.
Just remember that the probe points take into account probe offset.

---

Based in Darlington, North East

@Micktol The builds I've uploaded should have a fix for the problem we saw with the height map. Can you try that and report back. I'm not sure if it was the same issue as the one that you previously reported or not.

@Micktol Ah just seen your comment, that is good news. This was only a problem on the SBC version by the way.

Hello everyone，My friend Samuel Wang designed a skr v1.3 wifi extension board and he fully open sourced it.The pcb intergrated with esp8266-07/12s, two closed-loop
output, and a connector. The connector can be cut out from the pcb after you made it.

There is one problem that the output drivers was not supported in firmware.

The pcb is experimental - use at your own risk.



Edited 5 time(s). Last edit at 05/31/2020 11:24AM by niubo123abc.

How do the extra outputs work?

---

Based in Darlington, North East

Did you updated the release from the M122 crash bug?
I wanna to have a try after my pcb was made.

Yes, that bug has been fixed in the latest Google drive release.

---

Based in Darlington, North East

Did you mean the extension board? You have to define the pin which was printed in the pcb.

Ok. I believe the firmware would also have to be modified as I think the arrays for the pins only accept 5 inputs. Gloomyandy would have to confirm this.
What drivers is this designed for?
It should also work ok the SKR 1.4 as the EXP 1 and 2 ponputs are the same.

---

Based in Darlington, North East

We want to use two closed-loop stepper drivers in the voron2.4 design.Voron2.4 needs 7 steppers and the skr only support 5. So we designed this .The type of stepper dirvers wasn't decided.

Well it will be interesting to see it working

---

Based in Darlington, North East