mEDBG USB/Serial Baud rates?

Log in or register to post comments
Go To Last Post
36 posts / 0 new
Author
Message
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4769 View posts
Location: SF Bay area
#1
Posted by westfw: Sat. Aug 29, 2015 - 08:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does anyone know if the mEDBG chip (ATmega32u4 based) used on the Xplained mini eval boards supports baud rates above 57600 in its USB/Serial bridge code?

EDBG (AVR32 based, I think) is documented as working up to 2Mbps, but I can't find the equivalent for mEDBG, and I have some code that shows garbage at 115200, even though it works fine at 9600/38400/57600.   Of course, somewhere around there is where the math gets tough, too, so it could be a bug in my SAMD10 code...

 

inline void uart_init(uint32_t baud)
{
  uint64_t br = (uint64_t)65536 * (F_CPU - 16ULL * baud) / F_CPU;

("inline" is supposed to make it avoid having to do 64bit math at runtime.  It seems to work.  The value written to the BAUD register looks correct (63019 for a 48MHz clock.))

 

Um: 

mEDBG
Debug host
Debug port
Serial number     ATML2378020200002983
Connection        com.atmel.avrdbg.connection.cmsis-dap
Firmware Version  1.7
Hardware Version  0

 

Edit: the "Getting started" project produces the same sort of garbage when configured for 115200bps.  And it has an entirely different usart setup (using ASF)

 

Tags:

Tools, Evaluation and Development Kits (AVR-related)
Last Edited: Sat. Aug 29, 2015 - 08:55 AM
Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Sat. Aug 29, 2015 - 04:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Yeah, I've noticed the same thing.

 

In my MCU starter projects I use 38400 for mEDBG.

 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top
oxijin
oxijin's picture
Level: New Member
Joined: Wed. Sep 9, 2015
Posts: 2 View posts
Posted by oxijin: Wed. Sep 9, 2015 - 06:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On an atmega328p xplained mini with the 32U4's baud rate set to 115,200 through a terminal application, the baud rate I've measured coming out of the 32U4 is actually 111,111.  This is off by 3.5%, which is a lot for a UART connection.  It could have been set to 117,647 instead, which is off by 2.1% (still a lot, but better than 3.5%).  Most firmware that sets baud rates on AVR's clocked at 16 MHz (including the 32U4) to 115,200 uses UBRRn = 16, which yields the 117,647 actual rate.  Arduino Uno is an example of that.  UBRRn = 17 gives a baud rate of 111,111.  Both of these pertain to situations where the UCSR0A register's bit U2X0 is set to enable "double speed mode".  A UART connection between two AVR's with a shared 16 MHz clock where one UART is set up for 111,111 baud and the other is set up for 117,647 won't work.  But since there's a shared clock, it doesn't really matter what the baud rates are set to as long as they're the same, and as long as they're not too high for the software/interrupt/layout circumstances.

 

You can precisely transfer test bytes between the two avr processors at baud rates as high as 1 Mbaud (2 Mbaud if you don't have to deal with the screwy mEDBG firmware).  But given everything else the mEDBG 32U4 has to do, there are a lot of bytes dropped at 1 Mbaud.  In some quick initial testing, I've seen good results up to 250kbaud.

 

I found that when setting the baud rate to 115,200 in the PC terminal application and working at a real 111,111, I initially needed to enable parity (on the PC terminal application and the atmega328p target).  Once I ran it that way, I was later able to switch back to no parity and get good results.  

 

In your case, with an atmega32U4 for the mEDBG and a SAMD10 target, you could set the SAMD10's baud as close as possible to 111,111.  The SAMD's UART design supports finely adjustable baud rates.  (Setting S=16 and BAUD=63109 results in a baud rate of 111,099, a -0.01% error.) You could also try any of the following rates available from the 32U4. 

 

The following should work:

111,111 briefly tested
125,000
142,857
166,667
200,000
250,000 briefly tested

 

I've seen problems with the 32U4 dropping bytes at higher baud rates. 

 

To get 250,000 baud on the SAMD10 operating at 48MHz, use S=16, BAUD=60075.  This is also accurate to within 0.01%.

 

The following don't work, apparently because the mEDBG firmware for the 32U4 doesn't make use of the double speed mode available by setting the U2X0 bit in the UCSR0A register.

117,647 (This is how Arduino Uno gets 115200.)
133,333
153,846
181,818
222,222

 

Make sure there's nothing buggy going on with parity in the mEDBG processor or virtual COM port driver.  If it looks like there are issues there, switch to either EVEN or ODD parity on both ends, get it working and switch (back) to none if you want to.

 

If you're going to use the .NET framework's system.io.ports.serialport control from C# or VB.NET to work with this, be aware that DtrEnable has to be set to true.  This isn't necessary when working with most other virtual COM port peripheral devices.    

 

 

Last Edited: Thu. Sep 10, 2015 - 12:30 AM
Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4769 View posts
Location: SF Bay area
Posted by westfw: Wed. Sep 9, 2015 - 11:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah.  You know, I would have thought that I had enough Arduino background to recognize the limitations of a 16MHz AVR, but for some reason I guess I was expecting mEDGB to somehow be "magic."

(although to be fair to myself, 115200bps is one of the speeds that the Arduino environment MAKES work, regardless of how out-of-spec it might be.  57600 is usually the complicated rate.)

 

Top
jstampfl
jstampfl's picture
Level: Hangaround
Joined: Wed. Dec 29, 2010
Posts: 423 View posts
Location: Saipan, Northern Mariana Islands, USA
Posted by jstampfl: Thu. Sep 10, 2015 - 12:29 AM (Reply to #4)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Arduino sets the double speed bit:

U2Xn = 1

 

So Arduino uses the same "UBBRn = 16" as is used for 57600.  (I think due to a bug in the ATmega32u4 code.)

 

I think that since 115200 doesn't work on the Arduino Uno with the ATmega32u4 but works on the Chinese versions using the CH340.

 

Top
jstampfl
jstampfl's picture
Level: Hangaround
Joined: Wed. Dec 29, 2010
Posts: 423 View posts
Location: Saipan, Northern Mariana Islands, USA
Posted by jstampfl: Thu. Sep 10, 2015 - 12:32 AM (Reply to #4)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Arduino sets the double speed bit for 115200:

U2Xn = 1

 

So Arduino uses the same "UBBRn = 16" as is used for 57600.  (I think due to a bug in the ATmega32u4 code.)

 

I think that since 115200 doesn't work on the Arduino Uno with the ATmega32u4 but works on the Chinese versions using the CH340.

 

Last Edited: Thu. Sep 10, 2015 - 12:35 AM
Top
chawcs_smartmrt
chawcs_smartmrt's picture
Level: Rookie
Joined: Thu. May 8, 2014
Posts: 33 View posts
Location: Singapore
Posted by chawcs_smartmrt: Thu. Sep 10, 2015 - 01:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I am not sure about the ATmega32u4.

But I had try with the ATmega88PA.

 

From the datasheet,

if I change my external crystal to 11.0592MHz, it can get all the baudrate up to 115200bps.

The orignal design which use 8MHz, it cannot communicate at 115200bps.

No problem for both at 9600bps

 

So try change the crystal or look at the datasheet for no error for the baudrate.

cs

Top
oxijin
oxijin's picture
Level: New Member
Joined: Wed. Sep 9, 2015
Posts: 2 View posts
Posted by oxijin: Thu. Sep 10, 2015 - 03:51 AM (Reply to #7)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think westfw's goal is to get his SAMD10 xplained mini board working with a fast baud rate on it's virtual COM port.  To achieve that, all he has to do (aside from overcoming potential parity related bugs in the mEDBG firmware or driver setup) is set the SAMD10's finely tunable baud rate to match not the requested mEDBG baud rate but the actual baud rate he gets from the atmega32U4 USB mEDBG processor.  The selected rate will be a standard or non-standard baud rate provided via his terminal application, arduino serial monitor or other application.  The actual rate will be what the mEDBG firmware configures its UART for, within the limitations of both the mEDBG processor's UART hardware and its less than complete firmware.  Presumably, the only processors he's dealing with are on the same board so he doesn't need to accurately match a standard baud rate.  Once the data makes it's way from the SAMD to the mEDBG processor (atmega32U4), which he doesn't have much control over, it's all USB.  So it's not the actual baud rate or the accuracy with which it matches a standard baud rate that matters.  It's the accuracy with which the baud rates of the two on board processors match each other that matters in his case.

 

Now when you're trying to interface an ATMEGA based xplained mini, arduino uno or other (atmega based) 16MHz board with other off board hardware designed to operate at standard baud rates, that's a different question.  If the external device uses a crystal and is set up for exactly 115,200 for the nominal crystal frequency, data can in principle be transferred without errors using either the 111,111 or the 117,647 rate available from the atmega.  In practice, this will depend in a big way on the sampling technique used on the external device's UART.  It will also depend on the signal rise and fall times, the characteristics of any serial transceiver used and to a small extent on jitter and noise.  When you take the baud rate error right up to the limit, you become sensitive to all these things.  Thus the trouble with interfacing things like 16MHz Arduino Unos with fixed baud rate crystal clocked external hardware operating at 115,200.  If you don't mind messing with crystals and crystal frequency, it can be a good solution (as long as you don't create new issues by slowing down, speeding up or overclocking the micro).  But for the mEDBG interface to provide selected baud rates, the firmware on the mEDBG processor needs to know what the crystal frequency is, which present a whole new set of issues.

 

Thankfully the UARTS in the SAMD lineup and in Cortex M devices in general tend to be finely tunable, no matter what your crystal frequency... which, as long as you have a dedicated UART, makes the external hardware baud matching problems go away.  Here's the kicker though.  In westfw's case, if he is using the mEDBG virtual COM port to monitor communication between the SAMD and an external 3rd UART, the 16 MHz 32U4 causes problems by operating at baud rates of 111,111 or 117,647 if the external hardware operating at 115,200 doesn't like those rates, which is somewhat likely.  In this case, he could choose a baud rate on the SAMD that's half way between the nominal required by the external hardware and the actual real baud rate on the mEDBG processor.  This reduces the error problem by a factor of two and may allow a scenario where the SAMD can communicate with both the mEDBG interface and the external hardware.  But half of the 3.5% error you get from the 32U4 and it's limited firmware is still pretty huge.  Half of the fundamental limit of error at 16MHz, that's half of 2.1% at 117,647 baud isn't so bad... but you can't get there with the current mEDBG firmware.  

 

It's time for Atmel to support double speed mode in their atmega based mEDBG firmware.  mEDBG almost always supports exclusively shared clock scenarios.  For those cases, there's no down side.  It's also time for Atmel to start using small SAMD11's or 21's rather than atmegas in the mEDBG processor role!

Top
jstampfl
jstampfl's picture
Level: Hangaround
Joined: Wed. Dec 29, 2010
Posts: 423 View posts
Location: Saipan, Northern Mariana Islands, USA
Posted by jstampfl: Wed. Oct 21, 2015 - 02:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AS 7.0.582, ASF 3.27.3   ATMega328PB Xplainedmini. Windows 10, PuTTY for terminal emulator.

The code below, works at 115200 & 1,000,000 baud.
 

/*
 * u328.asm
 *
 *  Created: 12/31/2014 10:33:37 PM
 *   Author: john
 */ 


 
.cseg

.org 0x0000 ;Places the following code from address 0x0000
		jmp RESET ; Reset Handler
		jmp EXT_INT0 ; IRQ0 Handler
		jmp EXT_INT1 ; IRQ1 Handler
		jmp PCINT0L ; PCINT0 Handler
		jmp PCINT1L ; PCINT1 Handler
		jmp PCINT2L ; PCINT2 Handler
		jmp WDT ; Watchdog Timer Handler
		jmp TIM2_COMPA ; Timer2 Compare A Handler
		jmp TIM2_COMPB ; Timer2 Compare B Handler
		jmp TIM2_OVF ; Timer2 Overflow Handler
		jmp TIM1_CAPT ; Timer1 Capture Handler
		jmp TIM1_COMPA ; Timer1 Compare A Handler
		jmp TIM1_COMPB ; Timer1 Compare B Handler
		jmp TIM1_OVF ; Timer1 Overflow Handler
		jmp TIM0_COMPA ; Timer0 Compare A Handler
		jmp TIM0_COMPB ; Timer0 Compare B Handler
		jmp TIM0_OVF ; Timer0 Overflow Handler
		jmp SPI_STC ; SPI Transfer Complete Handler
		jmp USART_RXC ; USART, RX Complete Handler
		jmp USART_UDRE ; USART, UDR Empty Handler
		jmp USART_TXC ; USART, TX Complete Handler
		jmp ADCR ; ADC Conversion Complete Handler
		jmp EE_RDY ; EEPROM Ready Handler
		jmp ANA_COMP ; Analog Comparator Handler
		jmp TWI ; 2-wire Serial Interface Handler
		jmp SPM_RDY ; Store Program Memory Ready Handler
;
RESET:	ldi r16, high(RAMEND); Main program start
		out SPH,r16 ; Set Stack Pointer to top of RAM
		ldi r16, low(RAMEND)
		out SPL,r16
		cli ; disable interupts
		; Set baud rate
		ldi r16,8	   ; 0 = 1,000,000, 3 = 250000 8 = 115200, 16 = 57600, 103 = 9600, 207 = 4800
		sts UBRR0L, r16
		clr r16
		sts UBRR0H, r16
		sts UCSR0A, r16 ; set to zero to be sure

; Enable receiver and transmitter
		ldi r16, 0b0001_1000 ; (1<<RXEN0) | (1<< TXEN0 )  ;
		sts UCSR0B,r16
; Set frame format: 8data, 1stop bit
		ldi r16, 0b0000_0110 ;
		sts UCSR0C,r16

again:
        lds r18, UCSR0A
		andi r18,0b1000_0000
		breq again
		lds r19,UDR0
		sts UDR0,r19
		jmp again



;  ISR

EXT_INT0:
EXT_INT1:
PCINT0L:
PCINT1L:
PCINT2L:
WDT:
TIM2_COMPA:
TIM2_COMPB:
TIM2_OVF:
TIM1_CAPT:
TIM1_COMPA:
TIM1_COMPB:
TIM1_OVF:
TIM0_COMPA:
TIM0_COMPB:
TIM0_OVF:
SPI_STC:
USART_RXC:
USART_UDRE:
USART_TXC:
ADCR:
EE_RDY:
ANA_COMP:
TWI:
SPM_RDY:
	reti


;

 

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Wed. Oct 21, 2015 - 03:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Well, it works if you send singe bytes. Now try to send a continuous string of 100 characters without waiting to receive anything, and observe how EDBG misses all of them.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Last Edited: Wed. Oct 21, 2015 - 03:02 AM
Top
jstampfl
jstampfl's picture
Level: Hangaround
Joined: Wed. Dec 29, 2010
Posts: 423 View posts
Location: Saipan, Northern Mariana Islands, USA
Posted by jstampfl: Wed. Oct 21, 2015 - 03:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, here is a program that sends a string of slightly more than 100 characters.  Seems to work at 115200 & 1,000,000 baud.

 

Same AS 7.0.538, ATMega328PB Xplained Mini.

 

/*
 * utestuno.c
 *
 * Created: 2/6/2015 8:11:39 PM
 *  Author: john
 */ 


#define F_CPU 16000000UL
#include <avr/io.h>
#include <util/delay.h>


unsigned char msg[] = "Hello World! Let's add a few characters to the string.  Will this break the bank, or will it still work ok?\r\n";

void putch(unsigned char ch){
	while ((UCSR0A & (1 << UDRE0)) == 0); //Wait for UDR empty
	UDR0 = ch; //Send byte
}

void print(unsigned char *str){
	for(int i=0;str[i]!=0;i++){
		putch(str[i]);
	}
}

int main (void)
{
	DDRB = (1 << DDB4); //Configure a status LED
	
	UBRR0L = 0;//8 = 115200, 0 = 1,000,000 baud

	UCSR0B = (1 << RXEN0) | (1 << TXEN0); //Turn on RX/TX
	
	while(1)
	{

		print(msg); //Send test message
		_delay_ms(1000);
	}
}

 

Top
jstampfl
jstampfl's picture
Level: Hangaround
Joined: Wed. Dec 29, 2010
Posts: 423 View posts
Location: Saipan, Northern Mariana Islands, USA
Posted by jstampfl: Wed. Oct 21, 2015 - 03:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, here is a program that writes slightly more than 100 characters. It works at 115200 & 1,000,000. baud.

 

AS 7.0.538, ATMega328PB Xplainedmini.  Windows 10, PuTTY.

 

/*
 * utestuno.c
 *
 * Created: 2/6/2015 8:11:39 PM
 *  Author: john
 */ 


#define F_CPU 16000000UL
#include <avr/io.h>
#include <util/delay.h>


unsigned char msg[] = "Hello World! Let's add a few characters to the string.  Will this break the bank, or will it still work ok?\r\n";

void putch(unsigned char ch){
	while ((UCSR0A & (1 << UDRE0)) == 0); //Wait for UDR empty
	UDR0 = ch; //Send byte
}

void print(unsigned char *str){
	for(int i=0;str[i]!=0;i++){
		putch(str[i]);
	}
}

int main (void)
{
	DDRB = (1 << DDB4); //Configure a status LED
	
	UBRR0L = 0;//8 = 115200, 0 = 1,000,000 baud

	UCSR0B = (1 << RXEN0) | (1 << TXEN0); //Turn on RX/TX
	
	while(1)
	{

		print(msg); //Send test message
		_delay_ms(1000);
	}
}

 

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Wed. Oct 21, 2015 - 04:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The only reason it works for ATmega328P is that is is clocked from the external clock, which is synchronous with the clock inside EDBG. You are essentially running USART with implicit clock line.

 

And it seems that AS does not let me switch to internal 8MHz clock. If you figure out how to do that, try 115200 then and be surprised.

 

The original thread is about SAMD10-based board, where there is no external clock signal (or it is not forced, even if it is there).

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4769 View posts
Location: SF Bay area
Posted by westfw: Thu. Oct 22, 2015 - 02:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The original thread is about SAMD10-based board, where there is no external clock signal

Actually, I think at the time I was running the samd10 off of the  medbg-provided 8MHz clock (multiplied/etc.)  Although of course the d10 baud rate generator is much different than the avr baud rate generator.

 

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Thu. Oct 22, 2015 - 02:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Well, yes, running mega-mega with one of the megas providing the clock is like running a single device, internal clock bus simply appears on the output pin on one of the devices.

 

By the time that 8 MHz gets to the SERCOM it was transformed multiple times.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top
jstampfl
jstampfl's picture
Level: Hangaround
Joined: Wed. Dec 29, 2010
Posts: 423 View posts
Location: Saipan, Northern Mariana Islands, USA
Posted by jstampfl: Thu. Oct 22, 2015 - 07:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

 

Sorry, I don't have a D10 Xplained mini.  Maybe you can show some code exhibiting the problem.

 

Thanks

Top
jstampfl
jstampfl's picture
Level: Hangaround
Joined: Wed. Dec 29, 2010
Posts: 423 View posts
Location: Saipan, Northern Mariana Islands, USA
Posted by jstampfl: Thu. Oct 22, 2015 - 07:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The question asked was:

 

"Does anyone know if the mEDBG chip (ATmega32u4 based) used on the Xplained mini eval boards supports baud rates above 57600 in its USB/Serial bridge code?"

 

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Thu. Oct 22, 2015 - 03:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

jstampfl wrote:
Sorry, I don't have a D10 Xplained mini.  Maybe you can show some code exhibiting the problem.
This code, for example: https://github.com/ataradov/mcu-... just change the baudrate to 115200.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Thu. Oct 22, 2015 - 03:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

jstampfl wrote:
"Does anyone know if the mEDBG chip (ATmega32u4 based) used on the Xplained mini eval boards supports baud rates above 57600 in its USB/Serial bridge code?"

But this: "uint64_t br = (uint64_t)65536 * (F_CPU - 16ULL * baud) / F_CPU;" is a distinct initialization code for the D10. The OP also mentioned 48 MHz operating frequency and BAUD register, none of which are present in m238p.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top
jstampfl
jstampfl's picture
Level: Hangaround
Joined: Wed. Dec 29, 2010
Posts: 423 View posts
Location: Saipan, Northern Mariana Islands, USA
Posted by jstampfl: Fri. Oct 23, 2015 - 12:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"mEDBG USB/Serial Baud rates?" So this is the title of the thread? asking about the D10?

 

 

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4769 View posts
Location: SF Bay area
Posted by westfw: Fri. Oct 23, 2015 - 03:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The original poster (ie me) was happy with the explanation back in post #3.

The mEDBG chip is used in the Xplained mini boards (168pb, 328p, 328pb, and SAMD10, at least.)  The chip is an Atmega32u4 running at 16MHz, which means that 115200bps has an error rate of either *3.7% or -2.1%, depending on whether you use the doublespeed clock option.   A 328p, 168pb, or 328pb running with the opposite u2x option is nearly guaranteed to fail, even if there are no other bugs in the 32u4 code.   A SAMD10 is more complicated, because of the different operation of the BRG.

 

On the other hand, the way that it failed made me think that there was some firmware bug, rather than a simple speed mismatch.  Overflow in a calculation or something (115200bps also being the first standard bitrate that exceeds 16bits...)    It's a shame that Atmel is so ... proprietary ... when it comes to their debugger stuff.

 

On the third hand, there have been several mEDBG firmware releases since my original post; it could be worth trying again.

 

Top
jstampfl
jstampfl's picture
Level: Hangaround
Joined: Wed. Dec 29, 2010
Posts: 423 View posts
Location: Saipan, Northern Mariana Islands, USA
Posted by jstampfl: Fri. Oct 23, 2015 - 12:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 I am happy that you are happy. But the forum is for all.  I, for one, am not happy with the explaination "115200 has 3.5% error rate", for the following reasons:

 

1.  on the D10 Xplainedmini, I believe the D10 gets it clock from the 32U4, thus the clocks should be in sync.

 

 

2. I was told that same reason in reference to the Arduino Uno, which uses 16u2. The Arduino software uses the 2x trick to get around the problem.  However, If you use a Chinese version with a Ch340, you can do 115200.  With no problem.  The FTDI also doesn't exhibit this behavior. Leads me to suspect there was a bug in the 16u2 code.

 

3. I have no problem with the mEDBG on the 328PB Xplained mini.  I wonder if you can do 500,000 baud, since 57600 is about as fast as 1MHz clock would allow.

 

 

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Fri. Oct 23, 2015 - 03:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

jstampfl wrote:
1.  on the D10 Xplainedmini, I believe the D10 gets it clock from the 32U4, thus the clocks should be in sync.
48 MHz clock is obtained from 8 MHz input clock multiplied by the PLL and divided by the baudrate generator. By that time clocks are no longer in sync.

 

jstampfl wrote:
However, If you use a Chinese version with a Ch340, you can do 115200.
That is because it is a purpose-designed chip with a fractional divider in the baudrate generation block.

 

jstampfl wrote:
3. I have no problem with the mEDBG on the 328PB Xplained mini.
That is because you are using the easiest clocking configuration.

 

Also, D10 might work better if you specifically tune BAUD register to the actual baudrate of the mEDBG (including 3.5% error) instead of plain 115200. D10 baudrate generator is more flexible and can do that.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top
jstampfl
jstampfl's picture
Level: Hangaround
Joined: Wed. Dec 29, 2010
Posts: 423 View posts
Location: Saipan, Northern Mariana Islands, USA
Posted by jstampfl: Sat. Oct 24, 2015 - 02:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alexru said:

 

referring to the CH340 chip.

That is because it is a purpose-designed chip with a fractional divider in the baudrate generation block.

 What about the FTDI chip?

 

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Sat. Oct 24, 2015 - 03:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Same goes for FTDI. All they can do is convert USB into UART, they would not be worth anything if they could not do it well.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4769 View posts
Location: SF Bay area
Posted by westfw: Sat. Oct 24, 2015 - 08:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, I did some tests with Xplained Mini 168pb boards that I have around, and the Arduino "ASCIITable" application.'

With mEDBG firmware v1.4 (which I think is what is "shipping"), the sketch fails with the app bitrate set to 115200, and succeeds with the app bitrate set to 111200 (and the host-side software set to 115200.)  (Keep in mind that the Arduino code uses U2X for all speeds other than 57600.)

The same holds true for mEDBG firmware v1.a (which is "the latest", included with Atmel Studio 7 (I think.))  v1.a also supports the arduino auto-reset mechanism (at least one of them!) and allows an Xplained Mini loaded with an Arduino bootloader to be uploaded using the Arduino IDE (using the CDC Comm port; no debug capability...)

 

So it DOES appear to be a simple "doesn't quite hit the right bitrate" error, rather than something more obscure.

 

Top
jstampfl
jstampfl's picture
Level: Hangaround
Joined: Wed. Dec 29, 2010
Posts: 423 View posts
Location: Saipan, Northern Mariana Islands, USA
Posted by jstampfl: Tue. Oct 27, 2015 - 02:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting.

 

The code I posted above runs on a ATmegaPB Xplained mini and a ATmegaP Xplained mini at 115200 and 1000000.

 

 

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Tue. Oct 27, 2015 - 03:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

jstampfl wrote:
The code I posted above runs on a ATmegaPB Xplained mini and a ATmegaP Xplained mini at 115200 and 1000000.
And we have explained why it is the case for ATmega and not the case for SAM.

 

In case of ATmega both devices are 3.5% off in actual frequency (in case of 115200), but they are off by the same exact value, since they are clocked from the same exact clock source.

 

It is possible to configure SAM to be off by the same amount to accommodate deficiencies of mEDBG, but then it won't  work with anything else.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top
Who-me
Who-me's picture
Level: Raving Lunatic
Joined: Sun. Mar 25, 2007
Posts: 2336 View posts
Posted by Who-me: Tue. Oct 27, 2015 - 04:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jstampfl wrote:

 

 What about the FTDI chip?

 

 

 

I find the simplest way to manage FTDI, FT2xx and SiLabs CP21xx is using the concept of a Virtual Baud Clock.

This is a Number found by checking the granularity of the BAUD steps: in FTDI & SiLabs FS USB parts, that is 12MHz.

(for FTDI HS Parts it is 24MHz ) (and some newer FT23x )

 

The two nearest to a nominal 115200 are for 12MHz Virtual baud

 12M/104  = 115384.615

 12M/105  = 114285.714

 

or for 24MHz virtual Baud parts (added)

 

 24M/208  = 115384.615

 24M/209  = 114832.535

 

Last Edited: Tue. Oct 27, 2015 - 06:13 AM
Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Tue. Oct 27, 2015 - 04:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

What makes you think that FTDI uses integer divider? I'm pretty sure they have fractional baudrate generator and can achieve much better accuracy.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top
Who-me
Who-me's picture
Level: Raving Lunatic
Joined: Sun. Mar 25, 2007
Posts: 2336 View posts
Posted by Who-me: Tue. Oct 27, 2015 - 05:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:

What makes you think that FTDI uses integer divider? I'm pretty sure they have fractional baudrate generator and can achieve much better accuracy.

Was that question for me ?  I gave a formula, and a Virtual Baud Value, what they actually use does not matter.

 

Try it, and see for yourself.

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Tue. Oct 27, 2015 - 05:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

What is "Virtual Baud Value"? Yes, you gave some formula, but what makes you think that your formula is correct?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top
alexru
alexru's picture
Level: Raving Lunatic
Joined: Wed. Apr 15, 2009
Posts: 8059 View posts
Location: San Jose, CA
Posted by alexru: Tue. Oct 27, 2015 - 05:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

And actually FTDI AN232B-05 confirms that they do use fractional divider. And the formula for calculating the divisor is 3000000 / BAUD.

 

You can set the divisor to values N + 0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75 or 0.875.

 

So in this case 3000000 / 115200 = 26.042. The closest fractional part is still 0.

 

But the next frequency down is achieved at 26.125, which gives ~114832.535 baud.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Top
Who-me
Who-me's picture
Level: Raving Lunatic
Joined: Sun. Mar 25, 2007
Posts: 2336 View posts
Posted by Who-me: Tue. Oct 27, 2015 - 06:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:

What is "Virtual Baud Value"? Yes, you gave some formula, but what makes you think that your formula is correct?

If you look at your own equations, you will see a Step of 1/8 in 3 MHz, thus you have a virtual Baud value of 24MHz, which was one of the  numbers I quoted. 

 

Voila:

24M/ 209 = 114832.535

 

* I've expanded the formula examples above for both 12MHz and 24MHz virtual baud values.

If you want to know the next-supported Baud Value, the Virtual Baud Value allows you to skip messing with fractions 

 

Last Edited: Tue. Oct 27, 2015 - 06:25 AM
Top
Avrnaut
Avrnaut's picture
Level: New Member
Joined: Wed. Apr 6, 2016
Posts: 7 View posts
Posted by Avrnaut: Wed. Apr 20, 2016 - 02:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dealing with the same problem originally posted by westfw...

I am using a just delivered SAMD10 Xplained MINI from MOUSER.

I want a baud rate of 115200... because the mEDBG USB/Serial port speed is off this value... started to move the bauds in the SAMD10 code.

Found (in my Xplained MINI) a working range . I will choose 124000 bps to keep from the bauds with erratic results.

 

Matching_ mEDBG_115200

 

 

Last Edited: Wed. Apr 20, 2016 - 03:15 AM
Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4769 View posts
Location: SF Bay area
Posted by westfw: Wed. Apr 20, 2016 - 08:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I will choose 124000 bps to keep from the bauds with erratic results.

 I guess.   If the analysis that we're running into the limits of the mEDBG chip (a 32u4 running at 16MHz), then it's 125000bps that is an "exact match."

 

Top