Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Debugger Problems - Teensy #53

Open
atestani opened this issue Nov 1, 2019 · 12 comments
Open

Debugger Problems - Teensy #53

atestani opened this issue Nov 1, 2019 · 12 comments
Assignees
@valeros
Labels
help wanted

Comments

@atestani
Copy link

atestani commented Nov 1, 2019

(Moved from "PlatformIO Home 3.0 Beta and powerful Project Inspection")

I upgraded to the latest Home (3.0.0-beta.3) and Core (4.1.0rc3) and build and upload work fine but debugging is broken.

I will say debugging wasn't perfect before as I could only run the debugger once and then when I tried to reset I would get a message that said "The preLaunchTask ‘undefined’ terminated....". Frankly, this is why I upgraded everything... hoping the debugger problem would get fixed. When the upgrade occurred the Teensy platform updated to 4.4.0 which wasn't my intention.

I am running a custom "Teensy 3.1" with my board json file in the boards folder of my project and the .ld file in my source folder. platform.ini and extra_script.py look like this:

platform.ini

[env:jlink_debug_and_upload]
platform = teensy
framework = arduino
board = teensy3x
board_build.f_cpu = 72000000L
extra_scripts = extra_script.py
debug_tool = custom
debug_server =
  C:\JLINK\JLinkGDBServerCL.exe
  -singlerun
  -ifls
  SWD
  -select
  USB
  -port
  2331
  -device
  MK20DX128xxx7

extra_script.py

from os import makedirs
from os.path import isdir, join
Import('env')

# Optional block, only for Teensy
env.AddPostAction(
    "$BUILD_DIR/firmware.hex",
    env.VerboseAction(" ".join([
        "sed", "-i.bak",
        "s/:10040000FFFFFFFFFFFFFFFFFFFFFFFFDEF9FFFF23/:10040000FFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFFFD/",
        "$BUILD_DIR/firmware.hex"
    ]), "Fixing $BUILD_DIR/firmware.hex secure flash flags"))


def _jlink_cmd_script(env, source):
    build_dir = env.subst("$BUILD_DIR")
    if not isdir(build_dir):
        makedirs(build_dir)
    script_path = join(build_dir, "upload.jlink")
    commands = ["h", "loadbin %s,0x0" % source, "r", "q"]
    with open(script_path, "w") as fp:
        fp.write("\n".join(commands))
    return script_path

env.Replace(
    __jlink_cmd_script=_jlink_cmd_script,
    UPLOADER="C:\JLINK\JLINK.exe",
    UPLOADERFLAGS=[
        "-device", "MK20DX128xxx7",
        "-speed", "4000",
        "-if", "swd",
        "-autoconnect", "1"
    ],
    UPLOADCMD='"$UPLOADER" $UPLOADERFLAGS -CommanderScript ${__jlink_cmd_script(__env__, SOURCE)}'
    )

So the problem is now the debugger won't work at all. If I start debugging everything proceeds as usual but then the code starts. While the output says:
PlatformIO: Resume the execution to `debug_init_break = tbreak main
it never happens because if I "pause" the debugger I see the the code is stuck in an error loop in mk20dx128.c which is part of the Teensy core. I have checked (file by file) what changed when the Teensy platform was updated but don't see anything that changed that can be causing this. I've been trying to solve this for the last 8 hours and I am out of ideas.

So.... I would greatly appreciate some help on this. Thanks

NEW: I continued to work on this and found if I click the Restart button in the Debug toobar the debugger would then stop as it should on setup() in main() and then work I needed to click "Debug Anyway" in the "The preLaunchTask ‘undefined’ terminated...." error dialog. (I finally checked the box to not show the error in the future!).

So now I am back to where I was but whenever I Restart the ddebugger the terminal shows this
snap1699

Also, whenever I stop the debugger I get this error message:
snap1700
@atestani
Copy link
Author

atestani commented Nov 1, 2019

More on this:

  1. If I make a change to the source and click Restart a rebuild doesn't happen and the old code is reloaded. I added " debug_load_mode = always (or modified)" to platform.ini with no change. If I click "Upload" on the now orange bottom toolbar, it rebuilds the code and when I click Restart, it rebuilds the code again but evidently doesn't change the hex file as the change is not implemented. It appears this is because of the error message above occurs and the elf file is not rewritten

  2. If I stop the debugger and rebuild code normally, it doesn't run seemingly still stopped at the setup() default breakpoint(?) I have to repower the target board to get it back working again. I think again this is because of the inability for the compiler to rewrite the elf file.

I found the section in the latest 4.1.0rc3 documentation about the [env:jlink_debug_and_upload] and extra_script.py which is exactly what I have implemented. However, the main difference is that I have a "custom Teensy" (for lack of a better term!). Not only is it on my own PCB but it is using a MK20DX128VHL7 (128K) vs a Teensy 3.1/3/2 which uses the 256K version, i.e. MK20DX256VHL7. To deal with this change, I have the following "board" defined (as teensy3X in my platform.ini file) which uses the following .ld file:

**teensy3x.json:**
"build": {
    "core": "teensy3", 
    "cpu": "cortex-m4", 
    "extra_flags": "-D__MK20DX256__ -DTEENSY31", 
    "f_cpu": "96000000L", 
    "ldscript": "mk20dx128V.ld", 
    "mcu": "mk20dx128"
  }, 
  "debug": {
    "jlink_device": "MK20DX128xxx7"
  },
  "frameworks": [
    "arduino" 
  ], 
  "name": "teensy3x", 
  "upload": {
    "maximum_ram_size": 16384, 
    "maximum_size": 131072,
  "protocols": [
    "jlink"
    ],
   "protocol": "jlink"
  }, 
  "url": "https://www.pjrc.com/store/teensy31.html", 
  "vendor": "Teensy"

mk20dx128V.ld:

/* Teensyduino Core Library
 * http://www.pjrc.com/teensy/
 * Copyright (c) 2017 PJRC.COM, LLC.
 *
 * Permission is hereby granted, free of charge, to any person obtaining
 * a copy of this software and associated documentation files (the
 * "Software"), to deal in the Software without restriction, including
 * without limitation the rights to use, copy, modify, merge, publish,
 * distribute, sublicense, and/or sell copies of the Software, and to
 * permit persons to whom the Software is furnished to do so, subject to
 * the following conditions:
 *
 * 1. The above copyright notice and this permission notice shall be
 * included in all copies or substantial portions of the Software.
 *
 * 2. If the Software is incorporated into a build system that allows 
 * selection among a list of target devices, then similar target
 * devices manufactured by PJRC.COM must be included in the list of
 * target devices and selectable in the same manner.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
 * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
 * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 * SOFTWARE.
 */

MEMORY
{
    FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 128K
    RAM  (rwx) : ORIGIN = 0x1FFFC000, LENGTH = 32K
}


SECTIONS
{
	.text : {
		. = 0;
		KEEP(*(.vectors))
		*(.startup*)
		/* TODO: does linker detect startup overflow onto flashconfig? */
		. = 0x400;
		KEEP(*(.flashconfig*))
		*(.text*)
		*(.rodata*)
		. = ALIGN(4);
		KEEP(*(.init))
		. = ALIGN(4);
		__preinit_array_start = .;
		KEEP (*(.preinit_array))
		__preinit_array_end = .;
		__init_array_start = .;
		KEEP (*(SORT(.init_array.*)))
		KEEP (*(.init_array))
		__init_array_end = .;
	} > FLASH = 0xFF

	.ARM.exidx : {
		__exidx_start = .;
		*(.ARM.exidx* .gnu.linkonce.armexidx.*)
		__exidx_end = .;
	} > FLASH
	_etext = .;

	.usbdescriptortable (NOLOAD) : {
		/* . = ORIGIN(RAM); */
		. = ALIGN(512);
		*(.usbdescriptortable*)
	} > RAM

	.dmabuffers (NOLOAD) : {
		. = ALIGN(4);
		*(.dmabuffers*)
	} > RAM

	.usbbuffers (NOLOAD) : {
		. = ALIGN(4);
		*(.usbbuffers*)
	} > RAM

	.data : AT (_etext) {
		. = ALIGN(4);
		_sdata = .; 
		*(.fastrun*)
		*(.data*)
		. = ALIGN(4);
		_edata = .; 
	} > RAM

	.noinit (NOLOAD) : {
		*(.noinit*)
	} > RAM

	.bss : {
		. = ALIGN(4);
		_sbss = .;
		__bss_start__ = .;
		*(.bss*)
		*(COMMON)
		. = ALIGN(4);
		_ebss = .;
		__bss_end = .;
		__bss_end__ = .;
	} > RAM

	_estack = ORIGIN(RAM) + LENGTH(RAM);
}

@ivankravets ivankravets changed the title Debugger Problems with Home (3.0.0-beta.3) and Core (4.1.0rc3) Debugger Problems with Core (4.1.0rc3) Nov 1, 2019
@ivankravets
Copy link
Member

Could you try the latest stable PlatformIO Core 4.0.3? Just for a test. Please run this in PlatformIO IDE Terminal

pip install "platformio==4.0.3"

Restart VSCode.

@atestani
Copy link
Author

atestani commented Nov 1, 2019 via email

@ivankravets
Copy link
Member

  1. Do you use the latest JLinkGDBServer software?
  2. Did you upgrade the firmware on your JLink adapter?

Could you provide AnyDesk session where we can try to debug this issue together? It will save time from both sides. My email [email protected].

Thanks!

@atestani
Copy link
Author

atestani commented Nov 2, 2019 via email

@ivankravets
Copy link
Member

Could you re-run pio upgrade --dev to RC6 or above. Does it work now?

@atestani
Copy link
Author

atestani commented Nov 2, 2019 via email

@atestani atestani closed this as completed Nov 3, 2019
@atestani
Copy link
Author

atestani commented Nov 3, 2019 •
edited
Loading

FYI... For completeness I tried with a very small program (an I2C scanner I use) and got the same results.

@atestani atestani reopened this Nov 3, 2019
@atestani
Copy link
Author

atestani commented Nov 3, 2019

Do you want to do an AnyDesk session? I've installed AnyDesk in preparation.

@ivankravets
Copy link
Member

Yes, please email [email protected] with your ID/Address.

@atestani
Copy link
Author

atestani commented Nov 3, 2019 via email

@atestani atestani changed the title Debugger Problems with Core (4.1.0rc3) Debugger Problems - Teensy Nov 6, 2019
@out0f0rder
Copy link

Sorry for necroposting, but were you able to resolve this?
I'm having the same issue: debugging is fine until I press the "Restart" button: it shows an error that firmware.elf is being used by another process. I've found the process that locks the .elf file is arm-none-eabi-gdb.exe.
Seems it is needed to instruct arm-none-eabi-gdb.exe to release the ELF file somehow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@valeros valeros

Labels
help wanted
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@valeros @ivankravets @atestani @out0f0rder