@dc42 Found the solution, I didn't realize this earlier but the Toolboard firmware I was using had actually been modified by a coworker. We bought a new toolboard and tried to connect CAN (thinking maybe an IC had been fried) and it worked, so we copied that firmware onto the toolboard I had been using and sure enough, works fine. So it was a software issue. Thanks for your help!

@dc42 Duet3 Mainboard 6HC v1.02 with firmware 3.4.5 (date 2023-06-06)
Toolboard v1.03 with firmware 3.4.4

@dc42 I wrote Bootloader 2.3 to the toolboard and had it verify (I think the problem I had before was I forgot to write the fuses to the board). I put a RRF3 build of the code, with build configurations all matching SAMC21 or TOOL1LC. (CANlib - SAMC21RTOS, CoreN2G - SAMC21-CAN, Duet3Expansion - TOOL1LC, FreeRTOS - SAMC21, RRFLibraries - SAMC21) I put the bin file onto the mainboard in the /firmware folder. When I flash the bootloader onto the toolboard over SWD following the steps you gave above (no connection to mainboard at this point), microchip studio verifies everything is OK. The status light on the toolboard then flashes twice, indicating invalid firmware. a second later it flashed four times, indicating the board attempted to reach out to the mainboard and failed.

Next, I powered off the board, plugged in the CAN to the mainboard, and powered on both boards. The toolboard waits for a second and then pulls the firmware from the mainboard, and the status and act lights clearly indicate that the firmware is being written. Then, the status lights blinks repeatedly and fast, indicating no CAN connection. I cycled power and still no CAN connection. This does not make sense to me, as the toolboard flashed its own firmware over CAN, did it not?

thanks for your help

@dc42 I was finally able to flash firmware to the toolboard over SWD, but now I am unable to connect to the toolboard via CAN. This could probably be a different question but I am posting here, let me know if I should make a separate thread.

I reflashed the bootloader: not the most recent, as the toolboard rejected every 2.X version (status light flashed twice and turned off) I had to go with 1.3. Once I had that, I flashed both the firmware_TOOL1LC and TOOL1LC-Debug. These are from a RRF2 build, I cannot use RRF3 because of an existing project I am working with. Both flashed, but I could not do anything with CAN once I flashed. The debug version caused the status light to flash rapidly, and I could not connect via CAN. The regular firmware caused the status light to turn off and not turn back on. In both firmware's, the factory reset (hold both buttons while turning on) did nothing. CAN address is 121.

I am using a Mainboard 6HC v1.02. I verified that both terminating resistors are in the CAN circuit, and I hooked up the mainboard CAN to an oscilloscope and saw CAN messages being sent, as expected. But, I am unable to communicate with the toolboard.

Thoughts? Thanks.

@dc42 Connecting the reset pin didn't do anything. Some more details:

The Ice pinout I am using is the following:

This goes to a 6-pin connector, which I am connecting to the 5pin SWD pads on the toolboard (toolboard v1.3), which has the following pin configuration (pin 1 is SWDCLK, Pin 2 is target voltage):

The reset pin on the toolboard does not have a place on the cable that came with the ICE according to this, so I manually connected it to the Reset pin on the ICE. This did nothing.

In the device programmer (microchip studio), I have the following config: Atmel-ICE, ATSAMC21G18A, SWD. This still reads the Target voltage correctly but errors with No Device Detected, Error 4109.

I am attempting to flash new firmware to the Duet 3 Toolboard 1LC, verison 1.3. I am using a Duet 3 Mainboard 6HC v1.02 as well. Atmel ICE is running firmware version 1.4.

I was able to connect via CAN to the board, and began flashing Duet3Firmware_TOOL1LC.bin, the status light on the toolboard began flashing, but kept flashing for several minutes. Thinking it was caught, I unplugged everything and did a factory reset on the toolboard. Now, I cannot communicate via CAN, and the status light is blinking fast and not stopping. Factory resetting the board no longer changes the status LED (and I don't think it has any effect, it is always blinking fast regardless of buttons being pressed). Power supply is a solid 24V, I also tried with 12V, and no change. I tried using CANID 121, 20, and 10, and nothing. Attempting to flash bootloader also fails.

Instead I tried connecting via SWD with Atmel-ICE. Note, I have not flashed the debug version of the code (because I couldn't over CAN). Of course, I could not connect to the board, although I can read the target voltage, and it is correct. I am ignoring the reset pin (leaving unconnected). When I connect the board to the ICE, the status led stays a solid red until I unplug the ice, and it blinks very fast again (regardless if it is connected to the mainboard). I am fairly certain that pinout is correct.

Questions are these: Is there another way to flash the debug firmware to the Toolboard? Is there another way to connect with the ICE? Why can I no longer connect via CAN? Why is factory reset not appearing to do anything? Thanks in advance!

I am using Duet2 Ethernet board (v1.05) with Duex5 (v0.11) expansion, running RRF2.05.1 (I cannot use RRF3, as this is an existing project). I am trying to read the endstop pins on the Duex5, as the endstop pins on the Duet2 Ethernet are all populated. I am using custom code, with a similar idea as M585, where I move until I hit an endstop. I am using SetBit(moveBuffer.endStopsToCheck, [axis]) to specify which endstop I am using to stop movement when actuated. From a previous similar post, the END_STOP_PINS in Pins_Duet.h define the endstop pins for 9 axis.

I want to use two of the endstop pins on the Duex5. I can only get the endStopsToCheck to work correctly for axis 0 through 4, which are on the Duet 2 Ethernet board, and axis 9, which is E6 on the Duex5. axis 5 through 8 do nothing. I cannot seem to read endtops E2 through E5 on the Duex5.

I tried to trace the pin definitions through the RRF code but they have weird conventions and don't match the schematics, so I have no idea if the pins are defined correctly. for Example, axis 9 is mapped to pin X9 in END_STOP_PINS, and X9 is defined as pin 101 in varient.h, but doing a IoPort::ReadPin(101) is definitely not reading the endstop pin.

My question in short: How do I read endstop pins E2 through E5 on the Duex5 board? is endStopsToCheck working correctly for those pins?

Thanks for any tips.

I am writing code for an existing project in 2.05.1 (so no RRF3 sadly). I want to run two functions at the same time. In the big picture, I want to move my toolhead in a specific pattern while I have a sensor detecting specific points in the pattern, for calibration of some sort. My intent was to go about this calling one move function and one sense function and having both of them run at the same time, like cpp has multithreading (or concurrent threading). However, I cannot get the standard cpp threading syntax to work in the reprapfirmware project. I am using Eclipse 2018-19 for 2.05.1.

Looking through the existing code, it seems this line is used for this function:
TaskCriticalSectionLocker lock;
Which to my basic understanding would create a concurrent thread for the following code (there is no documentation on this, so that is a pure guess). However, I could not get this line to work as I intended.

So, my question is two parts: How do I use the above line correctly? and sub question; is my interpretation of the functionality correct? Secondly, how do I run two functions simultaneously? such as one move, and one sense function. Thanks for any help.

@rl_at_berk ISSUE SOLVED: Turns out the pin definitions that are in the code do not match the actual endstop pins on the 1.05. I ended up looping through EVERY pin on the board, and found that E1 and E0 on the board are pins 42 and 74. Then, digital(read) and IoPort::ReadPin() both work fine.

@hareshPrajapati So I tried using this and am getting some weird results. From my above comment, my Mcode command (in Gcodes2.cpp) cannot use endStopPins, as it is not in scope. Instead, my Mcode calls a function in Platform.cpp, which simply returns a pin from endStopPins. my Mcode then uses IoPort::ReadPin(Call that function in Platform.cpp). The result of this I do not understand:

No matter what the endstop pins current state, the first call of this will return false for every pin (I ended up testing all 9 pins in endStopPins individually). Then, if the state of ANY pin changes, the function call causes a crash (crash of software and WebController, resets everything). Note I am testing every pin at once here. In addition, the first time I call this, every endStopPin always returns false regardless of the actual state of the machine, for all axes including X, Y, and Z. This leads me to believe that endStopPins is not actually the correct Pins? I am using the Duet2 Ethernet Board with the Wifi Breakout Board.

I tried looking into Pin definitions and I cannot find anything in the reprapfirmware code that has pin definitions that match the actual hardware. I also tried to trace the X and Y endstop code, but it is not readable (at least for me, who does not have that advanced of an understanding of this code). I also found that IoPort::ReadPin uses digitalRead(pin), and this is the same behavior if I just use that (as expected).

Thoughts? Is there something I can look at for the X and Y endstops, so that I can test to see how to read the endstop pins? Because those work for other code, just not mine. Is there another way I can implement reading the endstops? Thanks for your help

EDIT: Another thing I have been looking at is the actual pinout from the Duet board. I found a map of some pins in CoreNG/variants/duet/varient.cpp which gives some pinouts. The issue is I cannot find a physical schematic which matches these pinouts. I am using the Duet2 Ethernet Board version 1.05. I can only find schematics for 1.04, did the pinouts change from 1.04 to 1.05?