The crystal with load capacitors for MK20DX256VMC10 does not work.

[zhangyoubao]

We copy the Trinamic's Landungsbruecke(attached Landungsbruecke_v12_01_Schematic.pdf) for our customized design(attached OurCustomizedDesignForMK20DX256VMC10.pdf).

When powered on, the crystal on Trinamic's board works properly, and we can see the oscillating wave.

However, for our customized board, when powered on, the crystal does not work. there is no oscillating wave on EXTAL0 pin.

The schematic is almost the same, and the difference is that: the chip on Trinamic's board is MK20DX256VLL10(100 LQFP package), and the chip on our customized board is MK20DX256VMC10(121 MAPBGA package).

We verified that:

1. Our crystal is OK. We put our crystal on Trinamic's board, and it works properly;

2. The voltages (3.3V and 5V ) are OK. We think that we powered the ARM chip correctly;

3. We tried different load capacitor for the crystal (The crystal requires 8pF load capacitor, we tried 10pF and 15pF, respectively), no work;

4. We have carefully checked our schematic and PCB layout.

Any ideas are appreciated.

[zhangyoubao]

@myke_predko Hi myke, finally, we've got through the unworkable crystal issue. It is the Trinamic's bootloader or TMC-EvalSystem program does not support the chip MK20DX256VMC10 directly. Since the bootloader is not open source, we use NOBL(no bootloader) option to compile the TMC-EvalSystem program. For the source, a few modifications (mainly related to the flash and SRAM address) are needed to make the chip work. The solution can be found at the website MK20DX256VLL10 chip.

For the reset circuit, the voltage monitor chip APX803S-31SA-7 (open drain) you recommended works perfectly. However, MAX809STRG (push-pull) does not work (we've expect it should be workable). There is a description in the K20's specification. we don't know the reason yet.

For the EZP_CS_b PIN, the chip can be programmed when we leave EZP_CS_b floating. Before, we've always connected EZP_CS_b to +3V3 for programming. So, for next revision, we will leave EZP_CS_b floating as you highly recommended, and we will also make it possible to connect to +3V3 through a 0ohm resistor.

Finally, we've got the chip work like a charm. Thank you very much, myke. Thank you for your kindly help.

[myke_predko]

@zhangyoubao 

That's great news!  I'm glad you're moving forwards.  

As to the MAX809STRG, I've worndered about the active drive output at Vcc * 0.8 and how it would work with the K20's !RESET pin.  I tend to always drive !RESET pins with an open collector/drive output as it allows multiple drivers on the bus (voltage monitors, buttons, programmers primarily) without worrying about contention.  

Good luck on your software - I thought there's a K20 bootloader that you can use available from NXP.  Have you looked around for something that you can use?  

Keep up the good work and let me know how things are going,

myke

[zhangyoubao]

@myke_predko thank you myke.

At present, we do not need the bootloader any more, for we could use Trinamic's code with NOBL option.

For the voltage monitor, we would keep use APX803S-31SA-7.

Youbao

[zhangyoubao]

@myke_predko 

Hi myke,

We've redesigned the board, and corrected the footprint of MK20DX256VMC10. Now,

1. The bootloader program can be downloaded into the chip through SWD;

2. The RESET signal is normal(OK) with only 100nF capacitor (one side is connected to uC's RESET pin, the other side to GND); The reset chip MAX809STRG does not work as expected, but it is not the main problem at present, and we can leave it later to investigate.

Our main issue is that the crystal(PN: FC3BACBDI16.0-T3) is still not working. So, although the bootloader program is downloaded into the chip, the CPU refuse to run without the working crystal. For the load capacitor of the crystal, the recommend value is 8 pF. We have also tried 10 pF and 15 pF, no success. 

The schematic for MCU part is attached to this message.

Do you have any ideas?

Thanks.

Youbao

[myke_predko]

Hi @zhangyoubao 

That's good news that you're moving forwards.  

As to the crystal, what are the parameters you're using for it?  I'm asking about the "OSC Mode" and "Frequency Range" specifically.  

I've found that the values required to get the crystal oscillating is not always what you expect.  

Just out of curiosity, can you get the crystal to oscillate when you put a 'scope probe to it?  That can be a clue as to the problem.  

myke

[zhangyoubao]

We use a 16MHz crystal, and the part number is FC3BACBDI16.0-T3. The load capacitor for it is 8 pF.

By the  "OSC Mode", it should be "High frequency" and "low power". According to the official reference manual, the Rf should not be used for the "low power" mode, which is also the Trinamic's way. 

We've tried to probe the crystal's output pin (PIN 3) with the scope to see what happens when we power on the board, and the signal is always flat (actually 0V).

We think our schematic is correct this time, but it is actually not working. 

Youbao

[myke_predko]

@zhangyoubao 

All this must be frustrating.  

So, the approach I would be taking at this point would be:

1. Pull Reset Up High (I'd use a 100k Pull up) to ensure that it is correct.  Maybe you're device isn't coming out of reset and that's why the clock isn't starting.  
     - I wouldn't recommend using the MAX809STRG for your voltage supervisor.  The output should be Open Drain, not Push/Pull and the Vth is lower than I would recommend (Personally, I use the APX803S-31SA-7 which has a Vth of 3.15V and is Open Drain Output).  

2. Turn off the internal capaitances to the MK20

3. Check the Pin Muxes for K11/L11 and make sure they're directed towards the XTAL/EXTAL functions in your clock/pin initialization methods.  

4. Put 1M load resistor across the Crystal terminals

5. Try another crystal.  This is both:
     - The same part number
     - A different part number

You haven't shared any PCB design details; I presume the Crystal is located as close as possible to the MK20's crystal pins and directly connected ot the ground plane?  Along with that, have you checked the impedance of your lines?

Good luck,

myke

[zhangyoubao]

Hi myke,

According to your suggestions, we've done the following test:

1. Pull Reset Up High with a 100k pull up resistor to ensure that it is correct. We've monitored the reset signal, and we think it is OK. No success.

2. Put 1M load resistor across the Crystal terminals. No success.

3. Try another crystal. For this, we've actually solder 3 boards. It is equivalent to try another crystal(the same part number). We just do not have crystals with different part number. No success.

We've double checked our schematic and PCB layout, and found no errors. We think that everything is fine, but the crystal just refuse to work. At present, we have no clues for the problem.

To provide more information, we've shared a few files attached to this message.

Youbao

[myke_predko]

Hi @zhangyoubao 

Layout looks good.  I'm assuming that you have a full PCB ground plane (it's not obvious in the images/pdfs) but things look good.  

So, you still have two things to check over:

1. Verified that the Pin Muxes are set correctly for the XTAL0/EXTAL0 functionality.  I know this is the default but something could be happening in software.  

2. What happens when you substitute in a different crystal of the same speed.  Maybe I wasn't clear enough in my previous email, but I would suggest you find a 16MHz PTH part and solder the leads to see if there's an issue with the crystal you've selected.  

One note 1., are you able to single step through your application?  You should be booting with the internal clock and then the external one is enabled - If all is well, then you will return from the BOARD_InitBootClocks method without any issued.  If there is a clock issue, the code will be stuck in a loop waiting for the clock to stabilize.  

Good luck,

myke

[myke_predko]

zhangyoubao@siom.ac.cn‌,

Before I make any suggestions, can I ask a few questions in regards to how the K20 chip you're using is programmed?  

1. How are you programming the chip that you are using?  Based on the schematic, it looks like the chip needs to be pre-programmed before it can run in the circuit.  
   1. There's not a lot of detail on the Landungsbruecke page but it seems that its MK20 is loaded with a bootloader before it is soldered to the board and application code is burned into the K20 using the USB port.  
2. I'm asking question 1. because the JTAG TDI & TDO pins are controlling LEDs and...
3. How is EZP_CS_b supposed to work?  Tying it the voltage divider will drive 4.0V to the pin (which is out of spec) and driving it generally causes problems during boot unless you know exactly what you're doing (and willing to face the consequences of that action) - I always recommend that EZP_CS_b is left floating. 

Let me know the answer to question 1.  and if you can comment on the other two questions that would be helpful.  

myke

[zhangyoubao]

ANS 1:

To programm the Landungsbruecke board, the bootloader should be downloaded into the chip through SWD (SW_PROG_SWDIO and SW_PROG_SWCLK in the schematic), then the application code could be downloaded through the USB port with Trinamic's TMCL IDE. We just imitate the way of the Landungsbruecke board does.

ANS 2:

The JTAG's two pins (TDI & TDO) are used for controlling LEDs (For Trinamic's board), which used for indicating of board status.

ANS 3:

By the EZP_CS_b, we just follow Trinamic's schematic, and we do not know the exact reason why the PIN connects to USB's VBUS. I think it is for USB port programming.

We're not quite familiar with NXP's K series ARM chips, and we just follow Trinamic's design. However, we encounter problems during programming the chip.

Whatever, we think that the crystal should work when we power on our customized board.

Thanks for your help.

[myke_predko]

Hi zhangyoubao@siom.ac.cn‌,

How are you trying to program the MK20 and what are the problems that you are experiencing?  What programmer are you using (please provide links)?  

Have you read Production Flash Programming Best Practices for Kinetis K- and L-series MCUs?  I would point you to Table 2. (on Page 9) as it shows the pin requirements for programming the parts and I would suggest you note ALL the pins that are required for the different programming options.  I'm saying this because the _Reset pin is used (driven by the programmer) in all of the three options listed in the table and the Landungsbrücke and your boards are not making it available for programming - which lead me to the conclusion that the Landungsbrücke has a pre-programmed Kinetis soldered to board and why I'm asking you to explain exactly how you are programming the Kinetis.  

I don't believe the external clock will be enabled without the firmware specifying it's use so the Kinetis MUST be programmed first.  Let's get programming figured out and then move to the clocking.  

myke

[zhangyoubao]

Hi Myke,

For my experience on Landungsbrücke board, I've just downloaded the bootloader into the chip through SWD, and then I've programmed the chip through USB port. So far so good on Landungsbrücke board; However on our customized board, no way.

I've gotten the idea that maybe the Landungsbrücke has a pre-programmed Kinetis soldered to board, and I will contact Trinamic's technicians to confirm this.

For my logic, the crystal (external clock) should work first, then we could program the chip.

According to your explanation, the Kinetis MUST be programmed first, then the crystal may work properly. Is it correct for my understanding?

Thanks for your help.

Youbao

[myke_predko]

Hi zhangyoubao@siom.ac.cn‌,

I just did an experiment with one of my boards - I erased the Flash and saw that the clock is NOT running and then I programmed my application and the clock is running.  

Based on what I've seen elsewhere, I was 90% sure that there needed to be a program (that specifies clocking) loaded into the Kinetis before you would see the clock operate - now I'm 100% sure.  

So I'm very sure that when you talk to Trinamic you'll find out that their processors are pre-programmed before they are soldered to the PCB.  

The good news is that I think you can wire up a programming interface on your board (pull R5 & R6, put a pull up on _reset and run the JTAG lines to a programmer) which should take an hour or so.  

myke

[zhangyoubao]

Hi Myke,

We've confirmed with Trinamic's Enrico, who said that the ARM chip is not pre-programmed (Does the Landungsbrücke board have a pre-programmed Kinetis ARM chip (MK20DX256VLL10) soldered to th... ). They use SWD for programming the chip (see attached Landungsbruecke board image).

My workmate may help find the problem. We may make the incorrect footprint of MK20DX256VMC10. I attached our designed footprint and the footprint from ULTRALIBRIAN webside to this message.

Because of the incorrect footprint of MK20DX256VMC10, we have to redesign our PCB. Are there any suggestions for the redesign?

Thanks.

Youbao

[myke_predko]

zhangyoubao@siom.ac.cn‌,

You're going to have to hammer at Trinamic to get a straight answer on what's going on here.  The published documentation doesn't match what they're saying and Segger JFlash is a software program - it's not an actual physical programmer with wires going in and out of it.  

When I look at the schematics (version 1.2) that you posted in your original email "RESET_B" is simply tied to a cap to ground (very bad practice, BTW):

This didn't make sense so I went back to the Trinamic's website and the documents for the Landungsbruecke board, noticed that you had posted version 1.2 and there was version 2.0 files available and when I looked at the schematics, on the first page I saw the added note (look at the second bullet point):

I then looked at RESET_B on the version 2.0 schematics and lo and behold the reset line looks like it's going somewhere else:

But, I can't find any reference to this pad on the the programming pads in the schematic nor do I see anything referencing it on the bottom of the PCB.  If I look at the bottom PCB layer there looks like there are four programming pins on the bottom of the board that I guess are going here but I haven't seen any reference to it in the documentation I've read.  

So zhangyoubao@siom.ac.cn‌ I suggest you get back to Enrico and ask:

1. To explain what is the programming hardware they're using and what K20 pins they're connecting the hardware to.  Saying that it's "JFlash" isn't answering the question.  

2.  To explain the pads on the backside of the PCB and which pins they are.  I'd also be interested in how they are connected when the board is initially programmed as I would suspect they have a custom fixture for doing the intiial programming - In your case you'll need to add a connector that will work with the programmer.  

  2.1.  Explain exactly how their board is wired duing programming.  That includes power (if not through "CON_SWD") along with what's happening with reset as well as whether or not the USB cable is plugged into something (and if it is, what is it)?  

myke

[zhangyoubao]

Hi, Myke,

According to Trinamic's information, I think we can just copy Landungsbruecke's schematic, and follow Trinamic's programming approach.

Do you have any improving suggestions?

Thanks.

Youbao

[myke_predko]

Hi zhangyoubao@siom.ac.cn‌,

Man, getting that information was like pulling teeth.  I guess if you're not going to buy a bunch of Trinamac's boards, they're really not going to help you.  For an "Open source" company, they have a lot of information that's not available.  

With the Segger Interface Description link, I would say that you have enough.  But, I would I would probably suggest that you use a full JTAG programming interface which means:

• You'll have to reallocate the two LEDs to other pins.  This will require a minor Trinamac Bootloader source code change but as, I believe, that you're using a part with more IO, this shouldn't be an issue.
• You'll have to add a JTAG connector to your board.  
  • Can I suggest using the Segger J-Link Needle Adapter?  This is built into the PCB (and you're respinning it anyway) and does not require any hardware.  I've been using it for a few years now and I really like it.  
• I would recommend putting a pull up and voltage supervisor on _Reset.  Costs a bit more than a chip cap but it buys you a lot of peace of mind.  
• Leave EZP_CS_p (aka PTA4) floating.  I don't like the way Trinamac drives it from VBUS ("V_USB" on their schematics) through a voltage divider (which provides 4V which is higher than VDD's 3.3V which is bad practice).  If you feel you need to drive EZP_CS_b high or low, put in pads for a Zero Ohm resistor to tie the line to Vdd or Vss.  
  • I think the purpose of the voltage divider on EZP_CS_b (PTA4) is for a USB detect - if this function is still required, then add a voltage divider (which produces a max of 3.3V) to VBUS and put this on another input pin.  

Here is the programming/reset circuit that I'm currently working with (just to show you that I put my money where my mouth is):

Let me know if you have any other questions,

myke

[zhangyoubao]

Hi Myke,

I will follow your recommendation for the _Reset connections. 

But a full JTAG programming interface would take a comparative space on the quite compact board. Following are the front side and the back side of my board. I would use the SWD approach for programming this time, and I will take your suggestion for my next board design.

Thank you for your continuously patiently coaching!

Best regards,

Youbao

[myke_predko]

zhangyoubao@siom.ac.cn‌,

I was just thinking about my final post above (which I've modified to make it more complete) and wanted to note that I'm not sure I'm happy with what Trinamac does with EXP_CS_b - I highly recommend that you don't connect it to EZP_CS_b to VBUS (labeled "V_USB" on their schematic) in any way, through a voltage divider or whatever.  

Instead, leave EZP_CS_b floating.  

myke