Forum Rule: Always post complete source code & details to reproduce any issue!
Page 5 of 5 FirstFirst ... 3 4 5
Results 101 to 106 of 106

Thread: Using GDB with Teensy without hardware debugger, first Beta

  1. #101
    Senior Member
    Join Date
    Sep 2013
    Boston, MA
    Quote Originally Posted by TeeVil View Post
    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
    I'm the module author. Thanks for debugging this setup. If you send me the specific steps you used to get this working I can add it to the README.

  2. #102
    Junior Member
    Join Date
    Jul 2021
    My problem wasn't caused by TeensyDebug - I just had to move the declaration of GDB_DUAL_SERIAL to the correct place (i.e. the makefile).
    So I don't think you need to add anything to the README, thanks.

    BUT...I'm having trouble using TeensyDebug along with the Audio library. Has anybody ever done this successfully? Please see post #6 at:

  3. #103
    Quote Originally Posted by ftrias View Post
    The installer is looking for a directory "hardware/teensy" inside your Arduino directory. If it's not there, it complains.

    Since you have a non-standard install, it's probably best to just set up manually. Look at the file and follow the steps in "Installing overview".
    I ran into the same problem with the install.
    The issue was that the ardunio/teensy stuff was installed in a folder like arduino-1.8.15.
    Also, the teensy_debug.exe file had to be hand installed in the "libraries" folder in a custom made folder "TeensyDebug".
    Then the .exe file has to be run and the special path given to it when it won't find the folder.
    By the way the GDB menu items are in the drop down "tools" list near the bottom.

  4. #104
    Junior Member
    Join Date
    Feb 2021
    Hello ftrias,

    having made a similar debugger in the past, I took a look at your code on github and I have few remarks to improve it:

    - too few instructions are decoded in the software single step routine (setBreakPointNext()), 32 bits thumbs instructions are ignored for example.
    You could take a look at the thumb_get_next_pcs_raw() function of GDB for a complete (I guess) decoding to manage software single stepping.
    Note that by recompiling the GDB client with a minor patch, you can let it doing this work (as done for linux ARM target).
    - PacketSize returned in the qSupported response should be in Hex format.
    - The ISR context stack size (ISR_STACK_SIZE) is not constant, it depends on Bit[4] of EXC_RETURN (see DAI0298A_cortex_m4f_lazy_stacking_and_context_swit ching.pdf). EDIT: and stacked PSR[9] if SP not 8-byte aligned.
    - You need to check whether it's PSP or MSP that is in use when the program is 'halted' to save the correct value as the top stack. But may be unnecessary if the same stack is used for user and handlers.

    And I don't understand why you use a polling-timer to retrieve the GDB data. Using the UART interrupt works perfectly fine, with zero overhead when there is no communication (Note: I don't use Teensy/Arduino).
    Last edited by Jory; 01-10-2022 at 01:33 PM.

  5. #105
    Junior Member
    Join Date
    Feb 2021
    It is also worth noting that the communication speed between the client and the stub is very dependent on the RX latency of the USB-UART IC driver.

    Using an FTDI cable on Windows (did not try on Linux) with the default settings is awful.
    Changing the RX buffer latency from 16ms to 1ms will improve the experience
    Click image for larger version. 

Name:	usb lat.png 
Views:	22 
Size:	32.7 KB 
ID:	27188

    but a better result can be achieved by using an ST-Link, as found on the Nucleo boards, with j-link driver.

    With interrupt based UART communication, running at 921600 bauds, it is equivalent to a hardware debug probe.

    And I am pretty sure that we can still improve the performance if we optimize the communication routines in the GDB client.
    Last edited by Jory; 01-12-2022 at 03:14 PM.

  6. #106
    Senior Member
    Join Date
    Apr 2021
    Cambridgeshire, UK
    I've been playing with this library again, as a result of seeing this thread. At first I couldn't reproduce the issue, then I could, and now I can't again! However, I may have made some progress, my observations being:
    • there can be possibly intermittent issues with using the GDB library with I2S audio, specifically the SGTL5000, but
    • it may not be specific to audio - I could provoke it by referencing the Wire library
    • the symptoms are that the Teensy never makes it to setup(), and its USB capabilities don't start up (no COM ports etc)

    I've possibly narrowed it down to the first call to resetPFD() in cores/teensy4/startup.c, and more specifically to the setting of CCM_ANALOG_PFD_480. Removing the call altogether, or just the change to that one register, seemed to fix the issue without causing any other side-effects. Note there's a second call to resetPFD(), commented "//TODO: is this really needed?" - obviously if you remove the first call, it probably is needed, and should set both analogue PFD registers' values.

    If the issue is occurring, then it looks like the CPU never returns from the first resetPFD() call, which suggests that something deeply nasty has happened to destabilise the core as a result of setting one or more of the PFD values. As I write I don't know which ones, because it's all started working again.

    I'll revert to the stock startup.c, use GDB routinely, and try to generate further data if/when the issue occurs again.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts