Using GDB with Teensy without hardware debugger, first Beta

I spent a while on this but didn't get it working. I was using the latest Teensyduino and built the project in the Arduino IDE.

Thanks for trying to help but I've given up for the moment. If I come at it again, I might figure it out.
 
Teensy 4.1 Gdb debugging with NativeEthernet programming Fail

When trying to use TeensyDebug with NativeUDP after compiling and programming, the mid board LED flashes Yellow at about 4 Hz and the board becomes unreachable via USB until a valid program like Blink is compiled and loaded.
I have successfully debugged other Teensy 4.1 programs and this issue appears only (so far) when trying to open a UDP port when compiling with the DEBUG Flag on.

I've tried with and without #pragma and a bunch of other dial spinning and flailing attempts but to no avail.
Anyone have any idea how to solve this issue?
Also what does the rapidly flashing LED after a programming attempt mean? Boot loader Fail?

Platform Linux Debian
Arduino IDE 1.8.13
Board Teensy 4.1 with Ethernet
TeensyDebug version 0.0.1
NativeEthernet version 1.0.3
FNET version 0.1.3

Code:

#pragma GCC optimize ("O0")

#include "TeensyDebug.h"
#include <NativeEthernet.h>
#include <NativeEthernetUdp.h>

////////////////////////////////////////////////////////////////////////////
// UN-COMMENT LINE BELOW TO REPRODUCE ISSUE WHEN COMPILING WITH DEBUG FLAG ON
//EthernetUDP Udp;

void setup() {
delay(1);
debug.begin();
}

volatile int mark = 0;

void loop() {
Serial.print("mark=");Serial.println(mark++);
delay(1000);
}

 

Attachments

  • teensy_nativeudp_example.c
    441 bytes · Views: 1,415
kburden000 said:
When trying to use TeensyDebug with NativeUDP after compiling and programming, the mid board LED flashes Yellow at about 4 Hz and the board becomes unreachable via USB until a valid program like Blink is compiled and loaded.
I have successfully debugged other Teensy 4.1 programs and this issue appears only (so far) when trying to open a UDP port when compiling with the DEBUG Flag on.

I've tried with and without #pragma and a bunch of other dial spinning and flailing attempts but to no avail.
Anyone have any idea how to solve this issue?
Also what does the rapidly flashing LED after a programming attempt mean? Boot loader Fail?

Platform Linux Debian
Arduino IDE 1.8.13
Board Teensy 4.1 with Ethernet
TeensyDebug version 0.0.1
NativeEthernet version 1.0.3
FNET version 0.1.3

Code:

#pragma GCC optimize ("O0")

#include "TeensyDebug.h"
#include <NativeEthernet.h>
#include <NativeEthernetUdp.h>

////////////////////////////////////////////////////////////////////////////
// UN-COMMENT LINE BELOW TO REPRODUCE ISSUE WHEN COMPILING WITH DEBUG FLAG ON
//EthernetUDP Udp;

void setup() {
delay(1);
debug.begin();
}

volatile int mark = 0;

void loop() {
Serial.print("mark=");Serial.println(mark++);
delay(1000);
}

Click to expand...
This sounds great. I used a software-based debugger for ATMega. A limitation was that interrupts needed to be running all the time in order for the debugger to work. Is it possible to set a breakpoint inside an ISR if the ISR disables interrupts for its duration?
 
Hey Luni,
Any idea on how to fix/workaround the issue with the Ethernet Interface on Teensy 4.1 detailed above?
I need a debugger to fix the debugger! Reducto Il Absurdum
 
The MIMXRT1060-EVK looks like a dev tools for making Cortex M7 systems not something used on existing Teensys. Yes?
Perhaps Paul used one when he made the Teensy.

My Use Case is debugging an extant Teensy 4.1+Ethernet, which to the best of my knowledge doesn't bring out any hardware debug pins, so the GdbStub method tfrias et. al. used is appropriate.
But it doesn't work on a Teensy if Ethernet is used. I just wanted that bug fixed.
 
Then I guess you need to fix up the debugger code, take a fork and mend it.

Use a logic analyzer, Oscilloscope or console out to find out why it is not working.
 
AndyCap said:
Then I guess you need to fix up the debugger code, take a fork and mend it.

Use a logic analyzer, Oscilloscope or console out to find out why it is not working.
Click to expand...

Indeed, Thread was marked BETA - and a good amount of effort shows GDB generally usable - but has some limitations - for whatever reason the author hasn't updated in 10 months. Whether lack of interest when time was at hand or complexity of doing more given the process and parts that worked with this fixed external tool.

Ethernet is speedy and perhaps naughty to the ways of the debugger. Perhaps some things like building with Ethernet disabled or made active later would allow it to start and then maybe even trap where it dies?
 
To clarify, the MIMXRT1060-EVK can be used to temporarily replace a teensy 4. I haven't tried this one, but with previous eval boards, it wasn't hard to load and run teensy code. Unlike the T4, it then allows easy attachment of a hardware debugger. It's not hard to save $120 in time.

That being said, with enough print statements and pin toggling, one can find a bug without a debugger.
 
defragster said:
Indeed, Thread was marked BETA - and a good amount of effort shows GDB generally usable - but has some limitations - for whatever reason the author hasn't updated in 10 months. Whether lack of interest when time was at hand or complexity of doing more given the process and parts that worked with this fixed external tool.

Ethernet is speedy and perhaps naughty to the ways of the debugger. Perhaps some things like building with Ethernet disabled or made active later would allow it to start and then maybe even trap where it dies?
Click to expand...

Sorry but I don't have the equipment or skill to suss this issue out. I was hoping it was something the author could fix easily as he appears to be far more adept.
On board Ethernet is popular interface for Teensy 4.1 and in case he hadn't tested for it I just wanted to inform him of the issue.
 
Thanks for the heads up. I checked GitHub for latest and sadly it appears Ethernet still locks up.
I was kind of snarky when I posted originally as I had just finished a Qt based FOSS GUI front end using tfrias GDB stub implementation for the 4.1.
Which I planned on using on a project with the teensy with Ethernet and was fairly crestfallen when it didn't work.
 
> I checked GitHub for latest

But you didn't create an issue - which is the best way to help others who may have the same problem.
 
Any instructions about how to remove once installed (on Win10 64b) ?
At least how to reverse changes done in (it is enough ?)
C:\Program Files (x86)\Arduino\hardware\teensy\avr
boards.local.txt
platform.txt
boards.local.txt
platform.txt

Thanks
 
I'm new to Teensy so I installed Arduino 1.8.15 and Teensyduino 1.54 on my Windows 10 machine.
I then installed TeensyDebug as per the instructions at https://github.com/ftrias/TeensyDebug . It seemed to install OK.

If I compile & run an app with Tools->GDB set to "Off" then it runs 100%.

But if I choose any other option for Tools->GDB then the app never seems to start. Symptoms:
1. None of my code executes, not even the very first line of setup()
2. Tools->Port is grayed out
3. gdb does not launch in a terminal window (I understand that is supposed to happen?)

Any suggestions to start debugging this? (I am new to the whole environment, I might be missing something obvious)

Thanks
 
Check your Teensy Rev for compatibility with GDBStub

To the best of my knowledge the GDBStub code that this scheme relies on ONLY works on Teensy 4.1,4.0, 3.6
 
Sorry yes forgot to mention: I'm using a Teensy 4.1

It looks like TeensyDuino 1.54 is fairly new - is TeensyDebug working for anybody else with these versions of TeensyDuino and Arduino?
 
Sorry been awhile since I played with it. If I remember correctly, sometimes you have to open up the GDB window and tell the program to go...

When I last played with it, I was using the VisualMicro (Visual Studio) setup for it. (https://www.visualmicro.com/)
 
Works fine for me with 1.8.15. I'd use this test program:


Code: 
#include "TeensyDebug.h"
#pragma GCC optimize ("O0")

// ~/arduino/arduino-*/hardware/tools/arm/bin/arm-none-eabi-gdb /tmp/arduino_build_xxx/jz-gdbstub-test.ino.elf -ex "target remote /dev/ttyACM1"

// gdb-multiarch /tmp/arduino_build_*/jz-gdbstub-test.ino.elf -ex "target remote /dev/ttyACM1"

// set USB Type to "Dual Serial"


#define ASSERT(expr) if (!(expr)) {asm volatile("svc #0x11");}

int mark1 = 3;


void test_function() {
  mark1 += 1;
  mark1 += three();;

}

int three() {

  int i = 3;

  //ASSERT(mark1 < 50);

  return i;
}

void setup() {

  Serial.begin(19200);
  while (!Serial && millis() < 2000) {}   // wait

  // gdbstub debugger on second serial port
  SerialUSB1.begin(19200);
  do {
    Serial.println("start debugger now...");
    delay(1000);
  } while (!SerialUSB1);   // wait
  debug.begin(SerialUSB1);
  Serial.println("debugger connected, issue continue command\n");
  halt();  
  debug.printf("teensy program running\n");  
}


void loop() {
  delay(500);
  Serial.println(mark1);
  debug.printf("%d\n", mark1);  delay(1);   // delay is needed with breakpoints
  
  test_function();
}
 
jonr - thanks for the reply, but I get the same result with your program. Dead as a doornail as soon as I press the pushbutton, and no serial port available to connect to.

What version of Teensyduino are you using?

I reverted back to Arduino 1.8.13 and Teensyduino 1.53 - and then it works!
So if it works for you with Arduino 1.8.15 then the problem is probably with Teensyduino 1.54? I'll just post a message to this effect in the Teensyduino 1.54 forum thread as well.

Thanks
 
I tested with a Teensy 4.0, 1.8.15 and 1.54. I just use the GDB-stub code without its install process.

Specifically, include "gdbstub.cpp, TeensyDebug.cpp and TeensyDebug.h" in the directory with the test program.
 
I think my problem was caused by the following:
I'm using Visual Studio Code with a makefile project (created with VisualTeensy)
To get the debugging going I declared GDB_DUAL_SERIAL at the top of my main file. After moving it to the makefile things are looking better.
So thanks for the help, it looks like it was a case of PEBKAC
 
You must log in or register to reply here.
Back
Top