Show Posts
Pages: [1] 2 3 ... 10
1  Using Arduino / Installation & Troubleshooting / Re: Mother of all strategies to deal with the dreaded "not in sync" error on: September 18, 2014, 10:05:26 pm
Well that's entirely possible.  Tonight I worked on the problem further.  I tried to upload the Blink sketch to the devel board via the Arduino IDE.  I was able to do this in the past, I distinctly remember that.  However it didn't work.

So I decided to explore further.  I have an old XP machine sitting in a back room; I haven't powered it up since the spring; it was my old, quite old desktop.  But it still works.  I installed Arduino IDE 1.0.5, the Bobuino variant files and the FTDI driver.  I tried uploading the Blink sketch to both the devel and prod boards.  Neither worked, same error.

So it doesn't appear to be the USB cable, the 6 wires coming from the FTDI breakout, the laptop, the driver nor the boards themselves.  That leaves the FTDI breakout...there isn't a way to check the breakout that I'm aware of, so I'll just have to wait until the new one arrives.  Cross did mention that he was able to upload via the serial header, so really it should work.

To that end I ordered a new breakout tonight.  Well two actually - hah!  The first comes from China (so it won't arrive until mid-October!), but I didn't notice until after I bought it (duh-oh!).  So I bought another.  The second should be here Tuesday.  Therefore I'll suspend working on this problem until then.  Crossing fingers that this is indeed the cause!
2  Using Arduino / Installation & Troubleshooting / Re: Mother of all strategies to deal with the dreaded "not in sync" error on: September 18, 2014, 06:00:10 pm
Hmm, once I was stuck a lot of time. The problem was the crystal, which didn't start up the uC. I had 2 22pf caps, but oscilator needed 18pf, then it worked fine. Are you using external or internal osc? Resonator or crystal?

Hi-

Interesting.  Thanks for the continued feedback.  I hadn't thought of the crystal being a problem.   Hmmmm....it doesn't seem like the crystal is the problem in my case however.   I say that only because I can upload the blink sketch successfully via the mkII programmer and the ICSP header on my board.  And Cross was able to upload the Blink sketch via the serial header via his setup.  It is an external SMT crystal that I am using, specifically this one:

http://www.mouser.in/Search/ProductDetail.aspx?R=ABLS-16.000MHZ-B2-Tvirtualkey52750000virtualkey815-ABLS-16-B2

I am using 22pF caps for this crystal.  It seems to work just fine, if the ability to load and run the blink sketch is any indication.
3  Using Arduino / Installation & Troubleshooting / Re: Mother of all strategies to deal with the dreaded "not in sync" error on: September 18, 2014, 05:49:08 pm
Ok I tried number 8 tonight when I got home.  Let me clarify that by saying that I tried using a new USB cable, not serial cable, that was a bit of a typo.  I had another USB cable that would fit into the USB port on my FTDI breakout, so I unplugged the one had been using, set it aside and tried the new one.  No joy, same result.  Just as a quick note, I am using Arduino IDE 1.0.5 on a Win7 laptop.

Other things I've tried during the past few days:

12) In the Arduino IDE (1.0.5), under File->Preferences, I clicked on the check-box to enable verbose output during hex file upload.  That generated the following output from avrdude:

Code:
Binary sketch size: 3,208 bytes (of a 130,048 byte maximum)
C:\Program Files (x86)\Arduino\hardware/tools/avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega1284p -carduino -P\\.\COM2 -b115200 -D -Uflash:w:C:\Users\Jerry\AppData\Local\Temp\build4496533372884728245.tmp\Blink.cpp.hex:i

avrdude: Version 5.11, compiled on Sep  2 2011 at 19:38:36
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware/tools/avr/etc/avrdude.conf"

         Using Port                    : \\.\COM2
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv: . [00]
avrdude: stk500_getsync(): not in sync: resp=0x00

avrdude done.  Thank you.

The only thing I noted about this was that in the past when using avrdude directly, I had used m1284p instead of atmega1284p for the part option.  So I tried running avrdude directly from a command prompt and changed the part option shown in the above code block to m1284p.  No diff.  And from what I have been able to determine, m1284p and atmega1284p identify the same part.

So then I tried running other avrdude commands in an attempt to do *anything* via serial.  No success.  I could post the output from that, but it seems kinda redundant, so I have omitted it for the time being.

So now I'm off to order another FTDI breakout and see what that does.  It won't be here for a couple of days of course.  That said, I don't anticipate it making any difference, but you never know and having a backup isn't a bad thing.

Later tonight I will try using this same configuration to upload a sketch on one of my old devel boards.  The boards I am attempting to get working now are the first round of the prod boards.  There is no fundamental difference between the two designs, though I switched to an external ADC and per Cross's recommendation the level shifter component was switched out for two individual level shifters.  And I made the switch to JST connectors.  So there's no significant difference; this stuff should work.  I know that the devel boards were working in this same configuration.  I also know that I encountered this problem in the past.  Switching to  a slightly newer version of the FTDI driver seemed to cure the problem then, but it hasn't made a difference now.  Cross told me that he's using an even older version of the FTDI driver, so I may download that, install it and see if it makes a diff.

Will keep up the fight and post the results to this thread.  Any ideas are appreciated.  Thanks
4  Using Arduino / Installation & Troubleshooting / Re: Mother of all strategies to deal with the dreaded "not in sync" error on: September 18, 2014, 05:24:57 pm
Hi mart256-

Thanks for the feedback and contribution.  You have the right idea regarding checking connections.  More specifically, what I meant by that step was two-fold:

1a) Ensure that you have the wiring done correctly.  One cause that I saw when Googling the error was a guy who had Rx connected to Rx and Tx to Tx.  Obviously that's a problem.
1b) Perform a continuity test on your wiring from the breakout to the serial header on your board (via DVMM, continuity tester, etc.)

I've done both multiple times and everything checks out thus far.  Excellent point about re-burning the bootloader.  I've also done that multiple times.  I've also tried using a different copy of the same bootloader, just in the (highly) unlikely event that my bootloader copy had become corrupted somehow.  Cross sent me the bootloader he uses for his 1284p projects and I tried burning that.  Although the burning of the "new" bootloader was successful there was no diff WRT the serial stuff, I got the same result.

Thanks again
5  Using Arduino / Installation & Troubleshooting / Mother of all strategies to deal with the dreaded "not in sync" error on: September 18, 2014, 02:51:27 pm
For the past two and a half days and until 2 or 3 am in the morning I've been obsessively attempting to resolve the latest incantation of the dreaded

avrdude: stk500_getsync(): not in sync: resp=0x00

error that you can experience when attempting to upload a sketch to your board via a serial interface.  I've Googled, I've searched, I've tried all manner of remedies, all to no avail.  Because the aforementioned remedies were rather widespread in the Internet, I thought I'd start "the ultimate" thread that addresses the issue.  It's kinda dangerous to make such a statement, I realize.  I don't claim to be an expert, just someone who is trying to get something working but this is standing in my way.  Perhaps others can contribute their experiences and solutions to the thread, in the hope that it would help others in the future.

So a bit of background.  From my research, this error essentially means that whatever you are using to upload sketches to your board cannot communicate with the uC on that board.  IOW your board isn't responding to your attempts to upload a sketch.

Specifically in my case, I have a custom-designed PCB that uses a 1284p (Bobuino variant via CrossRoads); I have a serial header on my PCB that should enable me to upload sketches serially and also to see serial data from the board for the purposes of debugging.  In my case I am communicating with my PCB using the Arduino IDE on my laptop computer.  I use one of the USB ports to run a USB cable to an FTDI breakout.  Then I use simple female-to-female electronics-project style (0.1") wiring to connect the standard 6-line serial output from that breakout to the serial header on my PCB.  Cross looked at a couple of my boards last weekend and told me that he was able to upload the Blink sketch via the serial header on my board.  Therefore that tells me that the board is working ok and further that there is something wrong in my configuration.  Somewhere.  But I'll be @#&*#@$^ if I can find it thus far.  The pin connections from the breakout to the serial header are:

BREAKOUT                   SERIAL HEADER ON PCB
Vcc                                 +5V
CTS                                 CTS (this is a rarely used pin)
GND                               GND
Rx                                    Tx
Tx                                    Rx
DTR                                 DTR (this pin is connected to the RESET trace via a 0.1uF cap)

Often the cause of this no-response scenario is rather simple, but I have also read stories of folk encountering a much more difficult time in finding resolution.  And those folk, like me, were at their wits-end and were willing to try most anything to "fix it."  With that in mind, here is a compilation of the possible solutions that I have attempted thus far.  Try these as a first-stab:

1) Check your physical connections.  Ensure that your pinout is correct from the breakout to your board.
2) If using the Arduino IDE, ensure that the correct COM port is selected in the Tools menu (should have a check mark next to it)
3) Ensure that you have first installed the correct bootloader for your chip; you won't be able to do this serial I/O stuff without the correct boatloader being successfully installed.  This must happen PRIOR to you attempting any serial I/O.
4) Press the RESET button prior to your sketch being uploaded.  Sometimes the DTR function on your header isn't working properly and so your uC RESET line isn't being brought low prior to the upload.  If this corrects the problem, then you need to re-check how you have your DTR implemented on your board.
5) Disconnect all wires that run to your Rx pin 0.  Then try to upload again.
6) Check your driver.  Perhaps consider using a different driver version or different driver altogether.  Uninstall and re-install your driver.
7) Another of the common causes is a comm speed differential between the device you are attempting to upload sketches with and your board.  Ensure that these match.
8 ) Try a new serial cable.
9) Try a different device to upload your sketch with.

And the list goes on if you Google enough.  There are cases of the Uno not responding, so a reflashing of the hex file that handles serial communication is needed.  But that doesn't apply to my implementation since I'm not using an Uno.  And so I moved on.

I haven't tried numbers 8 or 9 yet, as those aren't readily available to me.  I might have another USB cable that I could try, but I don't have another FTDI breakout to try with.  The next step is to order one I suppose.
6  Using Arduino / Microcontrollers / Re: Unknown Status 0x00 error when burning bootloader on: September 09, 2014, 12:21:02 am
Yeah that's more correct.  I don't think anything was actively holding the ADC's SS line low.  But it was low and ultimately that was the problem.  Thanks for the feedback.
7  Using Arduino / Microcontrollers / Re: Unknown Status 0x00 error when burning bootloader (solved) on: September 08, 2014, 01:31:22 am
The long story short version for anyone who might read this thread in the future is that there was a flaw in the design.  So if you are getting this error too, you have checked your connections, the crystal's caps and your programmer, then look back at your design.  The problem could very well lie there.

In my case specifically, those SS lines that were low were indeed the problem as I was suspecting.  I shipped the boards off to Cross who found time to take a look-see this weekend.  As it turns out I had 3 SS lines that were left without a hardware pullup.  Two were for shift registers and one was for a new ADC that I am using.  I was already setting the SR pins to digital output and then setting them to HIGH in software.  The plan was to do the same for the ADC.  I remember now that I thought it would work because I couldn't find anything in the ADC's datasheet that would indicate otherwise.  I struggled with confusion over the matter, but decided to go without the pullup for the new ADC.  And that is what bit me.

The ADC's SS being held low was causing it to keep the MISO line low and because the ICSP header uses SPI to program the uC, the mkII couldn't communicate with the uC.  So Cross soldered in a 10K pullup to the ADC's SS line and all is well.  He was able to load the bootloader and upload the blink sketch successfully.

Sheesh.  I didn't realize that the ADC (a MAX11628) would put anything out on the MISO line like that.  I think Cross was surprised too.  'Feeling kinda stupid right now, but I suppose that's how you learn....

Anyway mystery solved.  Hope this helps someone else in the future.
8  Using Arduino / Microcontrollers / Re: Unknown Status 0x00 error when burning bootloader on: September 04, 2014, 10:08:12 pm
Ok here are the pin-by-pin values that I observed on the 1284 tonight:
Code:
PIN FUNCTION VALUE
----------------------------------
1 MOSI (PB5) +0.002V
2 MISO (PB6) +0.004V
3 SCK (PB7) +0.011V
4 RESET +5.05V
5 +5V +5.05V
6 GND -0.00V
7 XTAL2 +0.004V
8 XTAL1 +0.003V
9 RX (PD0) -0.00V
10 TX (PD1) +0.00V
11 BLE_RDY (PD2) +0.001V
12 TX1-D3 (PD3) +0.002V
13 LCDSRSS (PD4) +0.001V
14 D8 (PD5) +0.002V
15 D9 (PD6) +0.002V
16 RTCSQ (PD7) +0.026V
17 +5V +5.03V
18 GND -0.00V
19 SCL (PC0) +5.05V
20 SDA (PC1) +5.05V
21 FRAMSS1 (PC2) +5.04V
22 FRAMSS2 (PC3) +5.04V
23 D2 (PC4) +5.01V
24 BLE-SS (PC5) +5.04V
25 PCLR (PC6) -0.00V
26 LEDSRSS (PC7) +0.002V
27 +5V +5.05V
28 GND -0.00V
29 AREF +0.012V
30 A0 (PA7) +2.192V
31 LCD-EN (PA6) +0.002V
32 LCD-RS (PA5) +0.002V
33 CTS (PA4) +0.002V
34 ADCSS (PA3) +0.002V
35 LD_SUP (PA2) +0.002V
36 LD_LEAK (PA1) +0.002V
37 A7-D21 (PA0) +0.002V
38 +5V +5.05V
39 GND -0.00V
40 D4 (PB0) +0.001V
41 D5 (PB1) +0.001V
42 D6 (PB2) +0.001V
43 D7 (PB3) +0.01V
44 SS-D10 (PB4) +5.04V

A couple of the SS lines were low, I wasn't expecting that.  Not sure if it's significant or not, will go back to the schematic to see if that was intentional.  I didn't see any shorts anywhere.  Dunno.  Anyone see anything peculiar?

Thanks!
9  Using Arduino / Microcontrollers / Re: Unknown Status 0x00 error when burning bootloader on: September 04, 2014, 05:13:41 pm
Hi-

By "chip", you're referring to the uC (1284)?  If so, then no, it's oriented correctly.  That was one of the first items I checked.  The circular impression on the upper left of the chip matches the location on the PCB.  That didn't change between devel and prod boards.  Good thought though.

Thanks for the feedback.
10  Using Arduino / Microcontrollers / Re: Unknown Status 0x00 error when burning bootloader on: September 04, 2014, 02:41:02 pm
Docedison and Budvar10- Thank you for the feedback.  I had the same thoughts that Doc had, but as it turns out everything in that regard seems ok.  Here is a report that I sent Cross just a few minutes ago.  I thought I'd post too to see if y'all have any feedback:

Well crap.  I took my stuff into the assembly house this morning to have it looked over.  I took the prod boards, the devel boards and several spare parts.  Here is a summary of what was found:

1) The crystal's caps on both the devel and prod boards are indeed 22pF and are functioning correctly.
2) The devel board's 16MHz crystal is functioning correctly; we saw a nice sine wave.
3) The crystal on the prod board has no signal, which is to say that it isn't doing anything.
4) The crystal itself doesn't appear to be defective.  We replaced it with a through-hole variant 16MHz crystal from my spare parts bounty (!) that the devel boards use; no diff.
5) The AREF cap shows +5.02V on the devel board and +2.xxV (don't remember exactly) on the prod board
6) We couldn't find a reason for the diff stated in #5.
7) The assembly house folk seemed to think that the 1284 was remaining in a "sleep state" though they couldn't say that for certain.
smiley-cool Then they had to stop at that point.  They told me that the next step would be to probe each of the 44 pins on the 1284 to see if I was getting the voltages that I expected.  The design did change slightly between the two boards and it's possible that some component is causing the 1284 to misbehave.

So they concluded that there was something in the design that was/is causing the 1284 to not "wake up."  I couldn't imagine what that would be, and I used Cross's services to verify that the design was ok prior to building these boards, he would have caught something if there was a problem.  One change that Cross recommended was to discontinue using the TI level shifter.  Therefore I went to two separate chips, one to convert 5 to 3.3 and the other chip converts 3.3 to 5.  Could the new level shifters be an issue? (I wouldn't see how)  Another change was that I was using the 1284's internal ADC.  As is well documented, it's more of a "hobby ADC", so I switched to an external precision ADC.  That freed up several of the analog pins on my 1284.  I ended up re-purposing those pins in a combination digital-and-analog usage type of scenario.  Could the way I am using the analog pins on the prod boards be an issue? (Also can't see how)

Another thought was this.  I went back in my head and thought about the times that I first did anything with ANY of the devel boards.  When I burned the bootloader (and fuses) on those boards, I always used the +9V battery to power the board, not the +5V from the laptop.  And I employ a voltage divider from the +9V source to tell me when the battery is running low so that I can illuminate a "LOW  BATTERY" led.  This voltage divider output runs to one of the analog inputs on the 1284.  This morning we noted that this input pin was showing something around +2V.  I told the assembly house that this is kinda what you'd expect to see if not supplying a +9V battery to the battery terminals.  Am I right about that?  And could this type of analog input be causing the uC to misbehave? (sounds unlikely)  It almost seems like the next step would be to fashion up a connector and try to power the board with the +9V when burning the fuses and bootloader, just as I did with the devel boards.  But then again, that seems rather unnecessary to me somehow.  Kinda silly even.  It should work with power from the laptop.

Today after work I am sending Cross a couple of the prod boards, one of the devel boards and some spare parts so that he can look it over when he has a chance.  I've got to get over this hurdle and move on.

Thanks!
 
11  Using Arduino / Microcontrollers / Re: Unknown Status 0x00 error when burning bootloader on: September 02, 2014, 06:34:52 pm
I'm pretty confused as I have read the last comments. Your programmer seems to be OK if you are able to write fuses or write whatever to other devices. It should be able to write bootloader or program also. Problem is probably somewhere else.
Yes I agree, I don't think it's the programmer, but I have ordered a new one anyway, just for completion.

Whenever I've obtained those messages  the problem which I had was always in wiring (misplaced connector about pin e.g.) and consequences. It would be better to work with minimal circuit but in your case it is not so easy as you have board completed.
You have to: Double check connections and try again.
I've lost count of how many times I've checked the connections.  The current thought is that the 16MHz crystals are misbehaving somehow.  I hope the new programmer arrives tomorrow, but I'm doubtful.  I say that because I called the assembly house today and will go in on Thursday morning to see if they can make a determination.  I'd like to verify that the new programmer doesn't make any difference prior to taking the boards in for a look-see.  After discussing the problem, their initial knee-jerk reaction was in regard to the crystal too, so perhaps I'm onto something there.  Possibly not, but we'll see.

The only reason why I'm using F7 for low fuses is that sometimes I have no technical data about crystals which I'm using for experiments. It concerns only chip power up time according the datasheet. Try to use internal ocsillator if you think the crystal is suspect. It is better to try this first than solder to final board. Raw chip is set to use internal osc. by default.
Don't forget to use appropriate bootloader.

Hmmm....ok.  I can try that but must admit to not being familiar.  Is there a how-to somewhere that I could take a look at?

Thank you for the help, I appreciate it.
12  Using Arduino / Microcontrollers / Re: Unknown Status 0x00 error when burning bootloader on: September 01, 2014, 09:51:52 pm
Oh I forgot to mention; I understand that burning the bootloader sets the fuses according to the boards.txt file.  Allow me to verify something else though if I may.  As I understand it, you don't need to burn the bootloader in order to use the uC, correct?  I mean, the bootloader is burned so that you can have serial I/O consisting of uploading sketches, data IN/OUT.  Right?  If you do burn a bootloader it is placed at the end of the memory array and is used to perform those functions.  I'm not sure if it does anything beyond that.  What I'm getting at is that burning the fuses and burning the bootloader are different tasks that are not related nor dependent on each other, correct?  If all you wanted to do was to upload your sketches via the ICSP header, you wouldn't need to burn the bootloader at all.  You could burn the fuses, upload the sketch you want to run and be done with it.  But any updates to your sketch or to upload a new sketch would mean that you'd need the ICSP again.  I have been operating with the understanding that I burn the bootloader only because I want to be able to see serial data for debugging, and also to enable sketch updates via the serial header.

And now that I think about it, how does the  Arduino IDE upload sketches ... does it use avrdude 'under the covers'?  Or does it have some other mechanism/script/executable that it runs?

I know this is a little off topic, but not really.  I'm interested to learn and it applies to the problem I'm experiencing.

Ok thanks
13  Using Arduino / Microcontrollers / Re: Unknown Status 0x00 error when burning bootloader on: September 01, 2014, 09:03:49 pm
Hmmmmm....ok.  Could I get your most recent boards.txt file that you mentioned?  The one I downloaded (some time ago) has 0xff for the low byte fuse...

Nick's stuff ... that uses an Arduino as a programmer, right?  Isn't it odd that the mkII that I have now works on the devel board but not the prod board?

Ok thanks
14  Using Arduino / Microcontrollers / Re: Unknown Status 0x00 error when burning bootloader on: September 01, 2014, 01:05:52 pm
Ok now I am thoroughly confused, if I wasn't already.  I just tried using my mkII programmer to burn the fuses on one of the devel boards that I have (and that I know to work correctly).  I was able to do that; I could change the fuses to whatever I wanted.  I tried Cross's suggestion with the devel board too, and noted much the same behavior as the prod board.  However because the devel board uses through hole crystals, I was able to flip the board over and look at the voltage on the DVMM.  Both terminals showed approximately +2.45V.  I see +0.04V on the prod board crystal, but I cannot be sure that I am making a good connection to measure anything.  The new crystal is SMD, but I can see the legs and they're buried in a mound of solder.  So I would think that I could check it pretty easily.

So what the heck is going on?  Could this batch of crystals be INOP?  Seems rather unlikely that all 3 boards would be that way, but ....
15  Using Arduino / Microcontrollers / Re: Unknown Status 0x00 error when burning bootloader on: September 01, 2014, 12:21:17 pm
Just for info. The difference between low fuse F7 & FF is for crystal oscillator with low rising power and fast rising power (FF). I prefer F7 to make sure clock stability at MCU's startup.
I think the problem is in programmer. I had similar problem due bad wiring or what (not 100% sure) and to reload FW or ISP sketch it helps after rewiring of course. That's the reason why I'm recommending to try another programmer.

Ah, I see.  So do you recommend changing the FF value to F7 permanently, even in the boards.txt file?  Would it change anything once startup completed?

I have ordered a new AVRISPmkII programmer, though I don't expect it to arrive until the end of the week at the earliest.  I do have a UNO, but am not sure how to use that to burn the fuses....
Pages: [1] 2 3 ... 10