DIY Teensy 4.1 stuck at double blinking

B

bhaskar

Member
We are trying to build a custom teensy board. Currently we are experiencing the double blinking error, indicating JTAG not responding or improper power startup sequence. We have tried 3 PCBs, and the issue is same (perhaps the issue is with our schematic itself).
The chips MKL, MIMXRT, and W25Q64 are bought from PJRC.
We would greatly appreciate it if anyone could point out any issues with the attached schematics.
Many thanks in advance!
schematics.png
 
Hello.
First time posting.

The 24MHz crystal (according to the symbol shown) is not connected to XTALO correctly. Connections to GND and XTALO should be swapped (at top of crystal symbol). Don't forget to move the capacitor as well.
The XTAL1 connection is okay.
I haven't reviewed the rest of schematic.
 
Thanks a lot for the help.
After fixing the crystal connection it seems the errors are gone. However, I am still not able to upload any program.
When I connect the board, the PC gives the sound. When trying to upload with the program button, the chip appears (in Teensy loader) and disappears, and nothing happens. [After pressing the program button, the LED blinks 3 times while PC showing the chip].
 
Last edited:
jmarsh said:
You tried to upload a blink sketch for the Teensy2. Try the sketch for Teensy 4.1 (ends in 41).
Click to expand...
Thank you for your reply. I also tried the file 'blink_slow_Teensy41.hex', but the issue is same.
[After pressing the program button, the LED blinks 3 times while PC showing the chip]
Is it possible that something is damaged?
The issue is the same with 2 PCBs.
t41.png
 
Last edited:
If a 15 sec Restore works it should stay with RED LED on some long time then come back to blink showing the bootloader and the 1062 are in good shape together.
>> Power, Press Button and hold ~15 secs until RED LED (bootloader LED) flashes and release button ...

If that fails the problem is in those connects perhaps

In either case the initial fail state may have interrupted the 1062 init?

What does the Verbose report in Teensy.exe show during connect and upload attempt? If that works then that part is healthy for sure.
 
defragster said:
If a 15 sec Restore works it should stay with RED LED on some long time then come back to blink showing the bootloader and the 1062 are in good shape together.
>> Power, Press Button and hold ~15 secs until RED LED (bootloader LED) flashes and release button ...

If that fails the problem is in those connects perhaps

In either case the initial fail state may have interrupted the 1062 init?

What does the Verbose report in Teensy.exe show during connect and upload attempt? If that works then that part is healthy for sure.
Click to expand...
The verbose report shows the following:

17:53:52.435 (loader): Teensy Loader 1.58, begin program
17:53:52.480 (loader): File "C:\Users\PC\Downloads\blink_both\blink_both\blink_slow_Teensy41.hex", 14452 bytes
17:53:52.480 (loader): File "blink_slow_Teensy41.hex". 14452 bytes
17:53:52.480 (loader): Listening for remote control on port 3149
17:53:52.480 (loader): initialized, showing main window
17:53:52.718 (loader): HID/win32: vid:0B05 pid:8854 ver:0003 usb:0/140000/0/6/7
17:53:52.718 (loader): HID/win32: vid:0B05 pid:8854 ver:0003 usb:0/140000/0/6/7
17:53:52.718 (loader): HID/win32: vid:0B05 pid:8854 ver:0003 usb:0/140000/0/6/7
17:53:52.718 (loader): HID/win32: vid:0B05 pid:0220 ver:0000 usb:190000/1
17:53:52.718 (loader): HID/win32: vid:0B05 pid:0220 ver:0000 usb:190000/1
17:53:52.718 (loader): HID/win32: vid:093A pid:3F01 ver:0A2B usb:150001/1
17:53:52.718 (loader): HID/win32: vid:0B05 pid:0220 ver:0000 usb:190000/1
17:53:52.718 (loader): HID/win32: vid:0B05 pid:8854 ver:0003 usb:0/140000/0/6/7
17:53:52.718 (loader): HID/win32: vid:04F3 pid:2F64 ver:6113
17:53:52.718 (loader): HID/win32: vid:04F3 pid:2F64 ver:6113
17:53:52.718 (loader): HID/win32: vid:04F3 pid:2F64 ver:6113
17:53:52.718 (loader): HID/win32: vid:04F3 pid:2F64 ver:6113
17:53:52.718 (loader): HID/win32: vid:046D pid:B020 ver:0009
17:53:52.718 (loader): HID/win32: vid:04F3 pid:2F64 ver:6113
17:53:52.718 (loader): HID/win32: vid:04F3 pid:2F64 ver:6113
17:53:52.718 (loader): HID/win32: vid:093A pid:3F01 ver:0A2B usb:150001/1
17:53:52.718 (loader): HID/win32: vid:04F3 pid:2F64 ver:6113
17:53:52.718 (loader): HID/win32: vid:04F3 pid:2F64 ver:6113
17:53:54.617 (loader): Open File event
17:53:59.582 (loader): File "C:\Users\PC\Downloads\blink_both\blink_both\blink_slow_Teensy41.hex", 14452 bytes
17:53:59.582 (loader): File "blink_slow_Teensy41.hex". 14452 bytes
17:54:04.483 (loader): handle 73c
17:54:04.483 (loader): Device came online, code_size = 100
17:54:04.483 (loader): Board is: NXP IMXRT1062 ROM
17:54:04.483 (loader): begin operation
17:54:04.483 (loader): File "C:\Users\PC\Downloads\blink_both\blink_both\blink_slow_Teensy41.hex", 14452 bytes
17:54:04.483 (loader): File "blink_slow_Teensy41.hex". 14452 bytes
17:54:04.483 (loader): set background IMG_ONLINE
17:54:04.483 (loader): nxp_write: success
17:54:04.483 (loader): nxp_write: success
17:54:04.483 (loader): HAB open mode, bootcfg=80018
17:54:04.483 (loader): Opps, NXP ROM in open mode, but we do not yet have code for this case :(
17:54:04.483 (loader): start ignoring usb:0/140000/0/4
17:54:04.483 (loader): end operation, total time = 0.000 seconds
17:54:04.483 (loader): redraw timer set, image 79 to show for 3000 ms
17:54:07.491 (loader): redraw, image 9
17:54:09.733 (loader): stop ignoring usb:0/140000/0/4
17:54:10.237 (loader): handle 5e4
17:54:10.237 (loader): Device came online, code_size = 100
17:54:10.237 (loader): Board is: NXP IMXRT1062 ROM
17:54:10.237 (loader): begin operation
17:54:10.237 (loader): File "C:\Users\PC\Downloads\blink_both\blink_both\blink_slow_Teensy41.hex", 14452 bytes
17:54:10.237 (loader): File "blink_slow_Teensy41.hex". 14452 bytes
17:54:10.237 (loader): set background IMG_ONLINE
17:54:10.246 (loader): nxp_write: success
17:54:10.247 (loader): nxp_write: success
17:54:10.247 (loader): HAB open mode, bootcfg=80018
17:54:10.247 (loader): Opps, NXP ROM in open mode, but we do not yet have code for this case :(
17:54:10.247 (loader): start ignoring usb:0/140000/0/4
17:54:10.247 (loader): end operation, total time = 0.010 seconds
17:54:10.254 (loader): redraw timer set, image 79 to show for 3000 ms
17:54:13.154 (loader): Verbose Info event
17:54:13.249 (loader): redraw, image 9
 
Can you measure the VDD_SOC_IN voltage? If the last stage of the power up sequence is working, it should be 1.15V or 1.25V.

Maybe also check the voltages on VDD_HIGH_CAP, NVCC_PLL, and VDD_SNVS_CAP.

If the board truly has completed all stages of the power up sequence (see the little javascript buttons on the T4 bootloader page to visualize) then the only other plausible explanation for 2 blinks would be a wiring error between IMXRT1062 and MKL02. But your schematic appears to be correct, at least by a quick looks comparing to the Teensy 4.1 schematic, so if there is a wiring problems between the chips it's likely something subtle. Maybe with showing the layout and photos of the bare and assembled PCBs something wrong might become visible.

But since the wiring appears correct on the schematic, first check that all power supply rails came up to proper voltages. Let's only dive into pictures of the layout and photos of the actual PCB if the power rails all check out.
 
Another thing to check, probably a long-shot, is whether you have anything driving the IMXRT1062 pins before it starts the power up sequence. Perhaps other devices that power up separately?
 
bhaskar said:
The verbose report shows the following:

17:53:52.435 (loader): Teensy Loader 1.58, begin program
// ...
17:54:04.483 (loader): HAB open mode, bootcfg=80018
17:54:04.483 (loader): Opps, NXP ROM in open mode, but we do not yet have code for this case :(
17:54:04.483 (loader): start ignoring usb:0/140000/0/4
Click to expand...
Does this mean the 1062 wasn't fuse configured and updated?
Would the 15 Sec Restore complete this? @bhaskar was this tried?
 
Hi everyone,
Thanks for the valuable insights.
The issue was perhaps improper soldering as I do not have much experience. I removed and resoldered both the MKL and W25Q64 chips, and it now works as expected!

The main mistake in the design was connection of the 24MHz oscillator as already pointed out.
 

Attachments

  • Schematic_SCAN_CTRL_V2.0_R0_2024-06-21.png
    Schematic_SCAN_CTRL_V2.0_R0_2024-06-21.png
    752.5 KB · Views: 54
  • DIY T41-2.png
    DIY T41-2.png
    1.6 MB · Views: 37
PaulStoffregen said:
Another thing to check, probably a long-shot, is whether you have anything driving the IMXRT1062 pins before it starts the power up sequence. Perhaps other devices that power up separately?
Click to expand...
Hi Paul,

Many thanks for the reply.
We fixed the issue by simple resoldering the MKL and W25 chips. Apart from that the oscillator connection was wrong.
Now we can flash codes without any issue, and IO ports seem working fine. We will do more testing.

Additionally, since we plan to use these custom boards in our commercial devices, do we need any licensing from PJRC or any PJRC-specific information on the PCBs, given that the microcontroller section of our board follows the PJRC schematic?
 
Hardware-wise, using the MKL02 chip from PJRC means you're good to go. Software-wise, most libraries are MIT license which is meant to allow usage in commercial proprietary products. But a few are GPL, like Entropy, so check the license on all libraries you're using.
 
We are testing the DIY version, and find that the digital outputs encounter some oscillations. We tried digitalWrite(30, 0) on both standard and DIY versions, and the results are as follows. May it be caused by improper grounding? The PCB consists of 6 layers. 2nd and 5th layers with ground planes, and 6th laser with 3.3V plane. Any suggestion is highly appreciated.

standard t41.png


custom DIY.png


Screenshot 2024-07-10 161833.png
 
Taking a quick look at your layout it doesn't look ideal. You have multiple power and ground pins connected together by a long thin trace and then a single via to the plane. Ideally it should be one via per pin, those pins should be connected as directly as possible to the plane. You certainly want to avoid any long traces that visit a long chain of pins. They way you have done it is going to introduce a lot more noise onto the processors power and ground pins.
For signals that go to lots of pins like VDD_SCO_IN it's often best to create a localised plane on one of the layers rather than running a trace between them.

There are a few other things that seem non-ideal, AC14-16 are not very well placed relative to AL2 and the related processor pins. You haven't removed floating islands in the ground flood. And personally I would have put ground on layer 2 and VCC on layer 3. Power on the outer layer seems like an unusual stackup.
 
AndyA said:
Taking a quick look at your layout it doesn't look ideal. You have multiple power and ground pins connected together by a long thin trace and then a single via to the plane. Ideally it should be one via per pin, those pins should be connected as directly as possible to the plane. You certainly want to avoid any long traces that visit a long chain of pins. They way you have done it is going to introduce a lot more noise onto the processors power and ground pins.
For signals that go to lots of pins like VDD_SCO_IN it's often best to create a localised plane on one of the layers rather than running a trace between them.

There are a few other things that seem non-ideal, AC14-16 are not very well placed relative to AL2 and the related processor pins. You haven't removed floating islands in the ground flood. And personally I would have put ground on layer 2 and VCC on layer 3. Power on the outer layer seems like an unusual stackup.
Click to expand...
Hi Andy,
Thank you for your valuable insights.
In this circuit we are also using DAC and Opamp, and to power them, we need +-9V supplies. From +9V, we are using linear regulator to get +5V to power the microcontroller. We also suspected the issue we see might be due to power lines. We tried removing +-9V supplies, and directly powering the microcontroller from the USB, however, the issue was the same.
That long trace as you mentioned is actually carrying -9V to a -6V regulator (powers an opamp). To avoid the long trace, perhaps we can put the regulator just near the power input. We would also use 3rd layer for the +5V (VCC).
Regarding placement of AC14-16, do you have any suggestion?
 
The long traces that worried me weren't big thick power supply ones going around the board, assuming a sensible power supply at the far end of them the length isn't an issue there.
The ones that concerned me were the ones under the BGA that looked to be connecting lots of power and ground pins to a single via.
No they aren't long in the grand scheme of things but they are far longer than you want the power connections to the processor to be. As I said the processor pins should be as tightly coupled to the power/ground planes as possible, that means a via per pin if possible, worst case one for every pair of adjacent pins.

For the DCDC_IN signal the trace on the board should follow the same path as the schematic, from the inductor it should go through the pads for the capacitors and from there to the processor pins. The capacitors should be in size order, the lowest value closest to the chip. This gives the lowest impedance on the power input pin.
 
AndyA said:
The long traces that worried me weren't big thick power supply ones going around the board, assuming a sensible power supply at the far end of them the length isn't an issue there.
The ones that concerned me were the ones under the BGA that looked to be connecting lots of power and ground pins to a single via.
No they aren't long in the grand scheme of things but they are far longer than you want the power connections to the processor to be. As I said the processor pins should be as tightly coupled to the power/ground planes as possible, that means a via per pin if possible, worst case one for every pair of adjacent pins.

For the DCDC_IN signal the trace on the board should follow the same path as the schematic, from the inductor it should go through the pads for the capacitors and from there to the processor pins. The capacitors should be in size order, the lowest value closest to the chip. This gives the lowest impedance on the power input pin.
Click to expand...
Hi Andy,
Thanks a lot! I now get your points.
 
bhaskar said:
Regarding placement of AC14-16, do you have any suggestion?
Click to expand...

You could place them similarly to how they're placed on Teensy. Especially important to place the DCDC decoupling capacitors (both input and output) directly underneath the BGA chip with traces as short as possible to the vias, and those vias as close as possible to the BGA pads.
 
PaulStoffregen said:
You could place them similarly to how they're placed on Teensy. Especially important to place the DCDC decoupling capacitors (both input and output) directly underneath the BGA chip with traces as short as possible to the vias, and those vias as close as possible to the BGA pads.
Click to expand...
Hi Paul, Thanks for the suggestions.
I have revised the design. Do you suggest any improvement?

top-bottom layers.png
 
Many more much smaller decoupling caps (10nF 0402?), one for each via that needs it? - that's how its usually done. 4- or 6-layer boards are typically needed for BGA devices. Large decoupling caps typically are further out as they can afford a bit more inductance between them and the 10nF decouplers. You want a solid groundplane on one layer if possible (hence 4-layer requirement). All the decoupling caps work against that groundplane, which is why its important.
 
It still looks like you have 10 pins in a long line off a single via.

As said before, one via direct to the plane for each power pin. The same for capacitors, one via per capacitor, normally the same one as goes to a power pin.
For local power rails create a small isolated plane under the part.
Power planes should be adjacent to ground planes in the stackup.
The idea is that you are using the plane as a small but very low impedance decoupling cap. You then connect all the power pins and capacitors to this plane with the lowest impedance path possible (a via right next to the pad) in order to take as much advantage as possible of the total distributed effect of the capacitors.

As MarkT indicated the placement of the larger caps isn't so critical, they aren't much use for the really high frequency stuff anyway. But they should be connected as directly as possible to a plane rather than using traces to connect them to other parts. The critical bit is to get the small caps as close as possible to the power pins, they are the ones that help with the really high frequency changes. As close as possible is one board thickness plus 2x minimum pad to via spacing.
I'd also have used more 10nF caps but if the Teensy manages with that few then it's hard to argue that more are needed unless you are aiming to keep noise levels lower than on the Teensy board.
 
You must log in or register to reply here.
Back
Top