None booting custom teensy board :(

Status
Not open for further replies.
R

russdx

Well-known member
Hello

In following on from this thread
https://forum.pjrc.com/threads/29280-Sanity-Check-custom-teensy-pcb-design-(circuitmaker)

Notes:
- The design is powered from external 5v psu (not usb)
- The 5v in and 3.3v out from mk20 reg look very clean

I have now had my design assembled. But nothing happens! when powered on. I have done a lot of research on this forum as to what can cause this and to what should be happening.

So far I have found that the mk20 reset_b line just stays at 3.3v (It does not try and reset every 53us like it should be doing) And this is with it completely disconnected from the programmer board.

With the programmer board disconnected from the main board I can press the PROG button and it will drop it its P5.2 port low for 4ms then raise it again (until i reset the power) But with this board connected to the main board (so now connected to the mk20 reset_b it will NOT drop low (like the reset_b is to strong and holds it high)

So from this I can assume the mini54 programmer board seems to be working correctly. The mini54 seems to be running pauls firmware fine and doing what it should do at this point in the boot sequence.


The problem seems to lie with the reset_b line on the main mk20 board it does not seem to do any thing! no life at all apart from been held at 3.3v

I am putting 4.7v into the mk20 regulator and getting 3.3v out so that part seems to all be working.

On the programming header the ports are held at these voltages: (with mini54 programmer board disconnected)(using the mini54lan port numbering)
P0.5/P0.6 - 3.3v
P0.1 - 0v
P0.0 - 3.3v
P0.7 - 0v
reset_b - 3.3v



I have checked my schematic over for mistakes. It looks fine to me. I have checked for shorts on the pcb cant find any. The mk20 just seems DEAD. Am i using the wrong crystal or crystal caps? Would these effect the boot sequence if wrong? (or only come into effect when you try and run a program)

I used these parts for the Crystal circuit
http://uk.rs-online.com/web/p/ceramic-multilayer-capacitors/8145558/
http://uk.rs-online.com/web/p/crystal-units/6936970/


Not sure where to look next really as im getting no life at all its like the mk20 is totally dead. Even though its getting all the correct power (and kicking out the correct 3.3v). It does not try to boot.


Any help will be much appreciated :)

Regards
Russell
 
What does your oscilloscope say when you check the crystal pins? You should use a 1:10 probe for that to reduce parasitic capacitance.
 
Those are 0v

I have read that the crystal will not even be enabled until the program is running? and I am not getting near this point so at the moment I guess nothing on the crystal lines is to be as expected.

(I assume the whole watchdog process with the reset line is done without using the external crystal?)

More worried about this static reset_b line that should be doing some thing. Not just staying high.

Regards
Russell
 
You could attach a SWD debugger (instead of your programmer) and use it to access the MK20.

I don't know - perhaps even a boundary scan is possible.
 
So I take it you used a 18pF crystal along with a pair of 20pF capcitors?

Is the area around the crystal properly grounded with No nearby digital signals? (Esp below the crystal)

Why the use of this ginormous crystal/cap setup when the OEM crystal is tiny and proven? See Pauls advice re load caps - https://forum.pjrc.com/threads/27378-Teensy-3-x-Crystal

As I understand it, Paul sets up the internal MK20 cap banks to expect a 8pF crystal. So you have to consider those caps in parallel to any external caps you provide.
 
Last edited:
russdx said:
So far I have found that the mk20 reset_b line just stays at 3.3v
Click to expand...

Perhaps you've connected to the wrong pin? Carefully check your PCB layout.

Or maybe the pin isn't soldered properly, so you're only connected to the Mini54 but not the MK20?

With a completely blank brand new MK20 chip, you should *always* see the pulsing behavior on that pin.
 
Also, is D26, aka pin 33 being pulled low? That can block MiniTan54 based boards.

But to work, reset has to pull low on schedule. Have you DMM'd that pin to see if you have a short leading to reset being pulled high inadvertently? I'd also check the power pins to make sure there is a good connection to VOUT and VSS, respectively.

If all power and reset connections check out then I'd go and change the crystal to a 8pF model to eliminate that from interfering.
 
Last edited:
No shorts. Reset_b is not connected to anything else when programmer board removed it is floating.

I have noticed mk20 pin33 PTA4 is set to ground. Wi this stop the mk20 from booting?

Regards
Russell
 
Yes. it does stop the process on a MiniTAN54-based board.

Cut the pin off or convert it to a floating output by using your soldering iron to lift it off the pad.

Paul has stated that this is no longer a problem on MK02/04-based bootloader boards.
 
PTA4 has an always-on pullup resistor inside the MK20 chip. If you haven't connected anything to that pin, it should be at 3.3V.

Everything you've described sounds like the MK20 chip is wired up very wrong. Perhaps it's rotated 90 degrees and not soldered to the intended pins at all?
 
Constantin said:
Paul has stated that this is no longer a problem on MK02/04-based bootloader boards.
Click to expand...

The new bootloader always disables the NMI feature in the flash config byte immediately after erasing the flash. Writing to flash only changes 1s into 0s, so there's no way to re-enable NMI by normal loading of programs. The new KL02/04 chip also has code to turn NMI off before running the bootloader, while the CPU core is still being held in reset. So the bootloader should be able to run in all cases, even if you've wired pin 33 low.

However, with a completely blank MK20 chip that's never been programmed, NMI is still enabled. Of course, the flash is filled with 0xFFFFFFFF on a brand new MK20 chip, so the ARM core will fault on the first instruction, regardless of whether it's executed due to the reset vector or NMI vector, so it really doesn't matter if NMI is enabled or not. But on a chip which the bootloader hasn't programmed, NMI will be enabled by default.

Likewise, if your program erases the memory at 0x0000040C, and then the chip goes through a hardware reset, the NMI can become re-enabled. If you enable NMI and drive that pin low (it always floats to high, since it has an always-on pullup), your code will run the NMI exception. Unless you've very carefully written a working NMI function, your program will crash.

But on working hardware, the new bootloader is able to recover from this circumstance and restore you to a proper NMI disabled state.

Obviously this DIY hardware isn't working, since PTA4 is low and the reset pin is stuck high. There's nothing the bootloader can do if the hardware isn't built correctly!
 
Chip definitely right way round as 5v going in and 3.3v coming out.

But i have grounded the PTA4 port ooops. Would these cause the reset line to just stay high?

I will try and lift it tomorrow. Least i have a starting point!

Thanks guys

Regards
Russell
 
UPDATE:

@PAUL might want to add this to your custom board page for mistakes to look out for!

As @Constantin pointed out I had grounded PTA4 which is used to selected the boot mode at start up. Cutting a trace fixed the problem and now the micro-controller boots up and runs Pauls boot loader and I am able to program it YAY!

Reason I did this is because I wanted a tiny bit of firmware security and just grounded a "random" pin for it to check when it boots. SODS LAW I picked the one pin that was actually very important! I really should of read the boot sequence section of the user manual before designing this board. In all schematics I have looked at this pin is left floating I just assumed it was unused by the designer I have not seen any thing mention how important it is. (until now) Lesson learned! Before you go ground "random" IO make sure its NOT used for the boot process.

Any way thanks for all your help :)
Looks like the crystal part works just fine :)

Thanks for all your help PROBLEM SOLVED

Regards
Russell
 
Status
Not open for further replies.
Back
Top