hip9011 - crystal issue
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
hip9011 - crystal issue
Some kind of electrical voodoo? I am sure it's not about a bad joint - I re-did them
[video][/video]
[video][/video]
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: hip9011 integration
XTAL circuits are a TANK circuit which oscillates between the XTAL and those small pF caps. A TANK circuit needs an initial ping or oscillation to get it started. Then it resonates at the TANK circuits natural frequency. As a side note, you can warp your 4.000000MHz signal by changing the caps, as the caps will change the resonate frequency slightly. Typically your chip will wait until the + V has gotten reasonably high, then it will turn on the XTAL. This initial transition is usually enough of a ping to get the circuit to resonate. However it appears in your case it is not enough.
I believe that when you touch it with the wire, you are creating a very small upset in capacitance, or very small ESD on the GND of the XTAL can, which appears to be enough of an upset to get the XTAL to resonate. The 1Mohm resistor R166 seems a bit odd to me, as you may have noticed this resistor is not commonly installed on MCU XTAL's. That resistor makes it harder for the XTAL to start oscillation. The datasheet notes that resistor can be between 1Mohm and 10Mohm. Do you have a higher Mohm you can put in there?
Also is C165 populated? If so can you add a smaller pF on top if it? It's possible that the .1uF cap is not working well enough at the 4MHz frequency and could be causing the XTAL to stall on that initial ping. The pF caps are better about providing high frequency energy.
I believe that when you touch it with the wire, you are creating a very small upset in capacitance, or very small ESD on the GND of the XTAL can, which appears to be enough of an upset to get the XTAL to resonate. The 1Mohm resistor R166 seems a bit odd to me, as you may have noticed this resistor is not commonly installed on MCU XTAL's. That resistor makes it harder for the XTAL to start oscillation. The datasheet notes that resistor can be between 1Mohm and 10Mohm. Do you have a higher Mohm you can put in there?
Also is C165 populated? If so can you add a smaller pF on top if it? It's possible that the .1uF cap is not working well enough at the 4MHz frequency and could be causing the XTAL to stall on that initial ping. The pF caps are better about providing high frequency energy.
Welcome to the friendlier side of internet crazy
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: hip9011 integration
Yes C165 is populated. What value should I try putting above C165?kb1gtt wrote:The 1Mohm resistor R166 seems a bit odd to me, as you may have noticed this resistor is not commonly installed on MCU XTAL's. That resistor makes it harder for the XTAL to start oscillation. The datasheet notes that resistor can be between 1Mohm and 10Mohm. Do you have a higher Mohm you can put in there?
Also is C165 populated? If so can you add a smaller pF on top if it? It's possible that the .1uF cap is not working well enough at the 4MHz frequency and could be causing the XTAL to stall on that initial ping. The pF caps are better about providing high frequency energy.
I have 3.3M and 10M in front of me. Which one should I try for R166? I can start with 3.3M
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: hip9011 integration
Just swapped R166 for a 3.3Mrussian wrote:I have 3.3M and 10M in front of me. Which one should I try for R166? I can start with 3.3M
Same exact behavior - nothing until I touch it.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: hip9011 integration
Try the 10 meg
Any pF would probably be fine. Perhaps you have some extras of those 18pF used for the XTAL. Can you post a picture of this part of the PCB?
Any pF would probably be fine. Perhaps you have some extras of those 18pF used for the XTAL. Can you post a picture of this part of the PCB?
Welcome to the friendlier side of internet crazy
Re: hip9011 integration
Welcome to the world of crystal oscillators, where almost nobody seems to know and/or understand how these things work.
Luckily most of the crystal oscillator application have rather mild frequency accuracy requirements, so usually when the thing oscillates it is OK.
At my day to day job I need to have 40 ppm accuracy in all conditions (Wireless transceiver) so I have seen all the pitfalls. I am still not a crystal expect, but let me see if I can be of help.
You hit the most nasty problem with a crystal oscillator: start-up issues.
Many reasons for this, but best to start with the load capacitance.
You need to select the right load capacitors, if there is too much load capacitance this can easily lead to the crystal not starting.
Do you have the datasheet of the used crystal?
This is the most import thing to do:
Lowering the load capacitance will make the oscillator easier to start, but it will cause frequency offset. For this application you do not need to worry about frequency offset (I can calculate the error, but I think it is irrelevant for this application).
Nice application note with some handles of solving crystal oscillator problems (and contains the quote from the section above):
http://www.freescale.com/files/microcontrollers/doc/app_note/AN3208.pdf
First I would start with checking the load capacitance, as it is most likely the culprit of the problem
Edit:
Found another application note explaining the circuit a little better:
http://www.st.com/web/en/resource/technical/document/application_note/CD00221665.pdf
Funny they assumed exactly the same value for stray capacitance I had in my head
Luckily most of the crystal oscillator application have rather mild frequency accuracy requirements, so usually when the thing oscillates it is OK.
At my day to day job I need to have 40 ppm accuracy in all conditions (Wireless transceiver) so I have seen all the pitfalls. I am still not a crystal expect, but let me see if I can be of help.
You hit the most nasty problem with a crystal oscillator: start-up issues.
Many reasons for this, but best to start with the load capacitance.
You need to select the right load capacitors, if there is too much load capacitance this can easily lead to the crystal not starting.
Do you have the datasheet of the used crystal?
This is the most import thing to do:
Assume a stray capacitance of around 5pF per pin, but it can be more with certain PCB layouts.The series combination of C1 and C2: (C1*C2) / (C1+C2), should give a value close to the load
capacitance, CL, specified by the crystal manufacturer. Be sure to consider stray capacitances when
performing this calculation.
Lowering the load capacitance will make the oscillator easier to start, but it will cause frequency offset. For this application you do not need to worry about frequency offset (I can calculate the error, but I think it is irrelevant for this application).
Nice application note with some handles of solving crystal oscillator problems (and contains the quote from the section above):
http://www.freescale.com/files/microcontrollers/doc/app_note/AN3208.pdf
First I would start with checking the load capacitance, as it is most likely the culprit of the problem
Edit:
Found another application note explaining the circuit a little better:
http://www.st.com/web/en/resource/technical/document/application_note/CD00221665.pdf
Funny they assumed exactly the same value for stray capacitance I had in my head
Re: hip9011 integration
XTAL is http://www.digikey.com/product-detail/en/FOXSDLF%2F040/631-1005-1-ND/1024710 it's datasheet specifies 20pF for CL
Using 18pF caps http://www.digikey.com/product-detail/en/GRM21A5C2E180JW01D/490-5533-1-ND/2334929
The HIP9011 datasheet suggest pierce configuration using 20pF, the 18pF assumes about 2pF in the PCB layout. In this case the XTAL is a little bit away from the chip, so perhaps it's as high as 5pF.
Per the example found here http://www.adafruit.com/blog/2012/01/24/choosing-the-right-crystal-and-caps-for-your-design/
The 18pf with 2pF stray we get (18*18)/(18+18)+2 = 11pF
Then with 5pF stray we get 14pF
Both are reasonably close to the 20pF CL.
for estimating PCB impedance I tend to like http://www.saturnpcb.com/pcb_toolkit.htm I followed typical routing rules, short-ish traces no vias, ect. I guess I could better predict the pF's but I doubt this is really an issue here. I expect the pF variations will change the PPM but we don't really care if we have a tight PPM on this component.
Using 18pF caps http://www.digikey.com/product-detail/en/GRM21A5C2E180JW01D/490-5533-1-ND/2334929
The HIP9011 datasheet suggest pierce configuration using 20pF, the 18pF assumes about 2pF in the PCB layout. In this case the XTAL is a little bit away from the chip, so perhaps it's as high as 5pF.
Per the example found here http://www.adafruit.com/blog/2012/01/24/choosing-the-right-crystal-and-caps-for-your-design/
The 18pf with 2pF stray we get (18*18)/(18+18)+2 = 11pF
Then with 5pF stray we get 14pF
Both are reasonably close to the 20pF CL.
for estimating PCB impedance I tend to like http://www.saturnpcb.com/pcb_toolkit.htm I followed typical routing rules, short-ish traces no vias, ect. I guess I could better predict the pF's but I doubt this is really an issue here. I expect the pF variations will change the PPM but we don't really care if we have a tight PPM on this component.
Welcome to the friendlier side of internet crazy
Re: hip9011 integration
Perhaps worth noting, the layout uses a slightly longer trace for what HIP9011 calls OSCIN, which I believe is the same as FS's EXTAL, which is connected to C1. Because of this I would expect slightly more pF's on C1. From FS linked above
Also to get the MFG suggested CL of 20pF, and assuming 5pF stray, you want 30pF caps. Do you happen to have something close to that pF? If you stack 2X tall those 18pF, you'd get a CL 23pF. Which is only off by +3pF. While the current 18pF caps are off by -6pF. Hmmm, what other caps might you have around.
If you add on top of the 18pF a C21 12pF you'd get a CL of 20pF. I would say try stacking the 12pF on top of the existing 18pF and see if that helps it out. C21 found at this link http://www.digikey.com/product-detail/en/08051A120JAT2A/478-5011-1-ND/1888222
Also we should consider ESD and heat cycling damage. Perhaps try replacing the caps. They might not be following design specs if they are damaged.
So I would expect the more pF's on C1 would make for stronger feedback, which would make it more friendly to starting.Since the feedback voltage is taken from the voltage divisor made up from C1 and the crystal, increasing C1 will result in stronger feedback, while reducing its value will result in weaker feedback. Insufficient feedback could prevent oscillation from starting or make oscillation difficult to sustain.
Also to get the MFG suggested CL of 20pF, and assuming 5pF stray, you want 30pF caps. Do you happen to have something close to that pF? If you stack 2X tall those 18pF, you'd get a CL 23pF. Which is only off by +3pF. While the current 18pF caps are off by -6pF. Hmmm, what other caps might you have around.
If you add on top of the 18pF a C21 12pF you'd get a CL of 20pF. I would say try stacking the 12pF on top of the existing 18pF and see if that helps it out. C21 found at this link http://www.digikey.com/product-detail/en/08051A120JAT2A/478-5011-1-ND/1888222
Also we should consider ESD and heat cycling damage. Perhaps try replacing the caps. They might not be following design specs if they are damaged.
Welcome to the friendlier side of internet crazy
Re: hip9011 integration
The knock chip power supply pin rise time when powered via 12V and 5V switcher regulator is about 10mS and when powered by USB 5V is 1mS. I would guess this could be a less than "sharp" power supply rise time. Perhaps it could contribute to the starting issues.
Blue trace is the 5V at pin 1, and yellow is oscout at pin 10. It seems to start reliably when the noise of the scope is connected. Which is very similar to how russian was touching the xtal case in the above video.
I measured C167 to be 23pF (meter is not accurate down this low, so it's probably 18pF), I was optimistic when I got way wrong measures for C166, but when I removed it from the board I was able to measure it to be 25pF, again meter is probably wrong. I re-installed the original cap, then added a 10pF on top, such that we should now have 28pF installed. It still fails to start.
Via SaturnPCB I predict less then 2pF of capacitance added by the traces. The SMT XTAL decreases the typical range of 2pF to 5pF noted in several on-line sources, as this design doesn't have any via's, while many designs have capacitance caused by a thru hold component.
Long term we really should test this at the highest temperature and lowest supply voltage, which lead to minimum loop gain and could result in a slow or no start-up. It’s also important to test at the coldest temperature and highest supply voltage, which lead to maximum loop gain and could overdrive and damage the crystal, force it to oscillate at an overtone or harmonic, or cause it to stop working. That's per FS http://www.freescale.com/files/microcontrollers/doc/app_note/AN3208.pdf
This is still elluding me. I wonder if the TPIC8101 is using a different internal amplifier setup than the HIP9011. Technically the board I'm working with has the TPIC8101 not the HIP9011.
Blue trace is the 5V at pin 1, and yellow is oscout at pin 10. It seems to start reliably when the noise of the scope is connected. Which is very similar to how russian was touching the xtal case in the above video.
I measured C167 to be 23pF (meter is not accurate down this low, so it's probably 18pF), I was optimistic when I got way wrong measures for C166, but when I removed it from the board I was able to measure it to be 25pF, again meter is probably wrong. I re-installed the original cap, then added a 10pF on top, such that we should now have 28pF installed. It still fails to start.
Via SaturnPCB I predict less then 2pF of capacitance added by the traces. The SMT XTAL decreases the typical range of 2pF to 5pF noted in several on-line sources, as this design doesn't have any via's, while many designs have capacitance caused by a thru hold component.
Long term we really should test this at the highest temperature and lowest supply voltage, which lead to minimum loop gain and could result in a slow or no start-up. It’s also important to test at the coldest temperature and highest supply voltage, which lead to maximum loop gain and could overdrive and damage the crystal, force it to oscillate at an overtone or harmonic, or cause it to stop working. That's per FS http://www.freescale.com/files/microcontrollers/doc/app_note/AN3208.pdf
This is still elluding me. I wonder if the TPIC8101 is using a different internal amplifier setup than the HIP9011. Technically the board I'm working with has the TPIC8101 not the HIP9011.
Welcome to the friendlier side of internet crazy
Re: hip9011 integration
I did some more digging as I want to understand crystal oscillators fully.
If the load capacitance matches the crystal there are a few options left to make the crystal start quicker:
1. Select crystal with lower Rs
2. Try a higher value for the 1M feedback resistor (try 2M or something)
3. Try lower load capacitance (will cause some frequency offset, but accuracy will be OK for this application)
Another option would be to use the clock output of the STM32 (MCO pin), but I am not sure that GPIO is required for something else. Advantage is also lower BOM cost.
If the load capacitance matches the crystal there are a few options left to make the crystal start quicker:
1. Select crystal with lower Rs
2. Try a higher value for the 1M feedback resistor (try 2M or something)
3. Try lower load capacitance (will cause some frequency offset, but accuracy will be OK for this application)
Another option would be to use the clock output of the STM32 (MCO pin), but I am not sure that GPIO is required for something else. Advantage is also lower BOM cost.
Re: hip9011 integration
Thanks DaWaN for the reply's and for helping with this issue. It's much appreciated and you have helped me start kicking over the some rocks to look under.
From this forum post http://e2e.ti.com/support/data_converters/precision_data_converters/f/73/p/88765/313361 a fellow notes this PDF which is for a different chip, but does involve a TI crystal circuit http://e2e.ti.com/cfs-file/__key/telligent-evolution-components-attachments/00-73-01-00-00-30-76-28/SBAA123_5F00_Using_5F00_Crystal_5F00_Oscillators_5F00_with_5F00_MSC12xx.pdf
It notes in section 8.3 how to verify you have a proper XTAL's ESR and how to make sure it has the correct safety factor. That section also notes what you suggested about decreasing the caps.
I have found that with the 18pF caps and if I put scope probes on both sides of the XTAL, it doesn't start, AKA equal pF's added to each side of the XTAL. However if I probe just one side it starts as noted in the above pictures. Perhaps the in-balance in pF's is causing it to start, perhaps my probe is an antenna that allows some energy to give it the initial ping.
I have also removed the caps all together, which seems to start reliably. I then noticed that we were sending SPI as soon as it was starting, and that even with the XTAL starting reasonably fast, we were seeing the SPI before the XTAL was stable. So I got russian to add a 100mS delay to the SPI. It currently appears the SPI is stalling for some reason. I don't see the SCLK any more, and it appears the TPIC8101 is echoing the SPI as expected. At this point both russian and I don't know why the SPI is stalling. Perhaps when russian gets more than 10 minutes to look into it, something in software will jump out to him, however I'm a skeptic about this being a software problem. I suspect we are dealing with a hardware problem. I wonder if the TPIC is perhaps holding the clock low. I know that can be an option for SPI. Basically if the chip is backed up and needs some time, some chips can hold the clock low as a way to say slow down. Then when it releases the clock and the SPI master see's it has gone high, it then waits the amount of time, then pulls it low and continues clocking data on the stream. I wonder if that's happening here. I'm not sure how to figure out who is pulling the clock low. In the below, pink is SO on pin 11, Yellow is 5V power measured at pin 1, and blue is XTAL on pin 10.
So far in R0.4, I have added a 0R resistor which will allow us to measure Rq and ensure the SF is around 2 or better as noted in the TI's SBAA123. I have also changed the BOM to call for FOXSDLF/080R-20/TR which is an 8MHz part with an ESR of 80 while the current 4MHz XTAL has an ESR of 120.
I also couldn't help but notice the min XTAL is 4MHz with an range up to 24MHz. I see 4MHz XTAL's can be obtained with down around 30 ohm ESR's, I wonder if that means the 4MHz can technically work, but needs to be a special low ESR XTAL. I suspect that picking up off the min 4MHz to 8MHz will allow more common XTAL's to work.
I have included the trace pF's in my expectations, but I don't know the pF's of the TI chip. I wonder if TI has added around 20pF to the chip. I'm not sure how to measure this kind of pF's.
I hesitate to use the MCU to generate the clock, as the board wasn't laid out for long high MHz traces, and it would likely cause coupling issues. I want to keep the high frequencies on short leads if possible to prevent antennas that can cross couple into other circuits.
From this forum post http://e2e.ti.com/support/data_converters/precision_data_converters/f/73/p/88765/313361 a fellow notes this PDF which is for a different chip, but does involve a TI crystal circuit http://e2e.ti.com/cfs-file/__key/telligent-evolution-components-attachments/00-73-01-00-00-30-76-28/SBAA123_5F00_Using_5F00_Crystal_5F00_Oscillators_5F00_with_5F00_MSC12xx.pdf
It notes in section 8.3 how to verify you have a proper XTAL's ESR and how to make sure it has the correct safety factor. That section also notes what you suggested about decreasing the caps.
I have found that with the 18pF caps and if I put scope probes on both sides of the XTAL, it doesn't start, AKA equal pF's added to each side of the XTAL. However if I probe just one side it starts as noted in the above pictures. Perhaps the in-balance in pF's is causing it to start, perhaps my probe is an antenna that allows some energy to give it the initial ping.
I have also removed the caps all together, which seems to start reliably. I then noticed that we were sending SPI as soon as it was starting, and that even with the XTAL starting reasonably fast, we were seeing the SPI before the XTAL was stable. So I got russian to add a 100mS delay to the SPI. It currently appears the SPI is stalling for some reason. I don't see the SCLK any more, and it appears the TPIC8101 is echoing the SPI as expected. At this point both russian and I don't know why the SPI is stalling. Perhaps when russian gets more than 10 minutes to look into it, something in software will jump out to him, however I'm a skeptic about this being a software problem. I suspect we are dealing with a hardware problem. I wonder if the TPIC is perhaps holding the clock low. I know that can be an option for SPI. Basically if the chip is backed up and needs some time, some chips can hold the clock low as a way to say slow down. Then when it releases the clock and the SPI master see's it has gone high, it then waits the amount of time, then pulls it low and continues clocking data on the stream. I wonder if that's happening here. I'm not sure how to figure out who is pulling the clock low. In the below, pink is SO on pin 11, Yellow is 5V power measured at pin 1, and blue is XTAL on pin 10.
So far in R0.4, I have added a 0R resistor which will allow us to measure Rq and ensure the SF is around 2 or better as noted in the TI's SBAA123. I have also changed the BOM to call for FOXSDLF/080R-20/TR which is an 8MHz part with an ESR of 80 while the current 4MHz XTAL has an ESR of 120.
I also couldn't help but notice the min XTAL is 4MHz with an range up to 24MHz. I see 4MHz XTAL's can be obtained with down around 30 ohm ESR's, I wonder if that means the 4MHz can technically work, but needs to be a special low ESR XTAL. I suspect that picking up off the min 4MHz to 8MHz will allow more common XTAL's to work.
I have included the trace pF's in my expectations, but I don't know the pF's of the TI chip. I wonder if TI has added around 20pF to the chip. I'm not sure how to measure this kind of pF's.
I hesitate to use the MCU to generate the clock, as the board wasn't laid out for long high MHz traces, and it would likely cause coupling issues. I want to keep the high frequencies on short leads if possible to prevent antennas that can cross couple into other circuits.
Welcome to the friendlier side of internet crazy
Re: hip9011 integration
I am not aware of anything like clock stretching with SPI, but it is not uncommon with I2C.kb1gtt wrote: I have also removed the caps all together, which seems to start reliably. I then noticed that we were sending SPI as soon as it was starting, and that even with the XTAL starting reasonably fast, we were seeing the SPI before the XTAL was stable. So I got russian to add a 100mS delay to the SPI. It currently appears the SPI is stalling for some reason. I don't see the SCLK any more, and it appears the TPIC8101 is echoing the SPI as expected. At this point both russian and I don't know why the SPI is stalling. Perhaps when russian gets more than 10 minutes to look into it, something in software will jump out to him, however I'm a skeptic about this being a software problem. I suspect we are dealing with a hardware problem. I wonder if the TPIC is perhaps holding the clock low. I know that can be an option for SPI. Basically if the chip is backed up and needs some time, some chips can hold the clock low as a way to say slow down. Then when it releases the clock and the SPI master see's it has gone high, it then waits the amount of time, then pulls it low and continues clocking data on the stream. I wonder if that's happening here. I'm not sure how to figure out who is pulling the clock low. In the below, pink is SO on pin 11, Yellow is 5V power measured at pin 1, and blue is XTAL on pin 10.
For I2C clock stretching is not really problem as all nodes are open-drain. SPI is push-pull so if two pieces of hardware are driving different levels to a pin you usually see a line ending up somewhere half-way the supply voltage on the scope.. If that is not the case I expect some issue with software or some funky behavior of the SPI peripheral in the STM32. If SPI fails at the slave side you usually just get bogus data because the MISO line is not correctly driven from the SPI slave, all other lines (MOSI, CLK, SSEL) are in control of the master and should never be altered by the slave. I cannot think of any way a slave can stall a SPI bus really..
Offtopic: I need to get my hands dirty on this project and get some hardware and play around, but life is getting in the way
Yes that sounds like a good plan.So far in R0.4, I have added a 0R resistor which will allow us to measure Rq and ensure the SF is around 2 or better as noted in the TI's SBAA123. I have also changed the BOM to call for FOXSDLF/080R-20/TR which is an 8MHz part with an ESR of 80 while the current 4MHz XTAL has an ESR of 120.
I also couldn't help but notice the min XTAL is 4MHz with an range up to 24MHz. I see 4MHz XTAL's can be obtained with down around 30 ohm ESR's, I wonder if that means the 4MHz can technically work, but needs to be a special low ESR XTAL. I suspect that picking up off the min 4MHz to 8MHz will allow more common XTAL's to work.
I have included the trace pF's in my expectations, but I don't know the pF's of the TI chip. I wonder if TI has added around 20pF to the chip. I'm not sure how to measure this kind of pF's.
I hesitate to use the MCU to generate the clock, as the board wasn't laid out for long high MHz traces, and it would likely cause coupling issues. I want to keep the high frequencies on short leads if possible to prevent antennas that can cross couple into other circuits.
In most MCUs the feedback resistor is integrated into the oscillator (AVRs, STM32s have this), as this TPIC does not have the feedback resistor integrated this makes me believe they integrated a very basic Pierce oscillator.
I expect the pF's of the TI chip to be around 5pF or so, I do not have any reasons to think the generic rules and/or calculations for a 'generic' logic inverter do not apply for the TPIC/HIP chip.
Re: hip9011 integration
Looks like I have a bad scope probe. I now see the SPI clock just fine.
Oops I mangled the I2C and SPI bus. I agree it probably can't stretch the clock.
I have removed the XTAL caps, and it still doesn't start. Also does not start when I installed some 10pF caps. So far we have failed when 0pF, 10pF, 18pF, and 28pF have been installed, but we have success when a scope probe is connected to the OSout (pin10) pin. So I guess the obvious solution is to ship a DSOquad with each rusEFI
I randomly tried 10pF on C166 and 0pF installed in C167. Theory that I could simulate the scope probe. That also failed. So I'm expecting the scope probe is acting more like an antenna than a cap, which I suspect is providing the initial ping to get it started.
I guess I need to figure out how to get the OSIN to become a steeper transistion. It seems to be reasonably slow. See picture below, Yellow is 5V at R171, blue is VDD and pink is PB11.
[edit] updated yellow trace note[/edit]
Oops I mangled the I2C and SPI bus. I agree it probably can't stretch the clock.
I have removed the XTAL caps, and it still doesn't start. Also does not start when I installed some 10pF caps. So far we have failed when 0pF, 10pF, 18pF, and 28pF have been installed, but we have success when a scope probe is connected to the OSout (pin10) pin. So I guess the obvious solution is to ship a DSOquad with each rusEFI
I randomly tried 10pF on C166 and 0pF installed in C167. Theory that I could simulate the scope probe. That also failed. So I'm expecting the scope probe is acting more like an antenna than a cap, which I suspect is providing the initial ping to get it started.
I guess I need to figure out how to get the OSIN to become a steeper transistion. It seems to be reasonably slow. See picture below, Yellow is 5V at R171, blue is VDD and pink is PB11.
[edit] updated yellow trace note[/edit]
Welcome to the friendlier side of internet crazy
Re: hip9011 integration
It has started several times when powered via USB, I think I finally have it working. My current 2 modifications are, 10uF added on top of C165, C167 has a 10pF and C166 has no cap installed, so we'll call that 0pF.
I decided to try it this was as I noted in the below eval board schematic, that the MCU has a 470pF to couple in the MCU clock to XIN and XOUT didn't have any cap. So I mostly randomly decided to try the caps this way and it seems to work.
http://www.ti.com/lit/df/tidr519/tidr519.pdf
I'm going to do a bit more testing to help verify it's good this way. However it appears we have a light at the end of the tunnel for this issue.
I decided to try it this was as I noted in the below eval board schematic, that the MCU has a 470pF to couple in the MCU clock to XIN and XOUT didn't have any cap. So I mostly randomly decided to try the caps this way and it seems to work.
http://www.ti.com/lit/df/tidr519/tidr519.pdf
I'm going to do a bit more testing to help verify it's good this way. However it appears we have a light at the end of the tunnel for this issue.
Welcome to the friendlier side of internet crazy
Re: hip9011 integration
Arrrgh. It appears it was only starting because I had a small wire installed on the XIN pin which was picking up enough noise to get it started. Argh.
Hmmm, I could install a 470pF between CS and CIN. I'd bet that would give it enough of a ping to get it started. It would be very similar to the eval board layout. Any how, the battle rages on.
Hmmm, I could install a 470pF between CS and CIN. I'd bet that would give it enough of a ping to get it started. It would be very similar to the eval board layout. Any how, the battle rages on.
Welcome to the friendlier side of internet crazy
Re: hip9011 integration
I finally got it working after several power cycles and with out my various sniffing leads installed. Per the below picture, I re-located C166 such that it can couple in some energy to get the XTAL started when ever the SPI CS line is activated. Also see how I added a wire wrap wire (22AWG) and ran it through the via's to act as a strain relief. Picture below.
Technically that picture shows C167 with a 10pF (yellow-ish) cap instead of the 18pF (blue-ish) cap originally installed, but I don't think that matters. The issue is it needs that initial ping to get started.
Technically that picture shows C167 with a 10pF (yellow-ish) cap instead of the 18pF (blue-ish) cap originally installed, but I don't think that matters. The issue is it needs that initial ping to get started.
Welcome to the friendlier side of internet crazy
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: hip9011 integration
[video][/video]
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: hip9011 integration
Great my hack is working. The TPIC chip wants to be driven by an external signal from the MCU. We don't have this signal and a 4MHz to 24MHz signal is kind of a pain to route across the board with out coupling into other circuits. I wonder if the HIP chip would have this issue or if it would play nicer with an XTAL. We are looking to use the TPIC chip, so I would like to learn how to do this in a less hacked way.
I guess I should call TI and inquire why I'm having problems. I wonder who's good to talk to. Often the generic tech support lines don't get you to who you really want to talk to. I guess I'll have to start with the generic inquire, and see where it goes from there.
I guess I should call TI and inquire why I'm having problems. I wonder who's good to talk to. Often the generic tech support lines don't get you to who you really want to talk to. I guess I'll have to start with the generic inquire, and see where it goes from there.
Welcome to the friendlier side of internet crazy
Re: hip9011 integration
@ got the TPIC8101 working with an 8MHz XTAL. He got the XTAL working by following this app note http://www.crystek.com/documents/appnotes/Pierce-GateIntroduction.pdf
That's basically the same as the above mentioned links, but this one includes a note that the chip leads are typically between 4pF and 7pF, as well it talks about how tune the Rs resistor to maintain a balanced 180 deg shift. Spilly was kind enough to share the BOM items and calculation he did for his 8MHz design, so I'm planning to use those for Frankenso R0.4.
That's basically the same as the above mentioned links, but this one includes a note that the chip leads are typically between 4pF and 7pF, as well it talks about how tune the Rs resistor to maintain a balanced 180 deg shift. Spilly was kind enough to share the BOM items and calculation he did for his 8MHz design, so I'm planning to use those for Frankenso R0.4.
Welcome to the friendlier side of internet crazy
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: hip9011 integration
Now, with my 0.4 board nothing is going on unless I touch the crystal with my finger. I guess it's still not starting, even with the new R177 resistor? What value should I install for C169
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: hip9011 integration
Per this post, http://rusefi.com/forum/viewtopic.php?f=5&t=778&start=17
That was 470pF. I don't think the exact value is all that important, the goal is to couple in some energy from the CS line to allow CS to act as an initial ping to get the XTAL started. I would try to keep it in the pF range, as you don't want to modify the signal after it's started.
That was 470pF. I don't think the exact value is all that important, the goal is to couple in some energy from the CS line to allow CS to act as an initial ping to get the XTAL started. I would try to keep it in the pF range, as you don't want to modify the signal after it's started.
Welcome to the friendlier side of internet crazy
Re: hip9011 integration
Oh, also you can try replacing R177 with 0R, Blob of solder on top. or a 0R on to would work fine. R177 was added such that we could find the max series resistance on the XTAL before it starts. The 820 should be good but it might be to high.
Welcome to the friendlier side of internet crazy
- AndreyB
- Site Admin
- Posts: 14373
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: hip9011 integration
I've installed 47pF C169 and now I need to hold my finger to have the thing running.
As a second step I've replaced R177 with a 0R resistor and now I see the slope on the oscilloscope. Is it time to make these 47pf and 0R values official?
I believe that on the rev 0.1 board the trick was to remove one of R166/R167 and place it the way we have C169 now. These were even lower values, 18pF or 22pF
Still invalid SPI responses on the rev 0.4 board without the diode hack, to be continued.
As a second step I've replaced R177 with a 0R resistor and now I see the slope on the oscilloscope. Is it time to make these 47pf and 0R values official?
I believe that on the rev 0.1 board the trick was to remove one of R166/R167 and place it the way we have C169 now. These were even lower values, 18pF or 22pF
Still invalid SPI responses on the rev 0.4 board without the diode hack, to be continued.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: hip9011 integration
According to the datasheet for the crystal http://www.abracon.com/Resonators/abls.pdf the maximum drive power is 1 mW and the typical/recommended is 0.1 mW. I've scribbled out the equation to calculate the needed resistance based on rms drive power.kb1gtt wrote:Oh, also you can try replacing R177 with 0R, Blob of solder on top. or a 0R on to would work fine. R177 was added such that we could find the max series resistance on the XTAL before it starts. The 820 should be good but it might be to high.
R = (6495 / P) ^ (1/3) - 80
At a minimum R177 needs to be greater than 107 ohm (max power). R177 would need to be greater than 322 ohm to stay under the typical/recommended power.
Re: hip9011 integration
According to this freescale document http://www.freescale.com/files/microcontrollers/doc/app_note/AN3208.pdf on troubleshooting oscillator startup, decreasing the value of R177 will decrease startup time. Lets try leaving the capacitor values at 24pF and decreasing the value of R177 to around 300 ohms.russian wrote:I've installed 47pF C169 and now I need to hold my finger to have the thing running.
As a second step I've replaced R177 with a 0R resistor and now I see the slope on the oscilloscope. Is it time to make these 47pf and 0R values official?
I believe that on the rev 0.1 board the trick was to remove one of R166/R167 and place it the way we have C169 now. These were even lower values, 18pF or 22pF
Still invalid SPI responses on the rev 0.4 board without the diode hack, to be continued.
Edit: Just realized you are talking about the capacitor that is connected to the CS line. That component shouldn't be necessary. The current component values just need to be tweaked/tuned. Don't you love analog circuits?
Re: hip9011 integration
Is C169 really necessary ? (I just looked at SECU4 and there is no such workarround for startup.)
OSCIN with C169 (470p??) has low impedance to "ground" (CS is tighted to log. 0 or log. 1 which is almost ground for oscilator, is not it ?)
If you have troubles with startup of oscillator, should not be better to try another manufact. of crystals ?
Or try to connect C169 to oscOUT instead oscIN ?
OSCIN with C169 (470p??) has low impedance to "ground" (CS is tighted to log. 0 or log. 1 which is almost ground for oscilator, is not it ?)
If you have troubles with startup of oscillator, should not be better to try another manufact. of crystals ?
Or try to connect C169 to oscOUT instead oscIN ?
Tomas
Re: hip9011 integration
I agree that playing with the value of R177 is a good place to start for startup issues. However, jumpering R177 or using too low of a value will likely damage the crystal. If R177 is zero ohms, power is approximately 12.7 mW (maximum rating is 1 mW).kb1gtt wrote:I designed R177 per Figure 15. Negative Resistance Measuring Circuit on this PDF page 11. Take note it specifies you increase the Rq until you hit the max. The XTAL's ESR is 80 ohms, or should be 80 ohms assuming china populated the correct part(s). Being 8 megs, and seeing that 7.99 megs it 100 ohms, means we might really be 90 ohms. Any how, with a SF of 3, Rq should be 3*80 = 240 ohms, and it appears that 280 ohms is to much. So we should decrease the value of R177 and see when it starts. Then we can cald the SF and see if we are acceptable or not.
I'm not sure how TI derived their safety factor formula, however, it seems to correlate with the numbers I calculated in regards to the crystal's maximum power rating. According to their chart, a value less than 120 ohms is "unsuitable" for R177.
Re: hip9011 integration
I don't think the issue is with the crystal. Using a different PCB with the same crystal and passive component values I have not had any issues with startup. Since the oscillator is an analog device, it is going to require a bit of tuning for it operate properly.Tomin wrote:Is C169 really necessary ? (I just looked at SECU4 and there is no such workarround for startup.)
OSCIN with C169 (470p??) has low impedance to "ground" (CS is tighted to log. 0 or log. 1 which is almost ground for oscilator, is not it ?)
If you have troubles with startup of oscillator, should not be better to try another manufact. of crystals ?
Or try to connect C169 to oscOUT instead oscIN ?
Re: hip9011 integration
The hope and goal is to not have anything for C169. C169 is a plan B make it go hammer. The 470pF was to make this potentially more like the TPIC suggested datasheet. See page 16 found here http://www.ti.com/lit/ds/symlink/tpic8101.pdf they have that 470pF on the Xin and driven by the MCU. C169 is being used to get an initial upset in the XTAL circuit which gets it started. I suspect the TPIC has changed the internal gain or some startup circuit which has made it more difficult to get started than the HIP.Tomin wrote:Is C169 really necessary ? (I just looked at SECU4 and there is no such workarround for startup.)
OSCIN with C169 (470p??) has low impedance to "ground" (CS is tighted to log. 0 or log. 1 which is almost ground for oscilator, is not it ?)
If you have troubles with startup of oscillator, should not be better to try another manufact. of crystals ?
Or try to connect C169 to oscOUT instead oscIN ?
Do you mean the SECU-3 schematic found here http://secu-3.org/wordpress/wp-content/uploads/pdf/secu3_schema.pdf this schematic notes they planned for a HIP9011 instead of the TPIC8101. The HIP does not have the suggested MCU connection. Also do we have knowledge that the SECU has reliable functioning knock? We are finding intermittent reliability. Perhaps they are also having trouble but it hasn't been evident yet, I don't know.
I have stumbled upon a couple other people who are had trouble with the TPIC starting and 3.3V operation. It seems to be a common issue.
Welcome to the friendlier side of internet crazy
Re: hip9011 integration
It would be very interesting if TI would release specs on the differences between the TPIC and HIP. On the datasheet the connection to the MCU is simply a clock output. This would allow the crystal oscillator circuit to be omitted. However, that would make for a huge antennae.kb1gtt wrote:See page 16 found here http://www.ti.com/lit/ds/symlink/tpic8101.pdf they have that 470pF on the Xin and driven by the MCU. C169 is being used to get an initial upset in the XTAL circuit which gets it started. I suspect the TPIC has changed the internal gain or some startup circuit which has made it more difficult to get started than the HIP.
From my understanding the biasing resistor going across Xin and Xout is generally part of the SOC (does not require an external component). I have yet to find anything better than rule of thumb suggestions for that resistor. Its value may also need to be fine tuned.
Since the previous set of components also had startup issues, is it possible that there is something on the PCB we are overlooking?