RepRapFirmware 3.0 port for LPC1768/9 based boards

No problem.
I will transplant the SKR into a spare machine I have and start testing

---

Based in Darlington, North East

OK I think I've managed to merge my changes into the V3.01 version (which was remarkably painless - git is not my strongest skill!) and it seems to be working (WiFi, TMC config, simple motor moves). I was fooled for a little while by firmware.bin now being in a different place!

So a quick question I'm currently using WiFi firmware v1.23 and the standard (not sdavi's version) V2.04 of DWC is this the best combination to use (I think there may be a later DWC now)?

My 3.01 changes are at:
[github.com]
Build system changes:
[github.com]

I believe sdavi's version of DWC would recognise when a new firmware.bin file had been uploaded and ask the user to install, thats it.
1.23 is the latest wifi firmware as far as I know and DWC is now at 2.0.6. Definitely worth the upgrade as there was a number of bugs fixed.

---

Based in Darlington, North East

@gloomyandy Did you by any chance happen to give this a go for the software UART: [github.com]

I think that is a nice solution utilising the GPDMA on the LPC17xx.

Edited 2 time(s). Last edit at 01/18/2020 06:42AM by sdavi.

It is a nice solution (and I had a good look at it when adding software serial to Marlin) but it uses a lot of resources (3 256 byte memory buffers, plus one of the general purpose timers and the gpdma channel). I'm not that familiar with the reprap LPC implementation so I'm not sure if those resources are available for use or not. I was particularly conscious of how tight memory is. It also makes use of FIOMASK (to restrict the dma writes to a single output bit on the port), but I'm not sure what impact using that might have on other I/O operations on the same port while the dma transfer is active (it certainly seems to impact some of them). It would be interesting to see if it could be made to work though as the dma usage would avoid the errors I see due to other parts of the system either disabling interrupts or higher priority interrupts running.

Quote
gloomyandy
It is a nice solution (and I had a good look at it when adding software serial to Marlin) but it uses a lot of resources (3 256 byte memory buffers, plus one of the general purpose timers and the gpdma channel). I'm not that familiar with the reprap LPC implementation so I'm not sure if those resources are available for use or not. I was particularly conscious of how tight memory is. It also makes use of FIOMASK (to restrict the dma writes to a single output bit on the port), but I'm not sure what impact using that might have on other I/O operations on the same port while the dma transfer is active (it certainly seems to impact some of them). It would be interesting to see if it could be made to work though as the dma usage would avoid the errors I see due to other parts of the system either disabling interrupts or higher priority interrupts running.

I was thinking more along the lines of just using the DMA approach with bitbanding in the current code.

In RRF3 LPC, timer1 is free, and only 4 DMA channels have been allocated (for SSP 0 and 1).

I checked the addresses for registers of the reading/writing the GPIO and it's within the BB region, as is setting pin directions. The manual also states that the bit-banding provides atomic operations to the bit data. I've just implemented this now in the core code for functions that set the direction, and write to a port (more on that later). So if using the BB alias address of the bit in FIOPIN and FIODIR in the DMA transfer for the pin writes and direction changes instead of FIOPIN and FIODIR, then I think that should avoid the need of using FIOMASK (as long as we are careful/doing that every where else too). *(also assuming i've followed all this correctly of course).

Only boards that have all steppers on port2 have a parallel write and that relies on FIOMASK not being changed as its using the SET and CLR. We don't set fiomask but assume it hasn't been changed)

All this did bring up an interesting point, writing ports bits or setting pin directions that get interrupted (after the read but before the write) and inside that interrupt sets/clears a pin on the same port, I guess is a real possibility. So I've edited the core to use the BB (instead of just stopping ints all the time) in GPIO_PinFunction, GPIO_PinDirection and GPIO_PinWrite which are called from pinmode and digitalWrite. There is no special bits on those registers so I think using the BB won't cause any issues. This should hopefully also prevent similar problems if going ahead with the DMA soft uart too.

If your keen to try DMA instead of the RIT+int, i've added an extra channel to be assigned in InitialiseDMA (in core) which sets up the DMA and assigns some channels and also the callback handler for finish int (if desired) which I added for SSP DMA not long ago.

That sounds very interesting! I'd certainly like to give it a try. But I think I need to spend some time reading up on bitbanding! Are there examples of using bitbanding already in the code?

Quote
gloomyandy
That sounds very interesting! I'd certainly like to give it a try. But I think I need to spend some time reading up on bitbanding! Are there examples of using bitbanding already in the code?

Yeah it is interesting, I only discovered it last night - what a great feature I never knew existed I added a new headerfile and edited gpio.c here: [github.com] and there is a section about bitbanding in the lpc user guide 34.3.2.

The networking version doesn't build due to missing files.
The RTOSPlusTCPEthernet folder is missing from the 3.01 branch. It is a case of just copying it from the 3.0 branch?

Edit: adding those files back in allow it to be built so it looks at though it's just the folder of files missing from 3.01

Edited 1 time(s). Last edit at 01/19/2020 04:13AM by jay_s.

---

Based in Darlington, North East

Quote
jay_s
The networking version doesn't build due to missing files.
The RTOSPlusTCPEthernet folder is missing from the 3.01 branch. It is a case of just copying it from the 3.0 branch?

Update lpc core from git, I fixed the makefile a couple of days ago for that. I moved all the LPC files that are additional to RRF into the LPC dir now so its all together.

That builds ok.
I have it running on an MKS SBase I had lying around.

---

Based in Darlington, North East

@gloomyandy I was having a play with the DMA and bitbanding today and looks like it's a no go. If I put a BB address into src or dst for DMA it doesn't seem to like it.

I've merged in the TMC22xx from gloomyandy repository onto v3.01-dev-lpc-tmc22xx branch here: [github.com] can someone check this to make sure its still working before I merge into the main 3.01 branch ?

@sdavi that's a real pity, I'd started hacking some code together to do this, but have not tried running it yet. There is surprisingly little information around on the subject. I did dig this up... [community.nxp.com] which would seem to indicate that the bit-banded "memory" only exists within the arm core and so the gpdma does not see these addresses as memory.

Hi,
so I think I may have figured out a way to use DMA for the TMC22xx UART. I'm still experimenting a little, but I think it will work. I've just noticed though that you are now using TIMER1 for the ADC smoothing code, are there any other free timers available?

Quote
gloomyandy
Hi,
so I think I may have figured out a way to use DMA for the TMC22xx UART. I'm still experimenting a little, but I think it will work. I've just noticed though that you are now using TIMER1 for the ADC smoothing code, are there any other free timers available?

• Timer 0 - Step Generation
• Timer 1 - (currently optional ADC filter as of yesterday - could be disabled in TMC builds)
• Timer 2 - Software Servo PWM - This is only a backup for pins for servo that are not on a HW PWM pin. However this probably isn't needed anymore and was just a left over from previous version and kept just cause the timer was free. Software PWM timer could probably just be used for that, so this could be freed up. Hopefully most boards are using HWPWM pins for servos - should check that.
• Timer 3 - Software PWM - Used for heater and fan PWM.

Quick update. I now how a working DMA based UART that seems to work pretty well. This code has a much lower interrupt overhead than that from the previous pure timer based version. It generates a single interrupt per byte being transmitted and just a single interrupt at the end of the receive, this compares with 3 interrupts per byte for both transmit and receive with the timer solution. I'm still working on improving some aspects of the code (reducing memory if possible, it currently requires around 500bytes). One problem I have seen is the occasionally the TMC2208 does not send a response. Hooking up a logic analyser revealed that this was because occasionally there was a glitch in the data being written to the driver, which resulted in the TMC2208 not recognising the command. This was being caused by the dma write occurring between the read modify write operation used in digitalWrite, I'm pleased to say that updating to the latest version from sdavi (and so picking up the bit banding implementation of digitalWrite has fixed that problem).

My version of the DMA UART is based on the original code by Artem-B that was linked above. However that had some problems during write operations that made it unsuitable for use with RRF. The main issue was the use of FIOMASK to enable writes via DMA to only a single bit. My version avoids this issue by creating a chain of linked DMA control blocks one per bit of the UART write data. Each control block writes to either FIOSET or FIOCLR (which allows writing to a single bit of the port). The read side of things follows the same basic scheme used in the original code (though switching from output to input is handled differently to avoid issues with the read modify write nature of the original). I'm still experimenting with the best possible configuration of this code, but it is looking promising.

A quick question for anyone with a duet that uses TMC22XX devices (@dc42 perhaps), do you ever get any read/write or timeout errors on the TMC I/O (shown by M122)? I'm still seeing some errors, but I'm curious if this is completely down to the use of a software UART or if there are still errors when using the hardware implementation?

Quote
gloomyandy
Quick update. I now how a working DMA based UART that seems to work pretty well. This code has a much lower interrupt overhead than that from the previous pure timer based version. It generates a single interrupt per byte being transmitted and just a single interrupt at the end of the receive, this compares with 3 interrupts per byte for both transmit and receive with the timer solution. I'm still working on improving some aspects of the code (reducing memory if possible, it currently requires around 500bytes). One problem I have seen is the occasionally the TMC2208 does not send a response. Hooking up a logic analyser revealed that this was because occasionally there was a glitch in the data being written to the driver, which resulted in the TMC2208 not recognising the command. This was being caused by the dma write occurring between the read modify write operation used in digitalWrite, I'm pleased to say that updating to the latest version from sdavi (and so picking up the bit banding implementation of digitalWrite has fixed that problem).

My version of the DMA UART is based on the original code by Artem-B that was linked above. However that had some problems during write operations that made it unsuitable for use with RRF. The main issue was the use of FIOMASK to enable writes via DMA to only a single bit. My version avoids this issue by creating a chain of linked DMA control blocks one per bit of the UART write data. Each control block writes to either FIOSET or FIOCLR (which allows writing to a single bit of the port). The read side of things follows the same basic scheme used in the original code (though switching from output to input is handled differently to avoid issues with the read modify write nature of the original). I'm still experimenting with the best possible configuration of this code, but it is looking promising.

A quick question for anyone with a duet that uses TMC22XX devices (@dc42 perhaps), do you ever get any read/write or timeout errors on the TMC I/O (shown by M122)? I'm still seeing some errors, but I'm curious if this is completely down to the use of a software UART or if there are still errors when using the hardware implementation?

Did you also increase the DMA int priority? At the moment its only at SPI priority level and will most likely need to be higher than step int.

I haven't yet but it is one of the things on my list to try as I'm investigating the errors I'm still getting. I may also change the priority order for the DMA channels to give the "UART" a higher priority to see if that helps. One "problem" I now have is that I've reduced the number of errors a lot so it takes a fair bit of time to get them to occur, so testing can be slow.

Hmm that's interesting (and puzzling), if I set the priority used by the GPDMA to anything below 5 then my board hangs (or at least it never appears as a USB device on my PC). It does the same both with and without my DMA UART code enabled. Any idea what may be going on? Not sure if it matters but I have the esp wifi code enabled and have a WiFi module attached but not enabled (I usually issue the M552 S1 command to enable it via a USB terminal connection). The USB interrupt is at priority 5, I wonder if there is any sort of interaction?

Quote
gloomyandy
Hmm that's interesting (and puzzling), if I set the priority used by the GPDMA to anything below 5 then my board hangs (or at least it never appears as a USB device on my PC). It does the same both with and without my DMA UART code enabled. Any idea what may be going on? Not sure if it matters but I have the esp wifi code enabled and have a WiFi module attached but not enabled (I usually issue the M552 S1 command to enable it via a USB terminal connection). The USB interrupt is at priority 5, I wonder if there is any sort of interaction?

That is cause the SSP DMA handlers make use of GiveFromISR functions from FreeRTOS, and in the FreeRTOS config has configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY set to priority 5, which is the highest interrupt priority isr that you can make calls to interrupt safe FreeRTOS calls.

Hopefully 5 will be ok for the softuart - after the software PWM but before the step int which is at 6. Fans and Heaters are using the soft PWM so may be best not to use high frequencies for the PWM when configuring those.

Edited 2 time(s). Last edit at 01/25/2020 06:45PM by sdavi.

Also the LPC Manual says it has "32 programmable interrupt priority levels" so we could even shuffle around the int levels above 5 to get the priority order that we need.

Hi,
a quick update on my progress and findings with the TMC22XX support...

I now have two versions of the code working both seem to work pretty well and operate most of the time with no errors. The first is based on my original code and uses timer interrupts to drive the I/O the other uses DMA to carry out all of the operations. The DMA solution requires about 360 extra bytes of RAM (for the sample buffer), but has a much lower interrupt overhead (approx 480/s verses 29000/s with both operating at 9600 baud), but it does have a higher non-interrupt overhead due to the need to process the received sample buffer, but I think overall the DMA solution is the better one. I now have RRF running on my actual printer (with WiFi and TMC22XX support), and everything seems to be working fine (heaters, fans, drivers, probe etc.) so I'm testing things for real now.

A few things about the current version of the code...
1. Although I had thought that the bit banding GPIO read/write code fixed the problems I had been seeing with corruption of the UART output, this was not the case. It was much better than the old code that basically did a read/modify/write on the GPIO PIN register, but I think that somewhere in the depths of the bit band implementation there was still a read/modify/write that can end up being interleaved with DMA write operations. However switching the code to use the GPIO SET/CLR registers seems to fix this problem and I can now operate the UART code with no errors over many hours. I suspect that the current bit banding code may create the occasional error if a pin is written to from an interrupt handler, so I think it would be worth changing the base code to user the SET/CLR mechanism.

2. At the moment my DMA code uses timer 1 which means it is not possible to have this and the ADC smoothing operating at the same time (though I've not seen any problems with the ADC readings on my setup so far). I had a look at the code and it seems to me that it might be possible to replace the current use of Timer 3 with the RIT timer and that would allow the use of Timer 3 for this UART code. Does that make sense to you? If so I'll have a look at actually making it work.

3. I'm a little unsure about how to configure the pins for the UART connections (I need one pin per device). Up until now I'd been using a board.txt and simply adding the extra configuration in there as an extra named array of pins. This worked fine when I did not have a the board type set (so it was using the generic board type I guess). However when I switched to using the SKR 1.3 or SKR 1.4 boards I hit a problem. At the moment you can only use pins in a board.txt file that have definitions in the base board definition (so in generic or SKR 1.3 etc). But the SKR board definitions do not by default have any of the pins used for the drivers defined in them. At the moment I've fixed this by simply adding the pins I need to the SKR definitions and then continuing to use an extra entry in the boards.txt file, but this seems a little messy. Any thoughts on the best way to fix this? I could add an extra predefined array of UART pins in the same way that we already have ones for the driver step/dir/enable pins to all of the board definitions, any thoughts?

I'd just like to say how impressed I am with both the base RRF code and the LPC port. Thanks to @dc42 and @sdavi for all of the hard work.

@gloomyandy

1. That sounds fine.
2. Yep also sounds fine.
3. All those pins should be added to the PinTable for the SKRs, assuming they are accessible as headers on the board if users want to do other things with them. I don't have any of those boards so I wasn't sure what was written on the silk so I just left them as comments.

I just noticed there was a bug after updating board.txt to handle the silk names that if the pin is not in the table then it was rejected so I'll fix that.

Hi,
So I've just pushed my fork of the LPC code (up to date with sdavi 3.01 as of today!), containing the latest changes I've made to support a UART interface for TMC22XX devices this version has both the timer based code and the DMA code (setup to use the DMA version by default). I've added the pins needed to the PinTable for the SKRs but I have not yet got around to trying to free up timer3 (next on my list). I've been running this code on my 3D printer and so far everything seems to be working fine during my tests. My git branches are:
[github.com]
[github.com]
the libraries are identical to those from from
[github.com]

A quick question, what pwm frequency makes sense for fans/heaters on the LPC? At the moment I'm just using the default values which I think is 250 (I assume Hz?) and comes from DefaultFanPwmFreq, is this a sensible value for things like the heatbed?

Quote
gloomyandy
A quick question, what pwm frequency makes sense for fans/heaters on the LPC? At the moment I'm just using the default values which I think is 250 (I assume Hz?) and comes from DefaultFanPwmFreq, is this a sensible value for things like the heatbed?

The defaults seem to work well. In RRF2 LPC we only had the 2 default heater frequencies available - 250Hz for hotends (and fans) and 10Hz for heated beds. In RRF3 LPC you can choose what frequency you want (it is generated by interrupts so probably best not to use very high frequencies). The official configtool lists 500Hz as the default fan speed.

@sdavi
Does your wifi password use any numbers?
I've had issues getting my board to connect to a wifi network when there are numbers in the password.
The board reports that the password is incorrect, but if I change the password to all letters, it connects without issue.
Just trying to marrow down if this is something with just me or whether its a more widespread issue.

---

Based in Darlington, North East

Quote
jay_s
@sdavi
Does your wifi password use any numbers?
I've had issues getting my board to connect to a wifi network when there are numbers in the password.
The board reports that the password is incorrect, but if I change the password to all letters, it connects without issue.
Just trying to marrow down if this is something with just me or whether its a more widespread issue.

I just tested this and is working properly for me when I added numbers to the password.

Quote
sdavi

I just tested this and is working properly for me when I added numbers to the password.

Must just be me.
Thanks for checking.

---

Based in Darlington, North East

I don't know if its me, but I'm really struggling with basic endstop setup.
I'm using lpc.board=biquskr_1.4.
I have an endstop fitted between ground and 1.29. That board setup calls that pin "xstop"

I've tried the following in the config

M574 X1 S1 P"xstop"

and

M574 X1 S1 P"1.29"

Neither of these show as triggering in M119 or DWC.

Anyone got any ideas? I've already tested the switch using a multimeter so I know that's not an issue.

---

Based in Darlington, North East