Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 38 of 38

Thread: Teensy 4.0 - how to connect a jtag debugger ?

  1. #26
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    1,094
    And now we have this, which is fine for many uses:

    https://forum.pjrc.com/threads/61373...ger-first-Beta

  2. #27
    Yes, very interesting, I'll have to try it. Only I don't like Teensyduino, so I'll have to see if I can get it working with the MCUXpresso IDE.

  3. #28
    Junior Member
    Join Date
    Aug 2020
    Posts
    1
    Is it possible to reprogram the MKL02 on the Teensy 4.0? I would be interesting in making or porting some firmware for it that talks JTAG to the IMX, similar to what Segger does with their JLINK-OpenSDA firmwares for KLxx chips.

  4. #29
    Hiya,

    [edit: just noticed this was already suggested.. ;-) ]

    Call me a spoiled brat but I insist on having a proper debugger for embedded work ;-) Life is too short for printf debugging complex issues on a chip with a gazillion peripherals.
    So... I have a gig that I may want to use Teensy 4's for, and I'll probably just buy the NXP eval board - which most usefully breaks out JTAG - plus has the other stuff like ethernet/USB/etc (and CAN and.. all sorts of optional junk in the trunk). For $99 it's _well_ worth it to me as a development/debug platform. The resulting code I'll deploy on Teensy 4's of course.

    NXP board:
    https://www.nxp.com/design/developme...MIMXRT1060-EVK

    Schematic: (may need an NXP account, just sign up)
    https://cache.nxp.com/secured/assets...2&fileExt=.zip

  5. #30
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    10,005
    Quote Originally Posted by DrTune View Post
    Hiya,
    Call me a spoiled brat but I insist on having a proper debugger for embedded work ;-)
    Ok Spoiled Brat

    For me, it would be nice but not a have to. Besides if you need some source level debug support you can always try playing with the stuff from VisualMicro, especially now that @ftrias has setup a nice GDBStub setup, and Visual Micro put in some support for it, you can do some of the debugging using that.

  6. #31
    Quote Originally Posted by PaulStoffregen View Post
    Here's a few random bits of info which might help...
    Attempting this plan won't be easy, but hopefully these tips can save you from the most frustrating issues which aren't well documented anywhere... other than this forum message!
    Thanks Paul for the details. It's however unfortunate that teensy 4 didn't make easy hardware debugging a priority when it was clear that there was interest in 3.x chips (but it was hard and out of reach for most).
    From what I read so far, it seems that 4.x is no better and you can't just connect a debugger?
    Unfortunately, most users will not have hardware debugging experience, so it would be good to have something that works easily with a howto (that someone else can write).

    In the meantime: how about something simpler. ESP32 is overall a lesser chip compared to teensy 3.6, but I mostly switched to it because I didn't have the issue of the serial port disappearing on teensy (on ESP32, it's an ftdi, so no problems), but the biggest thing that helped me on ESP32 was that it traps CPU crashes and displays a helpful message, like division by zero or loading from a forbidden address (buffer overflow)
    And the best part is that it displays the content of the stack, and a stack decoder gives you a full traceback in your code, so you know where things crashed.

    This has saved me so much time. Honestly, this is a main reason why I've used ESP32 chips over teensy in the last years.

    Teensy 4 is definitely a better chip, but it really needs better debugging. If easy hardware debugging is still mostly off limits for most, can you add what ESP32 has been doing for years now, and helps out in 95% of the cases?

    Thanks, Marc

  7. #32
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,607
    As far I know (I may be wrong) JTAG is disabled by default anyway, on I.MX.RT. , instead SWD is used. But this would work too.
    Edit: No, the other way round. SWD is disabled on Teensy.

    I think it's a problem to enable HW-Debugging and keep the bootloader internals secret?
    Then, I think, faults for division by zero are disabled, too (but there is a bit to enable them)
    A Stack trace is not possible without debugger. The ARM-ABI does not define where on the stack is the return address.
    GCC -unwind-tables would help, perhaps, but I was unsuccessful to get it work (Linker errors). Likewise -mpoke-function-names. So, a trace is currently out of reach, too (I you find a way to use these both switches, it would be helpful)
    But I found a good way to print hardfaults. Maybe I publish some code or a library for this, but the general interest seemed pretty low so far. It isn'nt that useful without a stacktrace, too.

    Yes the ESP is - regarding to things like these - fun.

    And beginners see a errormessage, at least - they know "oops, something was wrong" - not a silent crash like with Teensies where nobody knows what happened, and without the slightest hint what may have happened.

    Not beginner friendly.

    I hope there is *something* to solve that on Pauls TODO (and not with a low priority). I was begging many many years for at least a dedicated Error-LED

    When the next Teensy with 2 cores comes, we NEED better debugging.
    Last edited by Frank B; 01-03-2021 at 12:15 PM.

  8. #33
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,607

  9. #34
    Just my 2 cents worth: I also faced problem that I needed a decent and FAST debugger for complex programs written for embedded systems (not only Teensy but STM32 too). Although I got debugger with STM32 I find it too slow to work with. So I ended up with hybrid approach. I try to isolate hardware-independent parts of my software and make them portable so I can code on Windows machine and compile and debug Windows target. To be able to write UIs and audio I use in-house developed software emulation of LCD (redirect to Windows GDI) and software emulation of audio-DMA I2s hardware (using ASIO drivers to audio card).
    That way I am able to write and debug complex software in the comfort of Visual Studio IDE. And I only do final integration using PlatformIO IDE (instead of Arduino), STM32IDE or Embitz.

  10. #35
    Junior Member
    Join Date
    Feb 2021
    Posts
    8
    Hello,

    needing an i.MX RT board with Ethernet in a small form factor, the teensy 4.1 got my attention.
    However, I am not interested in the Arduino eco-system and I need a full access to the JTAG debug port (as SWD is permanently disabled by fuses).

    So, I plan to re-program the KL02 chip to properly drive the PSWITCH, POR_B, JTAG_MOD and BOOT_MODE0 signals at boot and let the others in high-Z state to connect an external JTAG probe.

    But, before to buy the board, I still have a couple of questions:

    Does anybody know whether the KL02 is protected against a full erase or not?
    What is the purpose of the B0_13 pin at boot?

    Thank you!

  11. #36
    Senior Member manicksan's Avatar
    Join Date
    Jun 2020
    Location
    Sweden
    Posts
    486
    Maybe you missed this thread
    https://forum.pjrc.com/threads/66180...ug-Mod-Project
    it would be the same approach for teensy 4.0

  12. #37
    Junior Member
    Join Date
    Feb 2021
    Posts
    8
    Indeed, I missed this recent thread, thanks.

    However, de-soldering the KL02 only makes sense if it can not be re-programmed. Even so, I would prefer to cut the PCB traces.

  13. #38
    Junior Member
    Join Date
    Nov 2019
    Posts
    5
    Hello all,

    Debugging is the most fundamental aspect of microcontroller programming. If you can't single step source code, add breakpoints, view memory (RAM, EEPROM, and flash) and see internal MCU registers, you are not working smart. Serial.printf is not effective debugging, adding a live watch to a variable is debugging which is available by using a Segger J-Link SWD debugger. The Arduino IDE is probably the most difficult to use IDE, use Eclipse and you will see the difference.

Posting Permissions

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