What's the best practice to test G-code during a debug session?

mpreishuber

Hi everyone

my name is Mario - obviously I'm new here - and I struggling with executing specific G- & M-commands on a Duet3 board while a debugger is active.

The firmware debugging itself works fine. I'm able to build and start a debug session directly within Eclipse.
However, it became tricky for me when I wanted to execute specific G-/M-commands during a debug session.

I tried to ...
(1) Send commands using the Duet Software Framework, but I'm not able to get a connection during a debug session.
(2) Send commands using Pronterface (https://www.pronterface.com), but it didn't work either.
(3) Load commands from SD cards. This approach works, but to me it is not really nice workflow. So, I really would like to avoid using a SD card

Here, my actual question is:
What's the best practice to test single & multiple G- & M-Commands during a debug session?

Thanks,
Mario

Hardware

Duet 3 Board (ATSAM70Q20)
Segger JLink Plus
Raspberry Pi Model 3 B+
Notebook (Windows/OSX)

Software

Duet 3 Firmware
- RepRapFirmware: v3.01-dev
- RRFLibraries: dev
- CoreNG: dev
- FreeRTOS: master
- DuetWiFiSocketServer: master
Segger JLink Remote Server v6.72c
Raspberry Pi with DuetPi (downloaded on 2020-05-13)
Eclipse 2020-03
GNU Tools for Arm Embedded Processor v9.2.1 (0-2019-q4-major)

Setup

Segger connects via SWD ping to the Duet3 board
Raspberry Pi connects via USB to the Segger
- The Raspberry Pi works as remote debug server
Eclipse connects via the network to the remote debug server on the Raspberry Pi

dc42

You could try sending the command via the PanelDue serial port. Caution: it uses 3.3V signal levels; 5V will damage the MCU.

chrishamm

To trace codes being executed from DSF, stop the service and start it with debugging output:

sudo systemctl stop duetcontrolserver
sudo /opt/dsf/bin/DuetControlServer -l debug -r

Whenever you see e.g. HTTP: Sent XXXX in the log, you know that the code has been processed in DCS and that it has been sent to RRF for further execution.

mpreishuber

@dc42 Thanks for the extremely fast response. Unfortunately, I don't have a PanelDue.
@chrishamm Starting the DuetControlServer in debug mode might help understanding what's going on.

What I don't understand is, why the DuetControlServer is not able to connect with the Duet3 board via ribbon cable while a debug session is active. Is this expected behavior or am I missing something here?

chrishamm

@mpreishuber DCS works best with low latencies and if it cannot establish a connection to the Duet 3 within a reasonable time, it will terminate again. Of course, if you pause the code execution on the MCU, the board won't be able to answer to DCS.

Sejl

@dc42 said in What's the best practice to test G-code during a debug session?:

You could try sending the command via the PanelDue serial port. Caution: it uses 3.3V signal levels; 5V will damage the MCU.

Duet 3 Hardware Overview web page says: "The inputs will tolerate up to 30V. The outputs are 3.3V signals levels with 470R series resistors."

I would like to know how can you damage MCU with 5V if input is tolerating up to 30V?

Best regards

dc42

@Sejl said in What's the best practice to test G-code during a debug session?:

@dc42 said in What's the best practice to test G-code during a debug session?:

You could try sending the command via the PanelDue serial port. Caution: it uses 3.3V signal levels; 5V will damage the MCU.

Duet 3 Hardware Overview web page says: "The inputs will tolerate up to 30V. The outputs are 3.3V signals levels with 470R series resistors."

I would like to know how can you damage MCU with 5V if input is tolerating up to 30V?

Best regards

I stand corrected. On Duet 3, PanelDue connects to the IO_0 connector, which is indeed tolerant of 30V on the input pin. On Duet 2 and Duet 085 it tolerates 3.3V maximum.

Sejl

@dc42 said in What's the best practice to test G-code during a debug session?:

@Sejl said in What's the best practice to test G-code during a debug session?:

@dc42 said in What's the best practice to test G-code during a debug session?:

You could try sending the command via the PanelDue serial port. Caution: it uses 3.3V signal levels; 5V will damage the MCU.

Duet 3 Hardware Overview web page says: "The inputs will tolerate up to 30V. The outputs are 3.3V signals levels with 470R series resistors."

I would like to know how can you damage MCU with 5V if input is tolerating up to 30V?

Best regards

I stand corrected. On Duet 3, PanelDue connects to the IO_0 connector, which is indeed tolerant of 30V on the input pin. On Duet 2 and Duet 085 it tolerates 3.3V maximum.

Thank you!