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

Thread: Teensy 4.1 Debug Mod Project

  1. #1
    Junior Member
    Join Date
    Dec 2020
    Posts
    11

    Teensy 4.1 Debug Mod Project

    I have been working on a Teensy 4.1 debugger mod for a month or so now and I figured it was in a good place to share my progress. This project started by de-soldering the MKL02 chip, soldering magnet wire onto each pin of the MKL02 and the Teensy to break them out to 16 pin headers on a breadboard. From there I jumpered the pins which were necessary for the teensy to function while leaving the J-tag pins free to be used by a J-Link.

    Click image for larger version. 

Name:	teensy 4.1 mod 2.jpg 
Views:	40 
Size:	69.1 KB 
ID:	23599
    Click image for larger version. 

Name:	teensy 4.1 mod 1.png 
Views:	41 
Size:	451.0 KB 
ID:	23600

    I was successful in programming and debugging using PlatformIO so I continued the project by designing a flex pcb which could be soldered onto the teensy QFN pads. This first attempt failed as too much of the pads were cut and upon soldering they came right off.

    Click image for larger version. 

Name:	teensy fail 1.png 
Views:	49 
Size:	441.7 KB 
ID:	23601

    Which brings us to the current revision. Fully functioning Teensy 4.1 debugging!

    Click image for larger version. 

Name:	teensy debugger 1.png 
Views:	71 
Size:	532.5 KB 
ID:	23602
    Click image for larger version. 

Name:	teensy debugger 2.png 
Views:	45 
Size:	220.2 KB 
ID:	23603
    Click image for larger version. 

Name:	teensy debugger 3.jpg 
Views:	49 
Size:	49.8 KB 
ID:	23604

    If you see this Paul, I would love for debugging on the next Teensy to be a bit easier! Although this has been an interesting/fun project to work on so thanks for that.

  2. #2
    Junior Member
    Join Date
    Apr 2020
    Posts
    5
    This is very cool. Never seen someone take out a IC like this, that's quite clever

    Any chance of releasing the files or selling these PCBs?

  3. #3
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    843
    Maybe PJRC should make a debug version. It's easy for a debugger to save $100 in time.

  4. #4
    Junior Member
    Join Date
    Feb 2021
    Posts
    5
    Hello Spencez,

    nice work.
    I also plan to add a JTAG access to the teensy 4.1, but I would prefer to re-program (in-situ) the KL-02 chip.
    Could you tell me whether it is protected against full erase or not?

    Thank you!

  5. #5
    Junior Member
    Join Date
    Dec 2020
    Posts
    11
    Quote Originally Posted by TGlev View Post
    This is very cool. Never seen someone take out a IC like this, that's quite clever

    Any chance of releasing the files or selling these PCBs?
    I will probably upload the files and/or post it on OSHPark. It requires hot air, good soldering skills and flux.

    Quote Originally Posted by jonr View Post
    Maybe PJRC should make a debug version. It's easy for a debugger to save $100 in time.
    I would love if they did this. I feel as if they are waiting until they make the switch from Arduino IDE to bother with debug capability.

    Quote Originally Posted by Jory View Post
    Hello Spencez,

    nice work.
    I also plan to add a JTAG access to the teensy 4.1, but I would prefer to re-program (in-situ) the KL-02 chip.
    Could you tell me whether it is protected against full erase or not?

    Thank you!
    Sorry, I am not sure on this one. I don't have an easy way of getting to the SWD pads at the moment. Worst case you have to buy a new chip and solder it in. That sounds like a project, I hope you figure it out!

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,949
    Quote Originally Posted by Jory View Post
    but I would prefer to re-program (in-situ) the KL-02 chip.
    Could you tell me whether it is protected against full erase or not?
    I can confirm PJRC does not protect the MKL02 from mass erase. You can erase it to wipe away the PJRC bootloader, if that is your desire.

    Of course if you do erase the chip, the only way to restore your board would be to desolder the erased chip and solder a pre-programmed chip in its place.

  7. #7
    So if I was to wipe the MKL02 and solder a JTAG connector to the relevant pins then the Teensy can be flashed and debugged over JTAG and the only downside would be that the teensy flasher app would no longer work, apart from that everything stays the same?

  8. #8
    Junior Member
    Join Date
    Feb 2021
    Posts
    5
    Quote Originally Posted by PaulStoffregen View Post
    I can confirm PJRC does not protect the MKL02 from mass erase. You can erase it to wipe away the PJRC bootloader, if that is your desire.

    Of course if you do erase the chip, the only way to restore your board would be to desolder the erased chip and solder a pre-programmed chip in its place.
    Thank you for this information Paul.
    As I said on an other post, I won't use the Arduino IDE/libraries, so it is unlikely that I want to restore the stock firmware. I just want to use the KL02 as a voltage monitor/boot IC.
    About that, could you tell me what is the purpose of the B0_13 pin in the boot process?
    Thank you.

    EDIT: I just saw the Bootloader chip page, that is what I was looking for, great!

    Is there any chance that the hardware initialization has not been done when we receive the board? i.e. as long as the board is not powered on the HW_OCOTP_CFG5 fuse word is blank.

    EDIT2: Ok, I read on an other thread that the i.MX RT fuses are set in factory.
    Last edited by Jory; 02-10-2021 at 10:15 AM.

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,949
    Quote Originally Posted by Jory View Post
    Is there any chance that the hardware initialization has not been done when we receive the board?
    We have multiple processes and double checks (including daily inventory reconciliation) at PJRC which are designed to make the odds of such a terrible mistake virtually zero. In the roughly 12 years we've been making Teensy, I can not recall even 1 case where this has ever happened. Plenty of other things have occasionally gone wrong, like shipping the wrong board, packages run over by a postal truck, issues with credit card processing, etc, etc... but failing to test & program boards isn't one of them.

    When you first apply power to any brand new Teensy, the orange LED is supposed to blink. The LED blink program is loaded into the flash memory via a USB cable using the normal bootloader-based programming process. Every Teensy goes through this test and can not pass unless all prior tests were completed successfully. Long ago the pass/fail was confirmed by a human watching the LED. We still do that, but the test fixture also measures the USB cable current and watches for it to change by about 2-3 mA as the LED turns on, so the test can't pass unless the LED really is using the right amount of power. Our testing process also keep a count of the number of unique boards it has passed in each session, which is shows on a bright 7-segment display the operator can see while testing the boards. The counter doesn't increment if any part of the test fails. That number is checked against the total, and as the boards are tested and placed on an anti-static mat, they are arranged in little groups of 5 boards, and areas of 25, where there's a strong human tendency to confirm the 7 segment display number is a multiple of 5 and 25 as each row of 5 and group of 5 rows is completed. We also have a process for logging each failure, which keeps the small number of bad boards from being able to get mixed up with good ones (and gives us a sure way to reconcile inventory to catch any mistakes). Human error is always still possible, but I can tell you we've put a lot of work into the process over the years to really minimize the odds of a mistake not getting caught.

    Slow blinking on the orange LED is a sure sign your board was properly initialized and fully tested. Likewise, holding the button of ~15 seconds for the blink restore process is also a sure sign everything on a Teensy 4.0 or 4.1 was properly initialized.

    Hypothetically speaking, if a board isn't initialized, you would also not see 3.3V on the Program pin (when not pressing the pushbutton) because the pin is 3.3V due to the internal pullup resistor inside the MKL02 chip. Pressing the button would not cause the red LED to turn on. The IMXRT's DCDC converter would also never turn on to create the 1.15-1.25V power for the CPU, since the DCDC_PSWITCH control signal is held low by a 100K pulldown resistor and can't turn on without the MKL02 driving that pin high.

  10. #10
    Junior Member
    Join Date
    Feb 2021
    Posts
    5
    Paul,

    my remark had nothing to do with PJRC quality control, sorry if my sentence was not clear.
    I just wondered if the MCU could arrive blank and programmed at the first boot by the bootloader chip, so that I could enable SWD (of iMXRT) by disabling the KL02.

    But, as I said in my "edit", it is not the case because the RT fuses are set at factory.

Posting Permissions

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