help with pre-programmed MINI54 setup

Status
Not open for further replies.
S

scottmahr

Member
Hey everyone,

First off, Teensy is great. After getting stuck on Arduino's limitations I switched to Teensy for a project I have been working on. I prototyped with the 3.1, then designed a board that had a socket for the 3.1. I have ten of those boards that are working great. My next step is to use a raw MK20DX128VLH5 on my board while using one of Paul's MINI54 chips to program it. I assembled my board for the first time last night. When I had everything connected, I plugged it in to usb and nothing happened. I had expected it to be found by my computer as a usb device. I plugged a Teensy 3.1 in with the same cable and it was quickly recognized. I made sure that the power to the chip looked good, it was fine. I pushed the reset button connected to the MINI54 and nothing happened.

I have attached my schematics in case anyone has time to check them out and find my errors. I have tried to copy this schematic as well as I could. I also tried to follow the instructions on this page to the letter. I couldn't find a definitive BOM, so I made my best guesses on some components. If we can get this figured out I will post the eagle files and BOM for other people who want to do something similar.

I have two boards that connect to each other over a 10 pin header. When they are connected I hope to be able to program the MK20. Both boards and the BOM is shown below.

Thanks in advance for any ideas on what to do next,

Scott


Some ideas I have:
1. I am using a layout from this post I assume that it is good, but I should probably check it out.
2. From that same forum, it sounds like I should put together another MINI54 board and see if it works.
 

Attachments

  • BOMv3.pdf
    34.8 KB · Views: 707
  • FormLiftingV3.pdf
    24.2 KB · Views: 789
  • MINI54.PNG
    MINI54.PNG
    26.1 KB · Views: 830
Quick update, I found one issue in my MINI54 board. My PTB2 and PTB3 nets should be connected to my SCL and SDA nets. Damn. Will report back when I fix that.
 
Ok, this still isn't working for me. I tested the first board using what Paul said in the other thread, it was broken. I very carefully assembled another one, and it passed the tests. I connected power, but not the mk20, checked both reset and prog, both were 3.3, great. I then pressed the reset button, that pulled prog low, and reset also responded by going low. I then plugged in the blank mk20 and powered it up. Like Paul suggested, I saw a small voltage on reset. I plugged it into my computer and it still doesn't recognize. I pushed the reset button, nothing happens. I also tried holding the reset button while plugging it in, nothing happens.

Is there any other troubleshooting I can do to see what is going on?

Thanks,

Scott
 
It's a little hard to parse your first schematic, mainly because I have no idea how your little connector or whatever it is actually interfaces to the MK20. What is it? From the other schematic, I can't quite tell what that MO5X2PTH is, either. Is it actually an MK20, or is it something else? I don't think there's a PTH version of the MK20 line, so I'm a little confused as to what you're 'plugging' in, too.
 
Ohh, wait, I get it now (I think). You're trying to build a Mini54 programmer board, basically? So that odd socket thing is a cable or just a socket for you to plug an MK20 into. Give me a few to look over this some more.
 
What's RTS? Is that, perchance, held to ground during initial power-on? Because that's on pin 33, which is a big no-no pin, currently. Holding pin33 to ground during boot up will force the MK20 into some sort of programming mode, which Teensy and the MINI54 don't use at all - it'll just act completely unresponsive. See: http://forum.pjrc.com/threads/24823-Teensy-3-1-Tying-Pin-33-(pta4)-low-freezes-teensy

Also, any reason for using an oscillator instead of a crystal? I can't think of any reason why that wouldn't work (maybe someone else can), I'm just curious.
 
Last edited:
Hey MuShoo, thanks a bunch for taking a look. Yes, the 5x2 pin is just a cable between the two boards. My intention is that when I connect the Mini54 board to the main board they will look like a Teensy and will be able to be programmed as one. I think the part I am using is a crystal, here is the digikey part. RTS is from my Bluetooth chip, it could very possibly be pulled low. I will cut that trace and see if it helps, thanks!

Scott
 
The schematic looks like something that was cobbled together by taking elements from various projects out there and throwing them on a single page. For example, you mention wanting to use the MK20DX256 chip found in the Teensy 3.1 MCU, but the drawing shows a MK20DX128. For sure, the pinouts the same, except for the DAC output only found on the MK20DX256, but the connections are sloppy and the layout confusing.

For example, you're showing a oscillator on the schematic but you're using a standard crystal. The bypassed inductor to the left of the crystal is also bizarre. If pin 26 on the Teensy MCU is kept pulled low during programming, then the unit will not allow itself to be programmed. You have plenty of other pins to play with, switch the signal to a different one. Did you mean to tie CTS and RTS on the bluetooth module together? Seems to me, those signals should be separate. Etc.

Lastly, I'm not a fan of any attempts to bypass what should be due to Paul (i.e. royalties for the Mini54 chip).
 
You are totally right that the schematic was cobbled together from multiple other projects. I am not an electronics person and that seemed like the safest way to make it all work (because I had tested all those circuits in my prototype).

All the info I found for the chip layouts were from this forum. I didn't realize that I had the DX128 instead of the DX256, I bet that does make it confusing.

I am also pretty new to using Eagle. I used sparkfun boards for all of my prototyping, and their libraries for all my parts. The closest thing I could find to the crystal layout was that of an oscillator they had. I probably should have learned how to make a new part, but I didn't spend the time to do that.

The datasheet on the bluetooth module says that if you aren't using hardware based flow control you should short the RTS and the CTS together.

That ferrite does look pretty odd. I was trying to mimic the ferrite on the teensy that connects the case of the usb connector to ground. I thought the connector was also supposed to be grounded itself, which leads to the bypassed ferrite I have. It is very possible that renders the ferrite useless, but I don't know enough to take it out.

I chose pin 26 simply because it made the most sense for my layout; I didn't know about its other uses. I really hope that is the issue I have. I will swap it to some other pin in the future.

I hope that I am not taking advantage of Paul's work, because that really wasn't my intention. I have purchased quite a few Teensy's from him already, I have also purchased all the Mini54's I am using from him. I will need to make quite a few programmer boards once I get them working (which means more Mini54s). I saw that there were at least a few other people who took this approach, and it seemed like a good one. This way Paul gets significantly more royalties than if I had taken the step and used JTAG to program the MK20s (which will take much more learning on my part).


Thanks for all the input. Before I ask for help again I will make sure to put more work into my schematic to make sure that it is more readable and correct.

Scott
 
I cut that trace to pin 26 and nothing changed. I think my best next plan is to make another board and see if it works. I will also try to clean up my schematic with the best libraries I can find and make sure nothing changes.
 
OK, I am stuck now. Fearing that I had cooked the MK20 I made another main board. Didn't have to do any rework after reflowing so I feel pretty confident the new mk20 is fine. I have also cut all traces to any external components to make sure they aren't causing issues. I have made very sure that my usb connections are correct. The only difference I can find with my schematic and Constantin's on this page is that he connects VCC directly to Pin 7 (VOUT33), while I have mine conencted to pin 8 (VREGIN). When I look at my VOUT33 I have 3.27v. I think Constantin's way is probably better, but it doesn't seem like it should really make a difference. I have attached the schematic of only the parts of the circuit that is still connected.

I realize I am not positive how this is supposed to work. The usb data lines are only connected to the MK20, so the Mini54 never communicates directly. I would assume that when the program button connected to the Mini54 is pressed, the Mini54 programs the MK20 with the code to initialize as an usb device to the computer. Is this right? Once that happens, the MK20 has enough of the code to talk with the teensyduino down loader. Does that mean that I should be able to watch some of the connections between the Mini54 and see that programming taking place? Is there an order of powering things up, pressing the program button and plugging in the usb to the computer to give me the best chance of having this work?

Any help is much appreciated.

Thanks,

Scott


Boards Schematics.jpg
 
Last edited:
Your assumptions are correct. When you press the Prog button the Mini54 will reset the MK20, this is the first point to check that the reset line is pulled. Then the Mini54 will program the MK20 with the bootloader, So over PTA0-PTA3 you should see a load of data going, PTA0 should be something like a Clock signal, PTA1 a data IN.

If you see those then check to see if the MK20 has brought up the crystal. Is it oscillating at 16Mhz.

Check that you have everything connected to USB port and that you don't have any dryjoints or shorts. Also check to see if your PC has actually seen the devices but is now in the Unknown Devices instead of prompting you for a driver.
 
scottmahr said:
he connects VCC directly to Pin 7 (VOUT33), while I have mine conencted to pin 8 (VREGIN). When I look at my VOUT33 I have 3.27v. I think Constantin's way is probably better, but it doesn't seem like it should really make a difference. I have attached the schematic of only the parts of the circuit that is still connected.
Click to expand...

I'm on my phone now so I may have missed it, but I'm not sure where you're getting your 3.3V power supply. On the Teensy 3.x board the 5V from USB connects to VREGIN and VOUT33 drives the rest of the 3.3V power lines (MK20's VDD pins etc.).

In my designs I've used a dedicated 3.3V voltage regulator and it feeds directly into VOUT33 and VDD, and VREGIN isn't connected at all. I'm not sure connecting 3.3V into VREGIN and VOUT33 is a good idea.
 
scottmahr said:
...The only difference I can find with my schematic and Constantin's on this page is that he connects VCC directly to Pin 7 (VOUT33), while I have mine conencted to pin 8 (VREGIN). When I look at my VOUT33 I have 3.27v. I think Constantin's way is probably better, but it doesn't seem like it should really make a difference. I have attached the schematic of only the parts of the circuit that is still connected.
Click to expand...

Your latest schematic is confusing at the moment. You have a 5V coming in on the USB, but none of the connection names on the MK20 pins match that. There are a couple of connectors that are labeled with VCC connections but they go into VREGIN. The connection coming out of Vout3v3 is not labeled. If it's VCC, then you are feeding the front and back of a voltage regulator the same voltage. Seems like a recipe for trouble.

Where is the power for VCC coming from? If it's external, then leave VREGIN alone and only connect the 3.3V to the VCC pins and the Vout3v3 to get USB to work. I'm not sure what would happen if you connect 3.3V to the VREGIN pin (and hence causing the VR inside the MK20 to drop out, at best) but I wouldn't do it. That pin deserves something north of 3.7V if you're trying to hit 3.3V on the output side.

Here is a statement from inside the reference manual that I found interesting:
When USB is not used in the application, it is recommended that the USB regulator VREGIN and VOUT33 pins remain floating.
Click to expand...

In other words, VUSB should be connected to VREGIN, and per the manual Vout3v3 deserves a dedicated 2.2uF capacitor. Whether or not to connect anything else to Vout3v3 is left to the designer, I guess. Note also the option in the reference manual to be running the chip at 1.8V VCC while USB 5V powers the USB portion of the chip at 3.3V via VREG+VOUT.
 
Last edited:
Constantin, I have a step up regulator that provides 3.3 volts to everything on my board from a lipo. I left out the charging circuit and the regulator to try to keep it simple.

I just moved my 3.3v supply to VCC and Vout3v3, VREGIN isn't connected to anything.

Here is what happens when I press the reset button:
Reset: .1v --> 0v (quickly) --> 3.3v
PTA0: 0v --> .88v
PTA1: 3.3v --> 3.3v
PTA2: .1v --> 0v
PTA3: 0v --> .76v



I don't have an oscilloscope at home, but I can look at the signals on those pins on Tuesday.

Scott
 
If you supply 3.3v to VREGIN the internal regulator goes into bypass mode and just output 3.3v on vout. Now there is a bit of confusion about VREGIN being connected or not to supply power to the usb module in the MK20. I've had troubles when I left this floating and just had 3.3v going to Vout while othe people have had no issues. Also I hate supplying the output of a regulator and not the input as I've blow up many a regulator doing that, so unless the MK20 has built in protection for that, I personally would just leave 3.3v to VREGIN and let it go bypass. This then also guarantees that all the other internal circuits are powered including the USB module.

Another thing to check is make sure your USB DP,DM connections are the right way round or the part you used from the eagle library is correct.
 
Good points, I also originally left Vout3v3 unconnected when I did my first MK20 board because of VR backfeeding concerns. Then, I got to hand solder a connection from VCC to that pin (fun!) in order to enable USB. The chips seem to work with an unconnected VREGIN but if adding a connection to VREGIN adds to the stability, I'm all for it. I'll have a look at the manual. There may be a clue there. :-D
 
Anecdotal evidence: I've never done a design with the Teensy 3.1's MK20DX256 but I just counted and have done five different circuits with the MK20DX128 using an external 3.3V regulator and have always left VREGIN floating with no issues. The latest 4 designs use Constantin's Eagle library for the parts, and all use USB and the PJRC Mini54 for programming, serial debugging, etc.

I have read the datasheets and don't really see anything past "When USB is not used in the application, it is recommended that the USB regulator VREGIN and VOUT33 pins remain floating." I am currently looking through the Freescale release notes and quick start guides to see if I can find something definitive. Nothing yet but I will post back if I find something concrete.
 
"When USB is not used in the application, it is recommended that the USB regulator VREGIN and VOUT33 pins remain floating."
Click to expand...

You see that to me would sugguest that both VREGIN and VOUT33 have to be connected if you want USB to work, Which you do if you want to program the MK20 using the Mini54 and teensyloader. But does it really matter to leave it floating if the reg goes into bypass mode anyway? Possibly time to experiment and see what the implications are in terms of power usage with it connected and not.
 
All my designs have used mains power via either ubiquitous 5V/USB adapters into something like a LD1117 that drives the chips or an adapter that converts mains directly to 3.3V so I can't speak to the power usage, but I can say I haven't had any problems with USB programming when leaving VREGIN floating. Again, this is anecdotal evidence...I'm still looking for something definitive.
 
I would really like to avoid the need for attaching VREGIN to the USB bus. My daughter-boards currently do not feature a dedicated VUSB connector/pin - instead VUSB feeds into a common raw power bus via a Schottky diode, just like all other power sources. In the meantime, I've attached VREGIN to the 3.3V bus in case that's better for the regulator than my current backfeeding habit.
 
Hey guys, thanks for all the help, it seems to be working now. It seemed like I had burned up my first MK20. When I sat down to look at my second one with an oscilloscope yesterday it was working.

I do have another question. Before a MK20 is programmed for the first time, will it start up the crystal?

Scott
 
scottmahr said:
I do have another question. Before a MK20 is programmed for the first time, will it start up the crystal?
Click to expand...

No. The crystal oscillator, like almost everything in the chip, is disabled by default. Freescale designed the chip so you can use it for low power applications, so pretty much everything that uses nearly any power has to be enabled.
 
Status
Not open for further replies.
Back
Top