Curiosity Nano USART and CDC

Log in or register to post comments
Go To Last Post
36 posts / 0 new
Author
Message
Altazi
Altazi's picture
Level: Hangaround
Joined: Sat. May 4, 2013
Posts: 148 View posts
#1
Posted by Altazi: Tue. Feb 23, 2021 - 02:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello All,

 

I have been working with the Curiosity Nano in order to familiarize myself with the new architecture.  After much trouble, I finally got Studio to recognize the tool, and am able to program the device.

 

I am trying to establish UART communication between the Nano and the host PC via the Nano's CDC UART capability.  I have written code that tests the connectivity between Tera Term on the host PC through to the Nano's port C USART1 RXD pin, and verified it with an oscilloscope - the data is getting to port C bit 1, and it looks OK, voltage and timing (115.2kbaud).  However, I am not seeing the data in the UART1 RX data register, nor am I getting to the breakpoint set at the USART1 RXD interrupt entry.

 

I have gone over the USART set-up information in the user manual, and everything looks as it should - as far as I know.  Are there any tricks to getting this to work?

 

Thanks!

 

Altazi

Attachment(s): 

PDF icon Curiosity Studio Capture.pdf
This topic has a solution.

Tags:

AVR Microcontrollers, AVR and XMEGA, solved
Last Edited: Thu. Feb 25, 2021 - 02:27 AM
Top
Altazi
Altazi's picture
Level: Hangaround
Joined: Sat. May 4, 2013
Posts: 148 View posts
Posted by Altazi: Tue. Feb 23, 2021 - 02:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

* I should also add that I cannot get the Nano to transmit anything - despite the fact that the TXDATAL register holds a $3E '>' character, which is the final character after some long text strings.

 

Top
kabasan
kabasan's picture
Level: Resident
Joined: Mon. May 22, 2017
Posts: 914 View posts
Location: Japan
Posted by kabasan: Tue. Feb 23, 2021 - 04:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have confirmed with my AVR128DA32 that it works fine with a setup similar to your code.

There doesn't seem to be anything missing about the USART setup.

 

Is your system clock definitely 24MHz?

Make sure you have changed from the default 4MHz.

 

TXCIF is set in your screen capture.

This indicates that the byte has been sent at least once.

It is normal for the data to remain in TXDATAL after transmission.

 

Since RXCIF is not set, it seems certain that nothing is coming to the RXD pin.

Top
kabasan
kabasan's picture
Level: Resident
Joined: Mon. May 22, 2017
Posts: 914 View posts
Location: Japan
Posted by kabasan: Tue. Feb 23, 2021 - 04:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I forgot one.
Is PC0 set as an output?

Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 3327 View posts
Posted by curtvm: Tue. Feb 23, 2021 - 06:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If your clock is too slow (baud register value too high for the speed in use), you may be getting the start bit rejected. If you are at 4MHz but baud calculated for 24MHz, a start bit is taking 1/6 of the time it the uart thinks it should and if the data byte sent doesn't end up triggering the start bit detection (0|0000?...), no rxc. Send a 0x00 and you could verify- that would get you 9 low bits and somewhere around the 5th/6th bit the start bit will be detected and will at least see something in rx (and rxc set).

 

I doubt the rx pin was disabled (input disable) as that takes work to do, so rx pin probably fine as-is (default input). Not much else can go wrong once a signal is at the pin and rxen is set.

Top
Altazi
Altazi's picture
Level: Hangaround
Joined: Sat. May 4, 2013
Posts: 148 View posts
Posted by Altazi: Tue. Feb 23, 2021 - 07:08 AM (Reply to #3)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for your prompt response.  I have confirmed that the system clock is 24MHz.  TXCIF is set because a series of text messages were sent as part of the program start-up - although nothing showed up on the Tera Term window.  The lack of received data in the RXDATAL register is the problem.  I have confirmed that the RX signal is present on port C bit 1, and that the baud rate is correct, but USART1 is apparently not 'seeing' it.

 

I must be missing something. . . I will probably kick my self when I figure it out.  If I figure it out.

 

Altazi

Top
kabasan
kabasan's picture
Level: Resident
Joined: Mon. May 22, 2017
Posts: 914 View posts
Location: Japan
Posted by kabasan: Tue. Feb 23, 2021 - 07:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I feel like there's some trap on the USB-serial bridge side, but unfortunately I don't have a Curiosity Nano so I can't track it any further.

Top
meslomp
meslomp's picture
Level: Raving Lunatic
Joined: Wed. May 2, 2007
Posts: 6413 View posts
Location: Nieuwegein, Netherlands
Posted by meslomp: Tue. Feb 23, 2021 - 07:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

forgot to enable something?

Top
kabasan
kabasan's picture
Level: Resident
Joined: Mon. May 22, 2017
Posts: 914 View posts
Location: Japan
Posted by kabasan: Tue. Feb 23, 2021 - 07:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For example, set the AVR PC0 and PC1 as inputs, boot, and then short them with tweezers.
Characters from TeraTerm should echo if the bridge is working properly.

Top
kosthala
kosthala's picture
Level: Rookie
Joined: Mon. Mar 30, 2015
Posts: 34 View posts
Location: Athens
Posted by kosthala: Tue. Feb 23, 2021 - 07:36 AM (Reply to #9)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 3327 View posts
Posted by curtvm: Tue. Feb 23, 2021 - 08:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can also manually mirror the rx1 to tx1 pin just to make sure you can do input/output on these pins, although would be odd if not able to do this. The input disable set (ISC bits) or not set to input (dir=0) can make rx1 not work, and tx1 just needs dir=1 to work.   edit- and also the portmux has to be correct of course, but these are on the default pins so unless portmux was changed...

 

It may also be easy to mix up these pins and end up setting rx1 to output and tx1 to input, which could also cause a problem for both. As seen below using 1<<0 and 1<<1 is something than could easily get mixed up.

 

#define TX1bm (1<<0)
#define RX1bm (1<<1)
PORTC.DIRSET = TX1bm; //tx1, pc0, output
PORTC.PIN0CTRL = 0;   //should already be 0
PORTC.DIRCLR = RX1bm; //rx1, pc1, input
PORTC.PIN1CTRL = 0;   //should already be 0

while(1){
    //manually mirror rx1 to tx1
    if( PORTC.IN & RX1bm ) PORTC.OUTSET = TX1bm;
    else PORTC.OUTCLR = TX1bm;
}

Last Edited: Tue. Feb 23, 2021 - 10:15 AM
Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 22478 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Tue. Feb 23, 2021 - 08:51 AM (Reply to #10)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good general point, but OP says in #1 that he's verified with a scope that the data is reaching the microcontroller pin.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 22478 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Tue. Feb 23, 2021 - 08:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Altazi wrote:
the Curiosity Nano

Which Curiosity Nano? There are several.

 

EDIT

 

Oh, it's hidden in the PDF attachment:

 

So much easier when you put the image in the post - where we can see it - see Tip #1 in my signature for how-to.

 

The AVR128DA48 has the pin multiplexing,  so the UART RX can connect to one of many pins, and the UART TX can connect to one of many pins - are you sure you have the multiplexing set correctly ?

 

See the datasheet section  3, "I/O Multiplexing and Considerations"

 

EDIT 2

 

Clarify that both RX and TX pin assignments are configurable

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Feb 23, 2021 - 09:01 AM
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101861 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Feb 23, 2021 - 10:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Altazi wrote:
I have written code that tests the connectivity between Tera Term on the host PC through to the Nano's port C USART1 RXD pin
Surely that is the wrong direction? Your initial test should be to send out from the AVR toward the PC. Not to try and receive something from it. If you are in control of what the AVR produces o nits TXD pin you can then scope that to check for activity and pulse width. If you set the AVR to transmit at 9600 baud for example you should see the pulses as 104us. Of course the high-low transitions on TXD will be different according to what you transmit which is why the capital-U is a perfect test sample. It just happens to have a bit pattern, with statr and stop bit framing, that is 10101010101 so it's very easy to use the scope to measure the width of a 0 or a 1 and check it is 104us. Until you get that working you can't really proceed.

 

The bit width at 115,200 baud is 8.7us but 9600/(104us) is a common choice when first testing things out. When you get the pulse width right with that one it should work equally well when you trade up to 115200 (clock errors permitting!).

Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 22478 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Tue. Feb 23, 2021 - 10:16 AM (Reply to #14)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Surely that is the wrong direction? Your initial test should be to send out from the AVR toward the PC.

Absolutely - totally agree.

 

However, in this case, he did say that he's tested with a 'scope at the AVR pin and can see the signal arriving there.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101861 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Feb 23, 2021 - 10:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
with a 'scope at the AVR pin and can see the signal arriving there.
Yes but that does not prove the TIMING of the AVR does it? As it says somewhere close to here "99.9% of UART errors are AVRs not being clocked right" ;-)

 

If you get the AVR to put out data at what it "thinks" is 9600 but the pulses are not 104us then your assumption about the CPU clock speed are wrong.

 

For example 24MHz has been mentioned but I thought these new, Xmega style AVRs, defaulted to a /6 clock divisor. So if you based your baud rate on an assumed 24MHz but it's really 4MHz then that would be wrong.

Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 22478 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Tue. Feb 23, 2021 - 10:27 AM (Reply to #16)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
that does not prove the TIMING of the AVR does it?

True, but he did say that the timing "looks right"

 

EDIT

 

of course, his assessment of what "looks right" could be wrong, but then you'd at least expect something to be received - even if garbage and with error flags - rather than nothing at all?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Feb 23, 2021 - 10:30 AM
Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30664 View posts
Location: Wormshill, England
Posted by david.prentice: Tue. Feb 23, 2021 - 10:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I might have lost the plot somewhere.

 

If you want to use the in-built CDC on the Curiosity board you write to USART3 on the PORTB pins e.g.

#elif defined(__AVR_ATmega4809__) //Curiosity:USART3,PORTB. SDA=PC2,SCL=PC3. XPRO:USART1,PORTC. SDA=PC2,SCL=PC3
...
#elif defined(__AVR_AVR128DB48__) //Curiosity:USART3,PORTB. SDA=PA2,SCL=PA3
...

Obviously you need to read the part number printed on your Curiosity board.

And download the appropriate PDF file e.g. ATmega4809 Curiosity Nano Getting Started

 

This will tell you which pins are connected to the debugger:

Table 4-4. Onboard Debugger Connections
ATmega4809
Pin
Debugger Pin Function Shared Functionality
PB1 CDC TX UART RX (ATmega4809 RX line) Edge connector
PB0 CDC RX UART TX (ATmega4809 TX line) Edge connector
UPDI DBG0 UPDI
PF3 DBG1 GPIO Edge connector
PF2 DBG2 GPIO Edge connector
PF6 DBG3 RESET/GPIO User switch
VCC_TARGET VCC_LEVEL 1.8-5.1V Supply
GND GND Common ground
 

David.

Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 22478 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Tue. Feb 23, 2021 - 10:45 AM (Reply to #18)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
This will tell you which pins are connected to the debugger

Indeed - it tells you the hardware connections on the board.

 

In addition to that, you also have to get the internal multiplexing within the chip correct.

 

For the SAM XPlained boards, there are #defines for the necessary mux settings - presumably the same applies to AVR & Curiosity ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 3327 View posts
Posted by curtvm: Tue. Feb 23, 2021 - 10:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

> If you want to use the in-built CDC on the Curiosity board you write to USART3 on the PORTB pins

 

Its a 128da48 as seen in the screenshot. Its curiosity board is using port c0/c1 which are default uart1 pins. He has a uart signal on the pc1/rx1 pin (from cdc tx) so the signal is at the already correct pin. My money is on a mixup setting the pins- tx set to input, rx set to output.

Top
Bronze Markdavid.prentice
david.prentice's picture
Level: 10k+ Postman
Joined: Sat. Feb 12, 2005
Posts: 30664 View posts
Location: Wormshill, England
Posted by david.prentice: Tue. Feb 23, 2021 - 02:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My apologies.   I rather assumed that the 128DA48 would have similar hardware CDC connections to the 4809 and 128DB48 Curiosity Boards.

 

I have subsequently downloaded the DA User Guide and sure enough,   it use PC0, PC1 and USART1.

 

It should still work like the 128DB48 board.   i.e. Use a Serial Terminal with DTR and write to USART1.  

 

David.    (who should read first before putting his foot in it)

Top
Altazi
Altazi's picture
Level: Hangaround
Joined: Sat. May 4, 2013
Posts: 148 View posts
Posted by Altazi: Tue. Feb 23, 2021 - 04:33 PM (Reply to #10)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you, kosthala, this may be it.  I was referring to the Nano schematics, but not the user guide.  My bad.

 

In my defense, I have done the CDC UART connection with the Xplained Pro 128A1U board, and it worked fine without flow control enabled.  So I wasn't expecting to need hardware flow control with the Nano, either.

 

Now I can continue my debugging and testing.

 

Altazi

Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 22478 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Tue. Feb 23, 2021 - 04:44 PM (Reply to #22)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Altazi wrote:
Thank you, kosthala, this may be it.

Seems unlikely - if that were the problem, you wouldn't be getting anything at all through the USB CDC ?

 

Pretty sure that this works the same on all the different *EDBG version - including XPlained Pro

 

it worked fine without flow control enabled

Flow control is usually on RTS/CTS; not DTR - so your terminal probably just asserts it by default

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Top
mraardvark
mraardvark's picture
Level: Hangaround
Joined: Mon. Nov 21, 2016
Posts: 197 View posts
Location: Trondheim, Norway
Posted by mraardvark: Tue. Feb 23, 2021 - 05:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

nEDBG uses DTR to enable it's level shifters. Without that you would not have seen anything reach the AVR.
Single-voltage boards (+many XPRO) probably behave differently.

Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 22478 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Tue. Feb 23, 2021 - 05:13 PM (Reply to #24)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mraardvark wrote:
Single-voltage boards (+many XPRO) probably behave differently.

IIRC, XPro use it to turn the interface signals on or off (hi-Z) - so that you're free to use the UART pins "locally" when there's nothing connected on the PC end of the USB

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Top
mraardvark
mraardvark's picture
Level: Hangaround
Joined: Mon. Nov 21, 2016
Posts: 197 View posts
Location: Trondheim, Norway
Posted by mraardvark: Tue. Feb 23, 2021 - 05:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
IIRC, XPro use it to turn the interface signals on or off (hi-Z) - so that you're free to use the UART pins "locally" when there's nothing connected on the PC end of the USB

Makes sense.
Which also means that without DTR you would not see anything incoming.

Anyhow - it appears that the problem has 'gone away' :)

Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 22478 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Tue. Feb 23, 2021 - 05:39 PM (Reply to #26)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mraardvark wrote:
Which also means that without DTR you would not see anything incoming.

Indeed.

 

 it appears that the problem has 'gone away' 

I think the OP may be back, having realised it hasn't gone away ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Top
Altazi
Altazi's picture
Level: Hangaround
Joined: Sat. May 4, 2013
Posts: 148 View posts
Posted by Altazi: Tue. Feb 23, 2021 - 08:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Haha!  Not out of the woods yet.  Using hardware flow control in Tera Term was the biggest impact.  Now my Nano is 'talking' just fine, sending long strings of text via an interrupt driven TX routine using circular buffers.

I am not yet getting RX interrupts, despite the fact I can see the received character in RXDATAL, the RXCIF flag is set, and the RXCIE bit is set . . .

 

Sigh.

Top
Altazi
Altazi's picture
Level: Hangaround
Joined: Sat. May 4, 2013
Posts: 148 View posts
Posted by Altazi: Tue. Feb 23, 2021 - 09:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is what I see:

 

- RXDATAL contains $33 - OK as I typed a '3' on the keyboard

- RXCIE is set (enabled receive complete interrupt)

- RXCIF flag is set, indicating receive complete

 

Despite all of this, the breakpoint shown wasn't reached when I entered the character.

 

I'm running out of ideas . . .

 

Altazi

Attachment(s): 

PDF icon Curiosity Studio Capture.pdf
Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 22478 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Tue. Feb 23, 2021 - 09:41 PM (Reply to #29)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Again, it's easier if you put your screenshot in your post as a picture - not a PDF attachment.

 

See #13

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Top
mraardvark
mraardvark's picture
Level: Hangaround
Joined: Mon. Nov 21, 2016
Posts: 197 View posts
Location: Trondheim, Norway
Posted by mraardvark: Tue. Feb 23, 2021 - 10:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Altazi wrote:
I'm running out of ideas . . .

Go out for a walk/run and come back and look at it again?  (quite often works for me :)

Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 3327 View posts
Posted by curtvm: Tue. Feb 23, 2021 - 11:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since you are in asm, its probably easy to end up using a ret instead of a reti. Even though the global interrupts are not disabled when an interrupt fires, you do have a LVL0EX bit that gets set which only gets cleared via a reti. Miss one reti and your interrupts are effectively disabled- you cannot get to another interrupt while LVL0EX is set and you cannot clear LVL0EX until you get a reti, catch 22. There is also LVL1EX, so that could still run if being used, but if the reti was missed in that isr then that will block all interrupts.

 

Learn C  :)

 

https://godbolt.org/z/7n8erM

 

 

original post-

>the data is getting to port C bit 1, and it looks OK, voltage and timing (115.2kbaud).  However, I am not seeing the data in the UART1 RX data register, nor am I getting to the breakpoint set at the USART1 RXD interrupt entry.

 

And how did we get from a signal on the rx pin but no rxc, to it now apparently working. It was not due to anything external as the signal was at the pin (that was the claim anyway). Everyone gets to guess at the problem, but then it is glossed over and you move to the next problem. The people giving answers need to add to their inventory of solutions, so its nice to know what the solution was.

Last Edited: Wed. Feb 24, 2021 - 01:00 AM
Top
Altazi
Altazi's picture
Level: Hangaround
Joined: Sat. May 4, 2013
Posts: 148 View posts
Posted by Altazi: Wed. Feb 24, 2021 - 03:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:

Since you are in asm, its probably easy to end up using a ret instead of a reti. Even though the global interrupts are not disabled when an interrupt fires, you do have a LVL0EX bit that gets set which only gets cleared via a reti. Miss one reti and your interrupts are effectively disabled- you cannot get to another interrupt while LVL0EX is set and you cannot clear LVL0EX until you get a reti, catch 22. There is also LVL1EX, so that could still run if being used, but if the reti was missed in that isr then that will block all interrupts.

There are no mistaken 'RET's where there should be a 'RETI'.  In fact, there is a properly functioning periodic timer interrupt hitting every 1.953ms.

Quote:

Learn C  :)

I dislike C

Quote:

 

original post-

>the data is getting to port C bit 1, and it looks OK, voltage and timing (115.2kbaud).  However, I am not seeing the data in the UART1 RX data register, nor am I getting to the breakpoint set at the USART1 RXD interrupt entry.

 

And how did we get from a signal on the rx pin but no rxc, to it now apparently working. It was not due to anything external as the signal was at the pin (that was the claim anyway). Everyone gets to guess at the problem, but then it is glossed over and you move to the next problem. The people giving answers need to add to their inventory of solutions, so its nice to know what the solution was.

 

Configuring Tera Term for hardware flow control resulted in the Nano being able to TRANSMIT data.  The RX data is getting into the RXDATAL register, but no receive interrupt is occurring.  The problem appears to be related to the lack of interrupt actions.  As you can see, the RXCIE bit is set, the RXCIF flag indicates the presence of a character in RXDATAL, and global interrupts are enabled.

Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 3327 View posts
Posted by curtvm: Wed. Feb 24, 2021 - 04:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was just wondering how we got from this (which also showed a screenshot with no rxc flag set)-

 

> However, I am not seeing the data in the UART1 RX data register

 

to this (rxc flag is now set)-

 

>The RX data is getting into the RXDATAL register, but no receive interrupt is occurring.

 

If the data was at the C1 pin as the original post said, then any terminal setting changes did not cause the mcu's uart start to accept data that was already there previously.

 

 

 

>I dislike C

 

You can still use it when it could help troubleshoot. Take the simple example in #32, change f_cpu/mybaud to suite, compile/upload it and see if you can get the terminal to echo chars. Either it works, and you confirm the rxc irq/isr system works or it also doesn't work for some reason. In any case it only requires 5 minutes of work.

Top
Altazi
Altazi's picture
Level: Hangaround
Joined: Sat. May 4, 2013
Posts: 148 View posts
Posted by Altazi: Wed. Feb 24, 2021 - 04:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:

I was just wondering how we got from this (which also showed a screenshot with no rxc flag set)-

 

> However, I am not seeing the data in the UART1 RX data register

 

to this (rxc flag is now set)-

 

>The RX data is getting into the RXDATAL register, but no receive interrupt is occurring.

 

If the data was at the C1 pin as the original post said, then any terminal setting changes did not cause the mcu's uart start to accept data that was already there previously.

 

The RXDATAL register contained $FF when Tera Term wasn't configured for hardware flow control.  It seems that the USART receives ONE character and no more.  Even though I saw the data with the scope, it wasn't being received.  Once I set hardware flow control. the USART still receives only one character, but at least it is the correct value.

Top
Altazi
Altazi's picture
Level: Hangaround
Joined: Sat. May 4, 2013
Posts: 148 View posts
This reply has been marked as the solution. 
Posted by Altazi: Wed. Feb 24, 2021 - 10:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mystery solved.  All interrupts are working now.  There were two problems, ultimately. One was Tera Term not being configured for hardware flow control.  The other was the interval timer interrupt.

 

The PIT timer interrupt was configured for a 1.952ms period.  The interrupt was occurring, and processing things properly.  BUT . . . the PI interrupt flag wasn't being cleared.  As soon as the interrupt routine exited, it immediately re-entered.  Thus, a 1.952ms interrupt was occurring every 3.3us - there was no time for any other processing.  It seems that the PIT timer is one of the peripherals where you need to MANUALLY clear the interrupt flag.  Once I fixed this, everything began working as expected.

 

I have been taking operational XMEGA32E5 code and porting it to the AVR128DA48.  This was one of the 'gotchas'.

 

Thank you all for your help.

 

Altazi

Top