M644A vs M324P serial problem

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Got an interesting one here... I'm trying to use UART0 on a 644A to talk to a u-blox6 GPS chip, and failing.

The same code, same pins, same voltage, same clock speed, same everything, works fine on the 324P.

Carrying the physical gps chip between the two boards shows me it works in the 324 but not the 644.

The point is... poking around with a USB serial probe shows the *exact same data* being delivered to the pin on the ublox, but it just doesn't give a response as expected. There *is* data, but it's the default NMEA codes which I don't want. The gps chip ignores the mode change message and also ignores commands to change the NMEA messages.

/me is completely confused... is there some really subtle difference between the two UART0s?

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As far as I can see the only major difference between your chips is the sleeping BOD in the MCUCR register BODS and BODSE bits. The other changes are the expected FLASH, EEPROM and RAM size differences.

barnacle wrote:
The same code,
I assume you assembled or compiled your code for the different processors with the correct project settings/headers/whatever.

The original ATmega644/V data sheet claimed only one single USART was in this chip. If you have the wrong project settings/headers/whatever for this older chip something may be messed up?

You could try enabling the pull-up resistor on the RXD0 input pin.

If you use any level converters between your GPS chip and USART maybe this is messed up or maybe you have a PC board problem on the 644A board. Do you have other boards to try out? Not likely, but could you easily switch the processor chips between the boards for testing?

[edit] there was nothing in any of the ATMEL 644 family migration sheets about the USART.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What do you use for CPU clocks on the two different boards?

Jim Wagner

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you make sure that fuses like CKDIV8 and CKSEL are the same on both chips?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks guys.

Fuses are the same - no BOD, no CLK/8, same CLKSEL. The clock in both cases is an 8MHz crystal. JTAG is disabled. There are no level converters - direct 3v3 Vcc in both cases. Project settings for 644A.

This is doing my head in!

The data I'm monitoring (yes, you can run multiple copies of Bray's in W7!) is going both ways at the same rate, as shown by poking around with a USB serial adaptor, but it's as if the GPS simply doesn't see it. However, I'm looking on the pin...

I'm beginning to wonder if the clock rate is ever-so-slightly off; I'll play with that today. The message to the GPS is quite long - sixty bytes or so - and includes a checksum, so it's possible. I would have expected the monitored data to show frame errors if the rate is off significantly, though.

I may also simply stick another board together with a 324...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stupid idea...
but you are really sure that you have set the fuses correct?

As your basic speed is OK you run on 8MHz but if in once case you accidentally still ruin on the internal osc... all seems OK, but indeed can be slightly OFF and as such give you trouble...

There not accidenatlly is a level converter on the u-blosk GPS receiver??? I have had some simple Ublox 4 gps receivers and they had a onboard level converter that could be bypassed, but in the end I removed them as the bypass gave me similar problems.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Even stupider
Wasnt there a 644 version wo dual uart?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is at least the P version.

from the head there was a single version with only a single uart....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This one has the dual UART - and I'm using UART0 to talk to the GPS and UART1 to talk to monitoring.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Complete shot in the dark - make sure the fuses for the crystal are set to "full swing".

So far it's only been noticed in the 1284P and not smaller brethren but there the crystal drive seems "weak" in some way and it benefits from swinging fully. It affects the accuracy of the UART otherwise.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How fast are you sending the data? If you are sending bytes back to back, try inserting a short gap between each byte, at least 1 bit-width, and see what that does. IF you do have a slight timing difference, this gap will allow the UARTs to sync up in between start bits.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thats the same as 2 stop bits I think.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Two stop bits on the transmit end WILL be received OK on a one stop bit receiver.

The other way can fail if the characters are packed as close as possible.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does a 644 have an M103 compatibility fuse? Or is that only in the mega128?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mr Wagner wins the prize, thank you!

It seems that the feeble clock is near enough to talk to an FT232-based serial port without error, but setting it to full-swing made it work. I'd forgotten the double clock setting...

Cheers Jim!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"

Complete shot in the dark - make sure the fuses for the crystal are set to "full swing".

So far it's only been noticed in the 1284P and not smaller brethren but there the crystal drive seems "weak" in some way and it benefits from swinging fully. It affects the accuracy of the UART otherwise."

 

 

This shot in the dark was exactly what I needed to overcome a similar issue to the one posed originally on this thread. I had a '324A that worked perfectly and wanted to move to a '644 to give me more memory headroom as we head in to our system integration phase. No other changes were made to the circuit and the code was recompiled as a '644A (need to select '644PA in AVR Studio 4). According to the datasheet, this should have been a drop in replacement. Serial communications to the new device were hit or miss. Sometimes commands appeared to be received and correctly interpreted while other times, no or little communications were established (using TX0 and RX0 for comms). After long sessions scouring the datasheet and trying to narrow the issue down, I read this thread and decided to try changing the fuses from the low power to the full swing settings (Was state: CKSEL[3..0] = 0xF; Is state: CKSEL[3..0] = 0x7). I am running with a 16.0 MHz oscillator with load caps of 15 pF. After just changing the fuse settings as described, the '644A circuit works with no issues. It appears that the issue indicated concerning the 1284 most likely also applies to the 644 as well. If this is documented somewhere, I would really love to have someone let me know where it is so I can read more about it. Thank you!
 

Last Edited: Mon. Jul 13, 2015 - 06:58 PM