You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Are you using a Single Board Computer (RaspberryPi) with your Duet?
Yes I use a SBC.
No I do not use a SBC.
Please upload the results of sending M122 in the gcode console.
M122 Report
Please upload the content of your config.g file.
; LED StripsM950E0 C"io8.out" T1; configure LED strip #0M950E1 C"io7.out" T2; configure LED strip #1
Please upload the content of any other releveant macro files.
A range of LED values was tested:
M150E1R0U255B0W0P40S6F0M150E1R0U0B0W0P40S6F0M150E1R0U0B255W255P40S6F0M150E0R0U0B0P40S6F0M150E0R0U0B255P40S6F0M150E0R0U0B255P255S6F0M150E0R0U0B0P255S6F0M150E0R0U255B0P255S6F0M150E0R255U0B0P255S6F0
Details specific to your printer.
Bench test only
Links to additional info.
No response
What happened?
Following the forum thread, I tested RGB and RGBW LEDs on 6HC io ports in RRF 3.5.1, and see the same as the user, ie first LED is stuck green. I went back and tested on 3.5.0-rc.1 (works correctly), rc.2 (works correctly), and rc.3 (first LED stuck green) too. It seems there was a regression in function between rc.2 and rc.3.
I also tested in 3.5.1 on Duet 3 Mini 5+, and LEDs on io port work correctly, so this seems to be specific to 6HC, and possibly 6XD (I don't have one to test).
The text was updated successfully, but these errors were encountered:
Issue was caused by the SAME70 cache behaviour and instruction reordering by the compiler. This sometimes led to the first pulse being too long when it was supposed to be a 0 (causing the reported symptom of too much green on the first LED), and sometimes led to the second pulse being delayed and shortened when it was supposed to be a 1 (causing too little green). Added ISB instructions to prevent the re-ordering, an alignment attribute to force the start of the function to be aligned on a cache line boundary, and some NOPs to shift the critical loop bodies to the middle of cache line boundaries.
Duet Forum Discussion Thread
https://forum.duet3d.com/topic/35653/rgb-rgbw-led-malfunction-3-5-1
Which Duet products are you using?
Firmware Version
RRF 3.5.1
Duet Web Control Version
DWC 3.5.1
Are you using a Single Board Computer (RaspberryPi) with your Duet?
Please upload the results of sending M122 in the gcode console.
Please upload the content of your config.g file.
Please upload the content of any other releveant macro files.
Details specific to your printer.
Bench test only
Links to additional info.
No response
What happened?
Following the forum thread, I tested RGB and RGBW LEDs on 6HC io ports in RRF 3.5.1, and see the same as the user, ie first LED is stuck green. I went back and tested on 3.5.0-rc.1 (works correctly), rc.2 (works correctly), and rc.3 (first LED stuck green) too. It seems there was a regression in function between rc.2 and rc.3.
I also tested in 3.5.1 on Duet 3 Mini 5+, and LEDs on io port work correctly, so this seems to be specific to 6HC, and possibly 6XD (I don't have one to test).
The text was updated successfully, but these errors were encountered: