RepRapFirmware 3.0 port for LPC1768/9 based boards

Quote
jay_s
Can you install the latest test version 3.1.1-8 from gloomyandys post a few posts back?
There's been a number of fixes since that release

Sorry, I don't see any download link for gloomyandys v3.1.1-8 few posts back

---

== Customized Ender 3 Pro ==
- SKR v1.4 Turbo + TMC2208 in UART Mode (and parked TMC2209) -
- Micro Swiss Direct Drive + All Metal Hotend -
- Noctua fans everywhere -
- ...and other modifications... -

There are two sets of test builds available at the moment:
3.1.1-7: [drive.google.com]
3.1.1-9: [drive.google.com]

You should probably try 3.1.1-9 but if you hit problems please report them (along with M122 output when the firmware reboots) and try the 3.1.1-7 version.

Ah. Didn't realise gloomyandy had started a new thread with the latest builds

---

Based in Darlington, North East

Quote
gloomyandy
I doubt if that TMC51xx support will work without a reasonable amount of work. The Duet 51xx support expects to use hardware SPI and it is all for a different set of processors (various SAMExx versions) which have a different hardware SPI unit to the LPC17xx used by this port. It certainly won't be just a case of setting the compiler option. What aspects of the 5160 do you need? Have you considered using 2209s?

I've already ordered 5 TMC5160 from China. I'll check the schematic, maybe I can make something work. Thanks for the update.

Quote
gloomyandy
There are two sets of test builds available at the moment:
3.1.1-7: [drive.google.com]
3.1.1-9: [drive.google.com]

You should probably try 3.1.1-9 but if you hit problems please report them (along with M122 output when the firmware reboots) and try the 3.1.1-7 version.

Thanks for test firmware gloomyandy, I've installed 3.1.1-9 and started printing, after 1h and 30 mins it works like a charm, no issues for now!
I'll see tomorrow morning if all ok!

Thanks again

---

== Customized Ender 3 Pro ==
- SKR v1.4 Turbo + TMC2208 in UART Mode (and parked TMC2209) -
- Micro Swiss Direct Drive + All Metal Hotend -
- Noctua fans everywhere -
- ...and other modifications... -

@sdavi Regarding your build, I noticed a strange problem when issuing commands from the TFT32 panel. It takes tens of second between their execution ????

PS: So many different developments going on on this firmware regarding various peripherals like Stepper driver, WiFi module, display ... that I am concerned !

---

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

@MKSA what is it you are concerned about? All of my developments will be merged back into my main branch once it looks like there are no major problems with the recent changes I've made. All of the "new" developments are compatible with older configurations (so although I've added TMC2209 support, TMC2208s still work fine), same with the WiFi updates, these are just new features. I'm sure at some point SDavi will make his changes public and I'll be happy to merge any fixes/improvements into my build. But it sounds like the ethernet fixes he has made have not helped with your slow downloads (which I've not been able to reproduce), which is a pity.

@sdavi An other issue, still related to the TFT32 communication, strange but dangerous:

From DWC (works but takes about 15 minutes to load as already mentioned), system works. I can home, set T°, print ....

BUT from the TFT32 when I set the hotend to say 130° (in fact any temp) , the T° keeps rising, never stopping ! I had to cut the power in an emergency as it was going beyond 350° !!!
Somewhat this TFT32 com issue must screw up the system because my Heaters set up is OK as I have not this when I control via DWC.

@gloomyandy My concern is illustrated by the above. Firmware change that corrupt other, even unrelated modules !

---

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

Quote
MKSA
@sdavi An other issue, still related to the TFT32 communication, strange but dangerous:

From DWC (works but takes about 15 minutes to load as already mentioned), system works. I can home, set T°, print ....

BUT from the TFT32 when I set the hotend to say 130° (in fact any temp) , the T° keeps rising, never stopping ! I had to cut the power in an emergency as it was going beyond 350° !!!
Somewhat this TFT32 com issue must screw up the system because my Heaters set up is OK as I have not this when I control via DWC.

@gloomyandy My concern is illustrated by the above. Firmware change that corrupt other, even unrelated modules !

That is strange. As I mentioned that was an early build that included a number of changes which needed extra caution - although I have been testing it a quite a lot but there must be a some odd issue going on (there may be issue with the dma rx which i'll look into such as an overrun or something). It's also strange that if something got "stuck" that it didn't reset. I'd suggest reverting back to a stable version. I debug over UART0 and haven't seen any issues like that with the new version so that is very odd. Are you using the original TFT firmware or the modified version to work in paneldue mode?

I think there is only about 2 reports of people with that slow networking issue and both are using sbase. I'm not sure if they all are affected or not, or if anyone else on another board has had it, I don't have that sort of info as you only usually hear about the things that don't work or sometimes people will try something doesn't work and just delete it and not say anything. I did add an extra variable in that test build to report if the driver was dropping Tx packets and will show in M122 if its non-zero, but I don't think that should happen as they should be reserved just for tx. I spent quite a while recently with the network code and i'm not sure what else it could be. Unfortunately, that's something I've never seen or able to replicate.

@SDavi as an extra data point, I have an SBase (as I think does Jay_S) and have not been able to reproduce the slow download of DWC (and I've tried it on a couple of different routers and over powerline adaptors), in all of those cases DWC downloads in about a minute for me. I have however seen the problem (that I think you have a fix for) of the connection sometimes connecting at 10Mbit rather than 100Mbit. The only major problem I've seen was caused by the use of an invalid MAC address because a default was not being set on the LPC port.

@MKSA Unfortunately that is the nature of software development, especially with real time systems like these. Sometimes changes in one part of the system can have an impact on other parts that the developer did not anticipate. Before I make builds public I try to test things as much as I can. I have there test systems - SKR V1.4 with WiFi, SKR V1.3 with SBC and SBase with ethernet and I try to make sure that the builds work on all of them, I also check that running with USB terminal connections and a PanalDue work on those systems. But doing all of that is a lot of effort and will still not reproduce all of the variations that people using the firmware are likely to create. That's why we need the help of users to test things. In the case of my recent developments (which contain a lot of changes), I asked Jay_S to test things for me before making things more widely available to try and spot any major issues. When I did make the builds available I tried to make it clear that this is a test build. I'm really not sure what the alternative is, but I'd be happy to hear any suggestions.

Quote
sdavi

Quote
MKSA
@sdavi An other issue, still related to the TFT32 communication, strange but dangerous:

From DWC (works but takes about 15 minutes to load as already mentioned), system works. I can home, set T°, print ....

BUT from the TFT32 when I set the hotend to say 130° (in fact any temp) , the T° keeps rising, never stopping ! I had to cut the power in an emergency as it was going beyond 350° !!!
Somewhat this TFT32 com issue must screw up the system because my Heaters set up is OK as I have not this when I control via DWC.

@gloomyandy My concern is illustrated by the above. Firmware change that corrupt other, even unrelated modules !

That is strange. As I mentioned that was an early build that included a number of changes which needed extra caution - although I have been testing it a quite a lot but there must be a some odd issue going on (there may be issue with the dma rx which i'll look into such as an overrun or something). It's also strange that if something got "stuck" that it didn't reset. I'd suggest reverting back to a stable version. I debug over UART0 and haven't seen any issues like that with the new version so that is very odd. Are you using the original TFT firmware or the modified version to work in paneldue mode?

I think there is only about 2 reports of people with that slow networking issue and both are using sbase. I'm not sure if they all are affected or not, or if anyone else on another board has had it, I don't have that sort of info as you only usually hear about the things that don't work or sometimes people will try something doesn't work and just delete it and not say anything. I did add an extra variable in that test build to report if the driver was dropping Tx packets and will show in M122 if its non-zero, but I don't think that should happen as they should be reserved just for tx. I spent quite a while recently with the network code and i'm not sure what else it could be. Unfortunately, that's something I've never seen or able to replicate.

I reverted to RRF 2.0 that works but for the slow DWC initial loading still present in RRF 3. May be some issue with my board. All the rest has been changed, tried (PC, network, router, direct...)

Indeed this T° running havoc got me by surprised ! The smell ! Fact, it exceeded 400°. No harm, my own designed full metal hotend.

The TFT32 is original, in fact it is just a crude pronterface sending/receiving Gcode via serial. Works OK with RRF 2 (in fact you make it work), with RRF 3, it takes more than 10 seconds for the orders to be executed. Plus the serious issue above.

Note: I may go for an other 32bits board as the Sbase use the infamous 8825 stepper drivers and they are soldered.

---

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

Quote
gloomyandy
@SDavi as an extra data point, I have an SBase (as I think does Jay_S) and have not been able to reproduce the slow download of DWC (and I've tried it on a couple of different routers and over powerline adaptors), in all of those cases DWC downloads in about a minute for me. I have however seen the problem (that I think you have a fix for) of the connection sometimes connecting at 10Mbit rather than 100Mbit. The only major problem I've seen was caused by the use of an invalid MAC address because a default was not being set on the LPC port.

@MKSA Unfortunately that is the nature of software development, especially with real time systems like these. Sometimes changes in one part of the system can have an impact on other parts that the developer did not anticipate. Before I make builds public I try to test things as much as I can. I have there test systems - SKR V1.4 with WiFi, SKR V1.3 with SBC and SBase with ethernet and I try to make sure that the builds work on all of them, I also check that running with USB terminal connections and a PanalDue work on those systems. But doing all of that is a lot of effort and will still not reproduce all of the variations that people using the firmware are likely to create. That's why we need the help of users to test things. In the case of my recent developments (which contain a lot of changes), I asked Jay_S to test things for me before making things more widely available to try and spot any major issues. When I did make the builds available I tried to make it clear that this is a test build. I'm really not sure what the alternative is, but I'd be happy to hear any suggestions.

Even 1 minute is slow compared to what i see on my boards, smoothieboard and mbed dev board loads up dwc in about 5 or so seconds. There isn't much of a difference between the wifi and eth loading times for me. It would be interesting to see if there are any CRC errors etc looking at the packets in wireshark.

That's right. Debugging on embedded platforms can be quite challenging, especially with interrupts and DMA in the mix. With the mbed I can at least use GDB to do a lot of debugging which really helps find certain issues. I've even been using the new daemon.g file in RRF to continuously ramp up and down a couple of extra outputs with PWM (connected to LEDs so i can see them working) to try and push the PWM code while heaters are running and doing test prints. I only have a azteeg x5 mini, a smoothieboard (which is on a CNC) and an old RRF full graphic LCD so testing lots of combinations is not possible. I use a FTDI connected to aux serial to make sure that still works, but no paneldue, tft etc. Of course it's extremely difficult to track down an issue you can't consistently replicate yourself. I also don't have access to any oscilloscopes, protocol analysers etc which can make some debugging a lot harder too.

@SDavi, due to the UK lockdown (which is still sort of ongoing), I'm away from home so I don't have access to scope, logic probes or my usual desktop PCs etc. In particular I only have a couple of laptops here and neither of those have an ethernet interface (only WiFi), I don't think there is anyway I can run Wireshark to check for errors on the SBase board as I won't see the SBase packets via the WiFi interface (I'm pretty sure the router has a switch rather than hub and that the packets will not make it through), but if anyone knows otherwise I'd be happy to give it a try!

Quote
sdavi
....

CoreLPC Updates

...

[*] DMA for UART0 (default AUX serial):

• Circular RX Ringbuffer implemented entirely with DMA (zero interrupts).
• TX data is sent out in a block via DMA rather than using the interrupt driven ringbuffer. Since the data comes from output buffers in RRF, and it attempts to write as much as possible each attempt this method seems to work well (and only 1 interrupt at the end of each block of data sent).

[/list]

May be there lies the bug causing the slow handling of commands issue by the TFT32 and the heaters running havoc I described earlier.

---

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

Quote
gloomyandy
I don't think there is any limitations on the pins the can be used for stepper drivers. However the current builds of RRF only support up 5 drivers, so if you want to use more you will need to modify the firmware and rebuild it

Man,I stuck in trouble to modify the rrf to support 7 steppers because i dont know the exactly file to be modify.Is there some routine or docs?

The setting to control the number of drivers supported on the main board is NumDirectDrivers but I've no idea if other changes will be needed.

Hi,
I've just released a new version of firmware that contains the updates to support the TMC2209 and other fixes covered in this thread: [reprap.org]

The released files can be found here:
[github.com]

Quote
gloomyandy
The setting to control the number of drivers supported on the main board is NumDirectDrivers but I've no idea if other changes will be needed.

Thank you very much! I will give it a try.

Oh,may be i should add stepper en,dir,stp pins to the baord config.

You will obviously have to add the extra ones, but the standard ones are already there as is the mechanism to define them in board.txt.

Quote
sdavi
....

CoreLPC Updates

...

[*] DMA for UART0 (default AUX serial):

• Circular RX Ringbuffer implemented entirely with DMA (zero interrupts).
• TX data is sent out in a block via DMA rather than using the interrupt driven ringbuffer. Since the data comes from output buffers in RRF, and it attempts to write as much as possible each attempt this method seems to work well (and only 1 interrupt at the end of each block of data sent).

[/list]

@gloomyandy This is what concerns me. Changes affecting unrelated modules. Thanks

Bumping up this issue.

May be there lies the bug causing the slow handling of commands issue by the TFT32 and the heaters running havoc I described earlier.

---

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

@MKSA

Those changes are only in sdavi's build. Gloomyandy doesn't have access to sdavi's changes.

---

Based in Darlington, North East

Quote
jay_s
@MKSA

Those changes are only in sdavi's build. Gloomyandy doesn't have access to sdavi's changes.

I know. See earlier commenst. Biocomputer experiencing memory leak, stack overflow ?

---

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

hi guys, i must do something wrong because i cant connect to my wifi...im using yat to setup my wifi network, but i cant figure out why it cant connect,i send M552 S0, after that i send M587 S"wifi ssid"P"password" and it disconnect from yat.
i folow the intruction from gloomyandy github, i wire my nodemcu v2 to skr1.3 folowind the instruction, i create the sd card files as per instructions, i add the board.txt to sys folder with the wifi lines in it..
this is my M122

=== Diagnostics ===
RepRapFirmware for LPC176x based Boards (biquskr_1.3) version 3.1.1-12 running on LPC176x at 100Mhz
Used output buffers: 1 of 16 (1 max)
=== RTOS ===
Static ram: 4516
Dynamic Memory (RTOS Heap 5): 2168 free, 2144 never used
Exception stack ram used: 248
Never used ram: 436
Tasks: NETWORK(ready,1992) HEAT(blocked,1376) MAIN(running,1460) IDLE(ready,80)
Owned mutexes:
=== Platform ===
Last reset 00:00:20 ago, cause: [power up][reset button]
LPC Flash Slot[24]:
Last software reset time unknown, reason: Hard fault, spinning module GCodes, available RAM 228 bytes (slot 0)
Software reset code 0x0863 HFSR 0x40000000 CFSR 0x00000400 ICSR 0x0442a803 BFAR 0xe000ed38 SP 0x2007d274 Task MAIN
Stack: 00048503 0004e484 81000000 00000000 00000aa1 10002d5c 00000001 10003d68 2007da2c 2007d350
Stack: 10003d68 00000000 2007d7a4 10002d58 00000000 2007da2c 00048c5f 00000000 00000000 2007d350
Stack: 00000030 2007dc9c 0004eb00
Error status: 0
Driver 0: ok, SG min/max N/A, error r/w 0/0, ifcnt 0, cnt r/w 0/0, timeout 376, failedOp 0x80
Driver 1: ok, SG min/max N/A, error r/w 0/0, ifcnt 0, cnt r/w 0/0, timeout 376, failedOp 0x80
Driver 2: ok, SG min/max N/A, error r/w 0/0, ifcnt 0, cnt r/w 0/0, timeout 376, failedOp 0x80
Driver 3: ok, SG min/max N/A, error r/w 0/0, ifcnt 0, cnt r/w 0/0, timeout 375, failedOp 0x80
Driver 4: ok, SG min/max N/A, error r/w 0/0, ifcnt 0, cnt r/w 0/0, timeout 375, failedOp 0x80
Date/time: 1970-01-01 00:00:00
Slowest loop: 4.01ms; fastest: 0.40ms
Watchdog timer: 6243479/6250000
Step timer: target 0 count 20826575 delta -20826576 late 0
USBSerial connected 1
ADC not ready 0 ADC error threshold 10 ADC Init 1
Ints: 20538; Calls 20538; fast: 3uS; slow 20uS adj 0 bad 0 big delta 0
PWM Channels
state 0 next 10675 on 25000 off 25000 pin 2.3
=== Storage ===
Free file entries: 4
SD card 0 detected
SD card longest read time 1.9ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0, FreeDm: 100, MinFreeDm: 100, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== Heat ===
Bed heaters = -1, chamberHeaters = -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
File is idle in state(s) 0
USB is ready with "m122" 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 0.57ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0)
HTTP sessions: 0 of 2
- WiFi -
Network state is starting2
WiFi module is disabled
Failed messages: pending 0, notready 0, noresp 0
Socket states: 0 0
ok


this is my M115
FIRMWARE_NAME: RepRapFirmware for LPC176x based Boards FIRMWARE_VERSION: 3.1.1-12 ELECTRONICS: LPC176x FIRMWARE_DATE: 2020-27-6b12
ok


config.g file

; Configuration file for SKR v1.3 (firmware version 3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v2.1.4 on Thu Jul 02 2020 17:33:17 GMT+0100 (Hora de verão da Europa Ocidental)

; General preferences
G90 ; send absolute coordinates...
M83 ; ...but relative extruder moves
M550 P"kelvin" ; set printer name

M667 S1 ; select CoreXY mode

; Network
M552 S0 ; disable network

; Drives
M569 P0 S1 ; physical drive 0 goes forwards using default driver timings
M569 P1 S1 ; physical drive 1 goes forwards using default driver timings
M569 P2 S1 ; physical drive 2 goes forwards using default driver timings
M569 P3 S1 ; physical drive 3 goes forwards using default driver timings
M584 X0 Y1 Z2 E3 ; set drive mapping
M92 X80.00 Y80.00 Z400.00 E420.00 ; set steps per mm
M566 X900.00 Y900.00 Z12.00 E120.00 ; set maximum instantaneous speed changes (mm/min)
M203 X6000.00 Y6000.00 Z180.00 E1200.00 ; set maximum speeds (mm/min)
M201 X500.00 Y500.00 Z20.00 E250.00 ; set accelerations (mm/s^2)
M906 X800 Y800 Z800 E800 I30 ; set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout

; Axis Limits
M208 X0 Y0 Z0 S1 ; set axis minima
M208 X200 Y200 Z300 S0 ; set axis maxima

; Endstops
M574 X1 S1 P"xstop" ; configure active-high endstop for low end on X via pin xstop
M574 Y1 S1 P"ystop" ; configure active-high endstop for low end on Y via pin ystop
M574 Z1 S2 ; configure Z-probe endstop for low end on Z

; Z-Probe
M558 P5 R0.4 C"zstop+xstopmax" H5 F1200 T6000 ; set Z probe type to effector and the dive height + speeds
G31 P500 X0 Y0 Z2.5 ; set Z probe trigger value, offset and trigger height
M557 X10:190 Y10:190 S20 ; define mesh grid

; Heaters
M308 S0 P"bedtemp" Y"thermistor" T100000 B4138 ; configure sensor 0 as thermistor on pin bedtemp
M950 H0 C"bed" T0 ; create bed heater output on bed and map it to sensor 0
M143 H0 S120 ; set temperature limit for heater 0 to 120C
M307 H0 B0 S1.00 ; disable bang-bang mode for the nozzle heater and set PWM limit
M308 S1 P"e0temp" Y"thermistor" T100000 B4138 ; configure sensor 1 as thermistor on pin e0temp
M950 H1 C"e0heat" T1 ; create nozzle heater output on e0heat and map it to sensor 1
M143 H1 S280 ; set temperature limit for heater 1 to 280C
M307 H1 B0 S1.00 ; disable bang-bang mode for the nozzle heater and set PWM limit

; Fans
M950 F0 C"fan0" Q500 ; create fan 0 on pin fan0 and set its frequency
M106 P0 S0 H T45 ; set fan 0 value. Thermostatic control is turned on

; Tools
M563 P0 D0 H1 F0 ; define tool 0
G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets
G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C

; Custom settings are not defined

Edited 2 time(s). Last edit at 07/03/2020 02:35AM by weed2all.

Please post...
* A picture of your board and WiFi module so we can see how you have it set up.
* The contents of your board.txt file
* The output from M122 P200

Have you flashed the WiFi firmware to your WiFi module?
What stepper driver modules are you using, they are currently all reporting errors.

Quote
gloomyandy
Please post...
* A picture of your board and WiFi module so we can see how you have it set up.
* The contents of your board.txt file
* The output from M122 P200

Have you flashed the WiFi firmware to your WiFi module?
What stepper driver modules are you using, they are currently all reporting errors.

thank you for your fast response...it was actualy my fault...i wire everything but somehow i forget to add the 2200r resistor between ground and reset pin and thats why didnt work...i gone thru wireing everything again and seen that 2200r resistor was left out of wiring...boomer
now is working as it should

actualy no stepper drivers were installed just because i was only testing before wire everything, i'll use tmc2208 for all axis

thank you for your fast response...it was actualy my fault...i wire everything but somehow i forget to add the 2200r resistor between ground and reset pin and thats why didnt work...i gone thru wireing everything again and seen that 2200r resistor was left out of wiring...boomer
now is working as it should

actualy no stepper drivers were installed just because i was only testing before wire everything, i'll use tmc2208 for all axis

so for setting up the uart of tmc2208 i need to put the jumper on uart as when use with marlin and add this line "stepper.numSmartDrivers = 4" to board.txt

How about having a separate thread for each developer/build ?

---

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

hi
just received the lpc board for my skr 1.4 for the rep rap conversion and i m looking for a tutorial of how to......

thanks