4.1 latest schematics
- Thread starter MMo
- Start date
PaulStoffregen
Well-known member
Teensy 4.0 & 4.1 schematics haven't been updated for the U2 chip substitution. Realistically, they probably won't ever get updated. This U2 part is meant to be a temporary change until the original chip is available again in sufficient quantity. And no, you probably can't actually buy GD32E230 anywhere, at least not in the same package we're using on Teensy 4.0 & 4.1, and of course it would come blank and be unusable anyway. But you can still buy the original pre-programmed MKL02Z32 chip from PJRC, at least in moderate quantity. We made the substitution partly because not enough of the original chip was available, and partly so we could keep the remaining original well documented chips available for people making custom PCBs. We (probably) can't ever sell the substitute chip for custom PCBs because its package is slightly different and (as far as I know) no ZIF socket exists for it.
Such is life during these times of global chip shortages...
Such is life during these times of global chip shortages...
PaulStoffregen
Well-known member
Teensy 4.1 uses JTAG, not SWD. It would in theory be done if you solder more wires and use a JTAG adaptor. Just know that SWD can not work.
PaulStoffregen
Well-known member
If you do attempt this, here are the signal locations you'll need.
BOOT0 needs to be connected to GND for normal operation.
PSWITCH needs a low-to-high transition to turn on the 1.15V DC-DC power supply for the CPU.
MOD controls which JTAG device you access, either ARM debug or standard boundary scan. See the reference manual & datasheet for detail.
BOOT0 needs to be connected to GND for normal operation.
PSWITCH needs a low-to-high transition to turn on the 1.15V DC-DC power supply for the CPU.
MOD controls which JTAG device you access, either ARM debug or standard boundary scan. See the reference manual & datasheet for detail.
Yes
- Remove U2
- Pull-out GPIO_AD_B0_06/JTAG_TMS/SWD_DIO and GPIO_AD_B0_07/JTAG_TCK/SWD_CLK from U2 pins
- Pull-out 3V3 and GND
U2 pinout is my only reference how where to find those SWD pins, since RT1062 is BGA.
Why SWD won't work?
PaulStoffregen
Well-known member
If you play with JTAG boundary scan, the IMXRT chips have an undocumented bug were weird/wrong things happen if you stay in the various scan states for more than about 8 seconds. Parking in the test-logic-reset or run-test/idle states works fine.
PaulStoffregen
Well-known member
SWD absolutely will not work. All Teensy 4.1 boards are permanently fuse configured for JTAG. NXP did not implement dynamic switch between SWD & JTAG as ARM's documentation says. It will only talk JTAG because the fuse is permanently set to configure for JTAG only.
See the fuse map documentation in the reference manual if you need more info about this.
See the fuse map documentation in the reference manual if you need more info about this.
PaulStoffregen
Well-known member
Maybe not the answers you wanted, but hopefully this gives you the info you need to get started, rather then wasting a lot of time on reverse engineering.
PaulStoffregen
Well-known member
Another gotcha is PSWITCH. It will not work if simply wired to 3.3V. NXP's documentation about this quite misleading. It's not a simple active-high enable. A low to high transition is required (after 3.3V power is stable) to get the DC-DC converter to turn on.
You can find detailed documentation on the power up sequence on this page. Look for the schematic with buttons to highlight each power up step.
https://www.pjrc.com/store/ic_mkl02_t4.html
Once you remove U2, you'll lose step #7-8. Before you can even attempt to use JTAG debug, you'll need to create circuitry to drive PSWITCH to cause the CPU power to turn on.
Obviously you should only attempt JTAG communication after the CPU power becomes stable.
You can find detailed documentation on the power up sequence on this page. Look for the schematic with buttons to highlight each power up step.
https://www.pjrc.com/store/ic_mkl02_t4.html
Once you remove U2, you'll lose step #7-8. Before you can even attempt to use JTAG debug, you'll need to create circuitry to drive PSWITCH to cause the CPU power to turn on.
Obviously you should only attempt JTAG communication after the CPU power becomes stable.
Last edited:
Teensy 4.1 JTAG simple mod with the GD32E230F8
After modding a Teensy 4.1 with the GD32E230F8 it begins blinking twice the red led because of the missing JTAG connections.
Others like Spencez experienced then that JTAG is not possible with the chip soldered in.
The only candidades I can see are the pins 11, 15,16,17 of the GD32E230F8 as PSWITCH and RESET are on a proper level.
In principle EMC_01 = JTAG Debug enable only is a possibility to prevent the CPU from accepting JTAG. This pin is not documented.
Cutting all the pins 11, 15,16,17 would be an attempt.
But:
Is there any hidden design change that forces to remove the GD32E230F8 (thus leading to an own power up circuit for PSWITCH and RESET) .
Probably Paul has a tip how to get around this without adding an own power on circuit.
After modding a Teensy 4.1 with the GD32E230F8 it begins blinking twice the red led because of the missing JTAG connections.
Others like Spencez experienced then that JTAG is not possible with the chip soldered in.
The only candidades I can see are the pins 11, 15,16,17 of the GD32E230F8 as PSWITCH and RESET are on a proper level.
In principle EMC_01 = JTAG Debug enable only is a possibility to prevent the CPU from accepting JTAG. This pin is not documented.
Cutting all the pins 11, 15,16,17 would be an attempt.
But:
Is there any hidden design change that forces to remove the GD32E230F8 (thus leading to an own power up circuit for PSWITCH and RESET) .
Probably Paul has a tip how to get around this without adding an own power on circuit.
PaulStoffregen
Well-known member
I don't really understand your question.
I can tell you the GD32E230F8 always drives the TDI, TMS, TDI signals. If you want to gain access to JTAG for your own use, you must disconnect those signals from the GD32E230F8. Yes, of course that will cause the GD32E230F8 chip to give the 2 blink error (if it still has power and the red LED connected) because it's unable to detect the main chip using JTAG.
No idea if that really answers your question, because I really don't understand what you're trying to ask.
First of all: thanks for the fast response.
There was a comment by Spencez. He said, that the JTAG mod just cutting the JTAG wires with the GD32E230F8 in place was not working any more.
He doesn't get access to the RT1062 by JTAG anymore
He is saying that he has to remove the GD32E230F8 .
I want to avoid that and just asking if this is really true and which of the other wires could be the reason for the experience of Spencez.
See the reference to his comment and the sentence I am talking about below.
https://forum.pjrc.com/threads/66180-Teensy-4-1-Debug-Mod-Project?p=297060&viewfull=1#post297060
"Although I did move away from reusing the MKL02 because a newer chip I received from Paul had new software which would cause it to blink the led when J-Tag was not responding and I could not get it to work correctly anymore. Diagnostic Blink Codes for reference. https://www.pjrc.com/store/ic_mkl02_t4.html
As long as you do not see the two blink code, I do not think this will be an issue for you."
There was a comment by Spencez. He said, that the JTAG mod just cutting the JTAG wires with the GD32E230F8 in place was not working any more.
He doesn't get access to the RT1062 by JTAG anymore
He is saying that he has to remove the GD32E230F8 .
I want to avoid that and just asking if this is really true and which of the other wires could be the reason for the experience of Spencez.
See the reference to his comment and the sentence I am talking about below.
https://forum.pjrc.com/threads/66180-Teensy-4-1-Debug-Mod-Project?p=297060&viewfull=1#post297060
"Although I did move away from reusing the MKL02 because a newer chip I received from Paul had new software which would cause it to blink the led when J-Tag was not responding and I could not get it to work correctly anymore. Diagnostic Blink Codes for reference. https://www.pjrc.com/store/ic_mkl02_t4.html
As long as you do not see the two blink code, I do not think this will be an issue for you."
PaulStoffregen
Well-known member
Ok, now I understand, you're really asking about comments from a message on another thread.
I can't say why it didn't work for Spencez, but I can confirm nothing in the GD32E230F8 should interfere if you really have severed those JTAG signals from it.
The 2 blink error absolutely is the expected behavior, because from the GD32E230F8 chip's point of view none of the JTAG signals are connected anymore. It will just sit there and keep trying to establish communication.
For completeness, even though it's almost certainly irrelevant for your usage, might also be worth mentioning this is all with regard to standard Teensy, or lockable Teensy not yet locked into secure mode. JTAG gets disabled if you lock secure mode.
I can't say why it didn't work for Spencez, but I can confirm nothing in the GD32E230F8 should interfere if you really have severed those JTAG signals from it.
The 2 blink error absolutely is the expected behavior, because from the GD32E230F8 chip's point of view none of the JTAG signals are connected anymore. It will just sit there and keep trying to establish communication.
For completeness, even though it's almost certainly irrelevant for your usage, might also be worth mentioning this is all with regard to standard Teensy, or lockable Teensy not yet locked into secure mode. JTAG gets disabled if you lock secure mode.
Sorry if my previous experience caused me to provide incorrect information. I was still working with the MKL02 at the time but I had not experienced the blink codes until then, I was under the impression that the software changed in some way that cutting the JTAG connections may affect the power up sequence. It is very possible I had a bad connection somewhere.
I have connected JTAG to a Teensy with a GD32 chip, but I am still removing the chip completely as I did before and driving PSWITCH and a few other pins myself. Since I switched to my new method I did not have a reason to go back and find my fault.
Here is one of my Teensy with the MKL02 footprints. I have a new PCB made for the GD32 footprint but I have not been able to test it yet.
I have connected JTAG to a Teensy with a GD32 chip, but I am still removing the chip completely as I did before and driving PSWITCH and a few other pins myself. Since I switched to my new method I did not have a reason to go back and find my fault.
Here is one of my Teensy with the MKL02 footprints. I have a new PCB made for the GD32 footprint but I have not been able to test it yet.
Thanks for sharing that.
This looks great, but not available for everybody's use, right ?
Anyway, I found a lot of hints that you shared. Very helpful. The last one on platformio.
(This looks more complicated than expected. Hopefully the jlink solution for the gdb server works also for me.)
By the way: this small 6 leg device looks very interesting for the job. What is it ?
This looks great, but not available for everybody's use, right ?
Anyway, I found a lot of hints that you shared. Very helpful. The last one on platformio.
(This looks more complicated than expected. Hopefully the jlink solution for the gdb server works also for me.)
By the way: this small 6 leg device looks very interesting for the job. What is it ?
I made now my own tests with GD32 and found the JTAG debugging instable. It seems that it is not reliably possible to halt the CPU so that the debugger gets a grip on the MCU before the first breakpoint passes by.
Uploading works. Sometimes also stepping. But unpredictable.
Question is: is it the hardware or the configuration of platformio. I am using the same config as others - reported as working - and use a simple blinking program.
Was this your experience ? Unpredictable behaviour ?
When I look on the pins of the GD32 that are unknown I find that these pins are silent - low or high.
Are you using the POR_B Signal to provide a reset by the JTAG connection ?
I have not shared the files for this version yet. I intend to share everything once I feel it is at a point where someone can easily install it, hopefully that will be very soon. I will also look into reusing the bootloader now that I know it should not be an issue.
The 6pin chip is an ATTINY10 microcontroller, I make use of every pin to change modes, reset, and power up.
I do not have any issues with instability or missed breakpoints. I'm not sure if it could be the platformio config, which one are you using? Are you making sure the project is being built with the Optimization set to DEBUG Og? It is possible the code is being optimized and causing breakpoints to be "passed by", same with stepping.
I am only using POR_B to reset when I tap the button on the Teensy, the debugger seems to handle resets over JTAG just fine. I have not used Platformio in quite a while, I have set up my own projects in VSCode and use the Cortex-Debug extension. I can help you with a blink project if we find PlatformIO to be the issue but it requires some setup.
Last edited:
ATTINY10, cool. I have everything for ATMEL now Microchip in the shelf, but didn't use it for a while. A good option instead of programming CPLD or so for slow applications.
Thanks for the hint. I played with the compiler options, because this was the first thought I had and "O0" was recommended by others and the docs.
Reading further now it says some of the debugging information is lost with "O0" and "Og" is recommended.
OK, gcc is not my core compiler.
I will dig into it again and check where it is coming from. I try to find more info for the reset, halt etc. probably by directly using the JLink tools by single commands.
Probably we have to change the thread if this goes further.
Thanks for the hint. I played with the compiler options, because this was the first thought I had and "O0" was recommended by others and the docs.
Reading further now it says some of the debugging information is lost with "O0" and "Og" is recommended.
OK, gcc is not my core compiler.
I will dig into it again and check where it is coming from. I try to find more info for the reset, halt etc. probably by directly using the JLink tools by single commands.
Probably we have to change the thread if this goes further.
Results so far:
1. GD32 simple mod with cutting the pcb wires works. Not easy, but feasible.
!!!! There is no hidden problem with the G32 !!
2. The mentioned problems above have to do with the configuration of platformio and CLion or the IDE integration. I posted the problem there.
3. platformio debugging on the commandline works with the gdb excellent with JTAG. This was the main goal.
As we use CLion for all our projects we are interested to stay with it. Visual studio code did also not work out of the box.
About these problems I will probably report later after they are solved.
To have a debugger is mandatory for what we plan with the Teensy.
1. GD32 simple mod with cutting the pcb wires works. Not easy, but feasible.
!!!! There is no hidden problem with the G32 !!
2. The mentioned problems above have to do with the configuration of platformio and CLion or the IDE integration. I posted the problem there.
3. platformio debugging on the commandline works with the gdb excellent with JTAG. This was the main goal.
As we use CLion for all our projects we are interested to stay with it. Visual studio code did also not work out of the box.
About these problems I will probably report later after they are solved.
To have a debugger is mandatory for what we plan with the Teensy.
PaulStoffregen
Well-known member
More detailed pin info followup on this thread:
https://forum.pjrc.com/threads/73001-U2-Gd32e230?p=327210&viewfull=1#post327210
https://forum.pjrc.com/threads/73001-U2-Gd32e230?p=327210&viewfull=1#post327210