LPC port of RepRapFirmware

Quote
dot_bob
Well after playing with the firmware the last couple of nights I have it running on a couple of printers and added support for the BIQU SKR board. I have submitted a couple of pull request with these changes.

I have been playing with the MKS SBASE trying to get networking and the discount reprap full graphics display running reliably. The hardware was designed pretty poorly as the display can't run very fast without artifacts. The same display runs fine on the AZSMZ Mini and BIQU SKR.

I have been playing with memory settings trying to make the network more reliable. it is working fairly well with NumHttpResponders = 1 and NumHttpSockets = 1 but goes to lunch after 5-10 minutes. It still responds to pings but the web server is MIA. The changes to the memory and network settings are in my default branch: [github.com]

I haven't had this issue with networking on the Smoothieboard or MBed board and have had it running happily for over 3 hours, so I'm not sure why the MKS is having issues, and without access to one it's a bit hard to guess.

First thing would be to turn on debugging for the networking module and have a terminal connected to the USB to see the debugPrintf output (there will be a lot of output for the networking) but may give hints to socket errors etc. I did make a small change for networking not long ago (not checked in yet) to catch the condition when the socket has an error mid "send" and can get stuck trying to resend over and over to a socket in error. You can see if this helps by adding Terminate(); just before the return 0 to L695 RTOSPlusTCPEthernetSocket.cpp.


I'm currently experimenting with adding support for loading a board config file from the SDCard to configure the hardware pins etc so its easier to support all the different boards and make it easier for people to use free pins for other things etc.

Quote
dot_bob
I have been playing with the MKS SBASE trying to get networking and the discount reprap full graphics display running reliably. The hardware was designed pretty poorly as the display can't run very fast without artifacts.

My guess is that the SBASE is sending 3.3v SPI signals to the display, however the datasheet for the ST7920 chip used in the RRD display specifies minimum high signal level of 0.7 * Vcc, which for the 5V RRD display is 3.6V. Preferably, use 5V level shifters on at least the SPI clock and data signals to the display. I've heard reports that these displays sometimes work with 3.3V signal levels if the SPI clock speed is reduced. In RepRapFirmware 2.03beta1 I've added a F parameter to the M918 display so that the display SPI frequency can be altered without rebuilding the firmware.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42

Quote
dot_bob
I have been playing with the MKS SBASE trying to get networking and the discount reprap full graphics display running reliably. The hardware was designed pretty poorly as the display can't run very fast without artifacts.

My guess is that the SBASE is sending 3.3v SPI signals to the display, however the datasheet for the ST7920 chip used in the RRD display specifies minimum high signal level of 0.7 * Vcc, which for the 5V RRD display is 3.6V. Preferably, use 5V level shifters on at least the SPI clock and data signals to the display. I've heard reports that these displays sometimes work with 3.3V signal levels if the SPI clock speed is reduced. In RepRapFirmware 2.03beta1 I've added a F parameter to the M918 display so that the display SPI frequency can be altered without rebuilding the firmware.

From the schematic, it is in 5V logic. They use SN74LVC1T45 level shifter. Note I don't use this ext port.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Quote
MKSA
From the schematic, it is in 5V logic. They use SN74LVC1T45 level shifter. Note I don't use this ext port.

What - there is actually a schematic for the MKS SBASE? Where?

If it does use 5V logic levels for the SPI drive to the display, then it should work at 2MHz SPI clock if the cables are reasonably short.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42

Quote
MKSA
From the schematic, it is in 5V logic. They use SN74LVC1T45 level shifter. Note I don't use this ext port.

What - there is actually a schematic for the MKS SBASE? Where?

If it does use 5V logic levels for the SPI drive to the display, then it should work at 2MHz SPI clock if the cables are reasonably short.

I found one via Google. Note it is ver 1.2 . Yet it has the crystal for both the processor and the ethernet.
On the other hand, I don't see any such level shifter for the Smoothie board, all is 3.3V logic (the 5V regulator seems to be optional)

The big difference seems to be the 100Mhz processor used in the MKS.

Edited 1 time(s). Last edit at 02/04/2019 02:14PM by MKSA.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Very experimental LPC build of RRF in testingConfig branch (also includes 2.03beta1 merged in from DC42's branch). Some have requested a config approach to set pin mappings to avoid recompilation etc and I've started implementing that, and included an initial preview of the new board config loader - this is still early days for the config system so things may still change and there may be bugs in the config system - anyone wishing to try should carefully check everything is working etc.

• Make sure to read DC42's 2.03beta1 Whats New (it notes changes to CoreXY etc).
• Note that the LCD frequency is settable by F param on M918 in RRF 2.03beta1. This will default to 2MHz SPI frequency. If the LCD is not working you can lower the freq using the new F param. I.e., enable LCD at 1MHz: M918 P1 F1000000

LPC Changes

• One binary for all boards. Important: If your board does not have an ethernet port ensure config.g does not enable Networking.
• Flexible Board Config:
  
  • Nearly all previous options in the variant headers are now configurable.
  • Loads /sys/board.txt from the SDCard early within Platform init.
  • Aim for board.txt was to be simple, readable and not use much memory for parsing etc. Similar format to the old header files.
  • Example configs here. Be sure to check these in case there was an error transferring them over to the new config format.
  • Changes to the timer code was needed for the flexible config, so ensure any heaters etc connected to a timer pin are operating correctly.
  • Configurable Options include:
    
    • Stepper pins (enable/step/dir)
    • Endstops and zProbe
    • Heater pins (thermistor/heater on) and ChipSelect pins for SPI temp sensors
    • Cooling Fan Pins
    • Fan tacho pin
    • LCD pins
    • Pins can be added to the SpecialPinArray to control servos or GPIO via M280 or M42 (up to 10 pins can be defined use any free/unused pins)
    • External SDCard CS and CD pins (lpc extra option to select SPI frequency)
    • ATX Power Pin
    • [LPC] Internal SDCard SPI speed selection.
    • [LPC] Pins for Timer PWM/servos.
    • [LPC] External Interrupt pins (limit of 3)
  • Temporarily, M122 P200 will print the current Board Configuration use this to check that the board.txt was loaded correctly.
• Very experimental support for BIQU SKR (untested) - Pin mappings provided by @dot_bob. Note: Unlike most other boards, it seems the step pins are not all on port2 but on different ports, so the step functions have been updated to handle it - specifically, they will not feature parallel writes at this time as the other boards do (needs testing).
• GPIO pins from special array are not listed in M122 anymore as they are defined in the config and the logical assignments will be known, and as M122 was getting too long to send to the web gui
• LPC Networking:
  
  • Updated send function (this has helped to increase download speeds) and add extra check to ensure socket has gracefully shutdown before closing them.
  • Updated the way the driver buffer array was defined within the network driver which has surprisingly saved a lot of RAM. New functions added to allow the TCP buffers be statically defined.
  • MSS is set to 512 to match the SDCard write buffer. MSS is also used to define buffers in other places too so has saved some additional memory here.
  • Extra info added to M122 to report on the network driver: Packet errors (CRC etc), overrun errors, min queue size and number of packets dropped due to lack of buffers to assist with debugging. Note that some dropped packets normally occur.
  • @dot_bob did some testing with reduced number of network buffers so I've included that to save more memory.
  • Increase reserved buffers so long responses (ie. M503) no longer cause DWC to disconnect when using DWC2.0 (thanks @dot_bob). Note that long responses will be truncated.
  • On my test system, with the updated network code and also selecting higher SPI freq for the Internal SDCard my download speeds has more than doubled.
• EndStops - Previous temporary hack removed now that endstop pins are no longer hardcoded in the binary. Update board config file to define which endstop pins are to be used.

Edited 1 time(s). Last edit at 02/11/2019 11:49PM by sdavi.

So far so good.

Note I didn't check if there was still this com issue with Repetier in debug mode as I don't use it anymore and removed it. I don't use the network either.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Quote
MKSA
So far so good.

Note I didn't check if there was still this com issue with Repetier in debug mode as I don't use it anymore and removed it. I don't use the network either.

I think for the next release I will just end up disabling "M111 Sx" and have it print a note that it should be used along with with the P parameter to enable only the modules they want to debug. That would at least stop the command M111 S6 turning on debugging for all modules.

Quote
sdavi
I think for the next release I will just end up disabling "M111 Sx" and have it print a note that it should be used along with with the P parameter to enable only the modules they want to debug. That would at least stop the command M111 S6 turning on debugging for all modules.

That's a good idea, I'll do that too in the 2.03beta2 build as standard. Repetier said some time ago that they were going to improve compatibility of Repetier Host with RRF, but I don't know whether they ever did that.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Updated to DC42's RRF 2.03Beta2. I've also made some changes to HTTPResponder that should hopefully stop DWC getting stuck in an endless reconnecting loop when the buffers run out.

In the beta2 update, DC42 also changed M111 so now debugging won't be enabled by "M111 S6" - this should help those using repetier-host.

Updated binary in the configTesting branch.


@DC42 The issue was the buffers were never timing out as it was falling through and sending an empty response (also causing a JSON parse error in DWC). Github diff here - not sure why git decided to change the formatting of the changes.

Thanks @sdavi, I'll include that HttpResponder fix in beta 3.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I had a little free time last night so I gave the testingConfig branch a try on my MKS SGEN (basically an MKS SBase without on board drivers).

A few things I observed... It appears the endstop min <-> max order is reversed in the boards.txt. According to documentation from MKS the pinout is the same as the SBASE but I ended up needing to flip the max and min endstop pin definitions in the board.txt.

Ethernet functionality is more reliable. I was able to leave the board running overnight and not have any lost packets or disconnects.

I did have a show stopper though. If I started a print a few seconds into the first layer of a print I would get a hard fault reset. This seemed to happen when printing via USB tethered to S3D, or printing the gcode file from the web ui. It seemed to be failing on simple moves while extruding. I disabled display support and recompiled to see if there was any difference and had the same result. I didn't have time to dig any deeper.

Quote
dot_bob
I had a little free time last night so I gave the testingConfig branch a try on my MKS SGEN (basically an MKS SBase without on board drivers).

A few things I observed... It appears the endstop min <-> max order is reversed in the boards.txt. According to documentation from MKS the pinout is the same as the SBASE but I ended up needing to flip the max and min endstop pin definitions in the board.txt.

Ethernet functionality is more reliable. I was able to leave the board running overnight and not have any lost packets or disconnects.

I did have a show stopper though. If I started a print a few seconds into the first layer of a print I would get a hard fault reset. This seemed to happen when printing via USB tethered to S3D, or printing the gcode file from the web ui. It seemed to be failing on simple moves while extruding. I disabled display support and recompiled to see if there was any difference and had the same result. I didn't have time to dig any deeper.

As mentioned before, the previous temporary hack for the endstops no longer exists (which selected min or max based on gcode low/high position setting using hardcoded endstop array). I think the default in the example board.txt files should be configured for the min endstops. Users now have a choice to either use the existing array in board.txt and use the C param of M574 to select the correct pin based on its position in that array, or edit the board config so the right pins (min or max or any other spare) are set for the X,Y,Z axis (first 3 in the array). By editing the board.txt you can also now remove those unused endstop pins and use them for other purposes (special pin, servo, etc etc) without having to recompile.

What kinematics are you using when seeing the fault? M122 after the fault should show what type of fault caused the reset.

I am using delta kinematics when I see the fault. Loading the old release I am able to successfully print the gcode that is crashing on the testingConfig build. This is the first part of the diagnostic output:

M122
=== Diagnostics ===
RepRapFirmware for LPC176x based Boards version 2.03beta2 running on LPC176x at 120Mhz
Used output buffers: 2 of 15 (5 max)
=== RTOS ===
Static ram: 5192
Dynamic ram: 26940 of which 0 recycled
Exception stack ram used: 208
Never used ram: 396
Main SRAM : 32340/32768 (428 free, 396 never used)
RTOS Dynamic Heap : 38192/46640 (8448 free, 8104 never used)
=== LPC PWM ===
HWPWM:100Hz T1:10Hz T2:50Hz T3:250Hz
Tasks: EMAC(blocked,208) NETWORK(ready,500) IP-task(blocked,388) HEAT(blocked,1324) MAIN(running,2316) IDLE(ready,200)
Owned mutexes: RTOSPlusTCPEthernet(NETWORK)
=== Platform ===
Last reset 00:00:15 ago, cause: [software]
Flash Slot[115]:
Last software reset at 2019-02-26 19:03, reason: Hard fault, spinning module Move, available RAM 332 bytes (slot 0)
Software reset code 0x4034 HFSR 0x40000000 CFSR 0x00008200 ICSR 0x00411803 BFAR 0x6e652c53 SP 0x2007dbe8 Task 0x10000704
Stack: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
Error status: 0

Edited 1 time(s). Last edit at 02/26/2019 09:13PM by dot_bob.

This is an interesting one. In simulation mode it works ok. In print mode it will always trigger on the same spot in my test gcode. It also happens with other kinematics too, although the point in the gcode that triggers the fault is different for each kinematic type. GDB backtrace shows a fault occurring:

#0  HardFault_Handler () 
#1  < signal handler called >
#2 DDA:: Start
#3 Move:: StartNextMove
#4 Move:: TryStartNextMove
#5 DDA:: Step
#6 Move:: Interrupt
#7 TIMER0_IRQHandler()

Increasing DdaRingLength from 20 to 28 in Move.h seems to make the problem go away, at least on the test gcode I'm using. Anything less than 28 causes the fault. This does increase memory usage. I'm not familiar with the movement code of RRF, so I'm not sure if that is a just a bandaid fix or if the larger ring length is required for the new version.

Updated binary (RRF v2.03beta2+1).

I am not aware of any reason why a larger ring length would be mandatory. Can you identify the faulting instruction, either using gdb or from the M122 info and assembly listing?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Here is an update with what I have been trying. I upped the DdaRingLength to 28 and was able to complete my simple calibration print ok but it crashed when printing a simple benchy right as it was printing the wording on the first layer. I upped to 32 and it still ended up crashing on a benchy. Upped to 40 it completed the benchy but the web server quit working I assume it ran out of memory as I got the following.
M122
Used output buffers: 1 of 15 (7 max)
=== RTOS ===
Static ram: 5192
Dynamic ram: 26940 of which 0 recycled
Exception stack ram used: 304
Never used ram: 300
Main SRAM : 32436/32768 (332 free, 300 never used)
RTOS Dynamic Heap : 45704/46640 (936 free, 248 never used)
=== LPC PWM ===
HWPWM:100Hz T1:10Hz T2:50Hz T3:250Hz
Tasks: EMAC(blocked,208) NETWORK(ready,500) IP-task(blocked,372) HEAT(blocked,1316) MAIN(running,2036) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 01:32:06 ago, cause: [power up]
Flash Slot[49]:
Last software reset time unknown, reason: Hard fault, spinning module Platform, available RAM 368 bytes (slot 0)
Software reset code 0x4030 HFSR 0x40000000 CFSR 0x00008200 ICSR 0x00400003 BFAR 0x9ff5db38 SP 0x10007f84 Task 0xa5a5a5a5
Stack: 0000822b 00007606 2100000f 00000028 40084fe0 00000007 2007dd98 0000001d 40084000 40084fe0 00001183 a5a5a5a5 0000822b 00000000 fffffffd 10007fe0 e000e014 e000e010 100000a0 7f000000 000082ed 000080d0 21000000

I changed DdaRingLength back to 20 and NumDms to 8. So far it is half way through printing the benchy and webserver is still responding.

Works for me but no network, no webserver !

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Looks like the main cause was "updating" the network driver memory allocation to match the other drivers in +tcp, so i've reverted back to the previous version.

Ive run a couple of different test gcodes through and so far no issues.

Updated Binary

Edited 1 time(s). Last edit at 03/01/2019 07:26AM by sdavi.

Quote
sdavi
Looks like the main cause was "updating" the network driver memory allocation to match the other drivers in +tcp, so i've reverted back to the previous version.

Ive run a couple of different test gcodes through and so far no issues.

Updated Binary

Your binary is working on everything I throw at it so far. I keep you up to date if I see anything strange.

Quote
dot_bob
Your binary is working on everything I throw at it so far. I keep you up to date if I see anything strange.

Thanks for the extra testing. I've also been testing it with a number of different GCode over the weekend and no issues either. I even did some testing with apache ab to request M114 500 times during a print and with DWC running and it handled that as well.

Fixed a typo in pins_lpc.h so it now correctly looks for firmware.bin when updating firmware via networking.

Also included a modified version of DWC V2-RC5 to add lpc as a known board, so when uploading firmware.bin file it will now prompt to update the firmware (like it does on the duets) to save entering the GCode to request the update. I also changed it so when you edit board.txt via DWC it will ask if you want to reset the board like it does with config.g.

Firmware and DWC v2-RC5

Hi, you wrote that you wanted to experiment with ESP 32. Is anything working?

Quote
svs072477
Hi, you wrote that you wanted to experiment with ESP 32. Is anything working?

What controller board uses this chip ?

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Quote
svs072477
Hi, you wrote that you wanted to experiment with ESP 32. Is anything working?

Yeah, it is getting close to working I think, only work on it now and again though. I've basically taken the whole Networking folder from RepRapFirmware and have it running on the ESP32 (only HTTP at this point). So most of the transfers between the LPC<->ESP (over SPI) are JSON status updates and File download/uploads from/to the SD Card and all the networking is handled by the ESP. This moves all the large memory buffers to the ESP and freeing up lot of memory on the LPC board - only requiring the memory buffers for the SPI transfers. The wifi, loading files, getting json status updates etc is currently working, so its slowly getting there.

A while back I did also have a partial port of RepRapFirmware 2.01 running on the ESP32 as well - just enough to compile and with SDCard, run/respond to gcodes etc. Mostly as something to do while learning the ESP32 IDF.

New binary updated to RepRapFirmware 2.03 Beta3.

Also includes an LPC networking update when using DHCP to address an issue that prevented the networking from working again if the cable was unplugged and plugged back in (or the hardware for some reason dropped the link) or when renewing the DHCP lease.

Quote
JoVo
could it be that web control something cached? Now lot of hour later webgui is stable (I configured dual-z today - works also )
Last issue for me is Temperature (Chart) this is not a straight line - it has a lot of spikes up to 10 C ° most of them up to 5 °.
For some test prints, the system was stopped due to incorrect temperature. PID was done.

Hello, is there any solution to this problem? my board (MKS SBASE 1.3) has the same issue. Thanks in advance

Quote
tripio2000

Quote
JoVo
could it be that web control something cached? Now lot of hour later webgui is stable (I configured dual-z today - works also )
Last issue for me is Temperature (Chart) this is not a straight line - it has a lot of spikes up to 10 C ° most of them up to 5 °.
For some test prints, the system was stopped due to incorrect temperature. PID was done.

Hello, is there any solution to this problem? my board (MKS SBASE 1.3) has the same issue. Thanks in advance

If the temp readings are stable after running M84 (to disable the motors) then it's likely noise from the motors is affecting it. As mentioned earlier in the thread (previous page), ensure the thermistor is wired correctly etc.

M570 can be used to configure what is considered a "fault" for the heaters. The documentation says the P param sets the time in seconds that the fault must persist before raising a heating fault (default of 5 seconds), and the T param sets the allowed excursion from the setpoint (default of 15C). So if using the defaults, and that is what is being triggered on your printer, then it must be a lot of noise affecting the ADC readings.

Also, I'm not very familiar with the protections in RRF, so I'm not sure if a spike that exceeds the Max Temp (as set in M143) obeys the persist time rule from M570 or if it is triggered instantly - if it is instant, then printing at temps near the max temp with noise spikes may also be something to look at.

Hi,

Duet Maestro was my solution - the SBASE waste a lot of my time. The spikes could be a hardware issue - couldn't stop that on my board.

Edited 1 time(s). Last edit at 04/28/2019 10:13AM by JoVo.

ok, thank you very much Sdavi, i will try it.

Quote
sdavi
Yeah, it is getting close to working I think, only work on it now and again though. I've basically taken the whole Networking folder from RepRapFirmware and have it running on the ESP32 (only HTTP at this point). So most of the transfers between the LPC<->ESP (over SPI) are JSON status updates and File download/uploads from/to the SD Card and all the networking is handled by the ESP. This moves all the large memory buffers to the ESP and freeing up lot of memory on the LPC board - only requiring the memory buffers for the SPI transfers. The wifi, loading files, getting json status updates etc is currently working, so its slowly getting there.

That's how we used to run networking on the Duet WiFi, except on ESP8266 instead of ESP32. But now we run the HTTP server, FTP etc. on the Duet main processor and the ESP just provides a TCP/IP socket interface. We did this because the closed-source nature of the ESP8266 code (including the interface to Lwip) made it difficult to diagnose problems, it was more difficult to update the web server files on the ESP than on the SD card, it took too long to upload the web files into the ESP8266 during manufacturing, and we wanted more common code with the Duet Ethernet.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].