Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 5 of 5

Thread: Teensy 3.6 with $xx NXP LPC-Link3 debug probe & $0 MCUXpresso IDE with GCC, GDB etc.

  1. #1

    Teensy 3.6 with $xx NXP LPC-Link3 debug probe & $0 MCUXpresso IDE with GCC, GDB etc.

    I want to use GCC, GDB, C/C++ etc. with the Teensy 3.6. I think I have no need to use or learn about Arduino.

    The first step is to modify the Teensy 3.6 (the 3.5 is the same) to expose the SDC and SDD Serial Wire Debug signals, so a suitable debug probe can be attached. This has been documented [1] and [2] and discussed on this forum, at least in [3].

    The next step is to select a debug probe and IDE which works with standard GCC etc. NXP's MCUXpresso Eclipse-based IDE is $0 and has no code size limits [4]. (A $xxx Pro version has better trace support.) It seems that MCUXpresso works well with NXP's $xx LPC-Link3 debug probe [5]. (I don't have a Teensy or one of these debug probes yet, but they are on order.)

    The list of supported devices for the LPC-Link3 debug does not include the Teensy 3.6's MK66FX1M0VMD19 (K66) microcontroller or anything like it, so I asked on the NXP MCUXpresso IDE forum whether it could be used with this K66 device:

    https://community.nxp.com/thread/466997

    Within hours Erich Styger replied that yes, it does work. He wrote an article about it [6].

    I posted to replies to the NXP forum thread with further things I found out. This includes my suggestion for exposing the JTAG_TDO/TRACE_SWO signal on the Teensy 3.6, so it can be connected to the debug probe and used for tracing and the Serial Wire Viewer (SWV) transfer of data in real-time back to the IDE, via the debug probe. I think this can be done by soldering to a via. I suggest the the modification to the Teensy 3.6 to reset the little KL02Z chip could be done with conductive silver loaded epoxy and a strand of copper wire (such as one strand from ribbon cable) between its pins 15 and 3, since pin 3 connects to the DE pad on the underside. This would avoid exceedingly fine soldering to a KL02Z pin or removing this chip entirely.

    Hopefully in a few weeks I will have it all working - and will write up my progress in that NXP forum thread.

    [1] https://mcuoneclipse.com/2017/04/29/...swd-debugging/
    [2] https://medium.com/@mattmatic/prepar...d-b014b0ce2999
    [3] https://forum.pjrc.com/threads/42728...ing-strategies
    [4] https://www.nxp.com/support/develope...ols:MCUXPRESSO
    [5] https://www.nxp.com/products/process...-link2:OM13054
    [6] https://mcuoneclipse.com/2017/12/31/...dap-lpc-link2/

  2. #2
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    1,461
    Just to satisfy my scientific curiosity: Why would one make all this effort, if the Teensyduino ecosystem allows already to write extremely complex and efficient code (see for example the Teensy audio library) in an easy way?

    The only "problem" I can see with this environment is the lack of H/W debugging, which means allowing to set breakpoints in the code and to check variables at these. But I can't imagine any situation where this would be an absolute need, there are many ways for creative and smart developers to do without.

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,057
    I'm curious what the speed of reprogramming the flash memory will be with this approach. Any chance you'll make some simple speed measurements? (assuming it takes more than 1 to 2 seconds... long enough to easily measure with a stopwatch or timer).

  4. #4
    Paul, thanks to you and Robin for the Teensies.

    My only experience with them is the Teensy++ 2.0 in the Quicksilver 303 retrofit kits [1]. The user-friendly firmware upgrade process, using USB and a PC, Linux or Mac machine works beautifully. The firmware was written in C++ with GCC under Eclipse - so for this little 8 bit CPU the developer was using essentially the same language and compiler as I am using for x86-64 number-crunching software for mining optimisation.

    This USB loader system is one reason I want to use Teensies for future products. My best understanding of it comes from Matt Page [2].

    The 3.6 has the compute, RAM, flash and I2S audio CODEC capabilities I want, and your Teensy board is well suited to assembly in the devices my wife Tina and I will eventually manufacture. I don't want to worry about assembling BGA devices - and I think they are essentially unservicable by any mortal technician. However, if the K66, its BGA solder joints or anything else in the Teensy 3.6 fails, it will be easy for me or some other technician to install a new Teensy. I do not plan to have the Teensy with pins plug into a socket, since I think the PCB flexing which would be unavoidable with insertion and especially removal poses an unacceptable risk to the BGA solder joints. So I will use header pins soldered at both ends.

    Here are the reasons I want to avoid anything to do with Arduino, and use GCC and the powerful debugging arrangements which are now possible and highly affordable. This is based on zero experience so far developing for ARM, and a very limited understanding of Arduino, which I have never used.

    The Arduino system is clearly extremely valuable for many people learning about embedded programming. Curiosity typically comes from the top down: I wondered how the TV, toaster, light-globe, tape recorder and radio worked (I am a 1955 model) and today the equivalent question is "How does the PC / tablet / cell-phone / Internet / 3D printer work? . . . and can I pull one apart or build one?".

    At this point it generally makes little sense to answer with a bottom-up explanation of protons, neutrons, electrons, current flow, electromagnetism, orbital resonances, semiconductors, gates, minority carriers, amplifiers, digital logic, CPUs, assembly language etc., since that involves months or years of effort. The really curious will dig down and become fascinated with all this in due course.

    I understand that Arduino enables people to learn and make real working projects with modular hardware and source code, cobbled together with a language somewhat related to C/C++, without necessarily knowing anything concrete and detailed about electronics, digital logic or assembly level programming. This is an extraordinary thing - but I am sure there is a great sense of powerlessness when something doesn't work, since the user typically does not have the expertise or the time to fully understand everything, including the hardware, and all that could go wrong.

    My interest in the Teensy 3.6 is for a electronic musical instruments, to be made and sold in a way that they are robust and servicable for decades to come. This is all closed-source programming since open-source would reduce our ability to earn a living from the years of development work which is required. The user-friendly USB firmware update process is essential for any such product.

    I understand that Arduino libraries are GPL, so I can't use them. As far as I know, NXP provide a bunch of libraries, specifically tuned for this actual microcontroller (or at least its family) for common computational and I/O tasks, with licensing which enables them to be used in closed source projects. A assume these are written in standard C/C++ and perhaps assembler. Also, I am happy to deal with DMA controllers and the I2S interface directly, since I have done this kind of thing before. For other I/O systems such as USB or Ethernet I would certainly want libraries, since life is too short to understand that sort of thing and program for it from the ground up,

    I want to use modern, standard, full-featured C++ for ARM programming since I am already up-to-speed with this language, and find it necessary and sufficient for all the programming I am interested in. (Of course Python, PHP and other languages are best for other kinds of computing.)

    So I want to use GCC and GDB with an IDE I like. I use Codelite on Linux for x86-64 and initially thought I could continue like this, just by using a cross compiler and some kind of GDB server and debugger link to the ARM CPU. After glancing at the 2,250 page K66 Reference Manual, I decided that it would be better to use an IDE with numerous ARM-specific creature comforts built in, as NXP supplies for free with MCUXpresso and which are available for non-trivial cost from several companies.

    I don't know what limited debugging capabilities Arduino provides via a USB link. Nor do I know the full extent of the debugging facilities which can be achieved with GDB talking to a GDB server talking to this inexpensive but powerful LPC-Link2 debugger probe, operating in CMIS-DAP mode. Nor do I know the full extent of what is possible with the Serial Wire Viewer system. I expect to spend weeks or months extending my GDB skills to make the most of all these capabilities. Every hour spent improving the understanding of debugging tools will save many hours futzing around with bugs and false assumptions when I really want to be programming. In principle, debugging could be done with the Sopwith Camel approach, but it would be faster overall for me to invest a lot of time so I could fully use the equivalent of an Apache AH-64.

    [1] https://www.socialentropy.com/engine/?page_id=464
    [2] https://medium.com/@mattmatic/prepar...d-b014b0ce2999

  5. #5
    Here is how I soldered to pad 15 of the KL02Z. Grounding this pin should reset the KL02Z and so free the debug pins so we can use them. The heat to complete the joint was conducted through the single strand of wire I used to make the connection so it was not necessary to touch the pad itself with a soldering iron.

    https://forum.pjrc.com/threads/42728...064#post170064

Posting Permissions

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