ATtiny4313 USART issue after some days.

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

Hello,

I am working on ATtiny4313 for my project.

In my project i will be using USART to display few commands on terminal, immediate after code everything will be working fine i will be getting commands on terminal but after some time say after a day or a two,everything else works proper except USART it won't display anything on terminal.

Little strange issue but i am not sure what exactly causing the problem.

 

Please someone suggest me on this to solve it.

 

Regards & Thanks,

Chetan Hiremath

Last Edited: Tue. Jan 16, 2018 - 08:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

chetanhiremath wrote:
suggest me on this to solve it

To solve a problem, you first have to identify what the problem is.

 

The first step must be a review of your code - in particular, look for things that can "accumulate", and are not being (properly) reset ...

 

The ATtiny4313 has on-chip debug - so use it!

 

Is it related to any "environmental" conditions/changes/events ?

 

USART it won't display anything on terminal

So is that because the USART is sending nothing, or because the USART is sending "invisible" stuff, or because the terminal stops working, or ... ?

 

everything else works proper 

How do you determine that?

What is, "everything else" - and what constitutes "works proper" ?

 

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

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Are you running on an external crystal?

"This forum helps those that help themselves."

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

 

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

 

You really do need to determine, at the very start, what is changing. For us, "it won't display on terminal" is woefully inadequate. Lets consider a list of possible things:

 

1. The UART actually DOES NOT send anything, at all. This will be a problem in your code.

 

2. The UART sends the right thing, but at the wrong speed. This is usually a clock problem and usually comes from trying to use the internal clock rather than a crystal.

 

3. The UART sends the wrong thing and the terminal cannot interpret what it hears as printable characters. This is usually a problem with your code.

 

4. There is a problem with the electrical connection between your micro and the terminal.

 

5. There is a problem with the terminal.

 

Now is the time to learn how to use the debugger!

Jim

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

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

ka7ehk wrote:
2. The UART sends the right thing, but at the wrong speed. This is usually a clock problem and usually comes from trying to use the internal clock rather than a crystal.

 

3. The UART sends the wrong thing and the terminal cannot interpret what it hears as printable characters. This is usually a problem with your code.

These will usually show up as "garbage" on a terminal - similar to this:

Baud Mismatch

See: https://learn.sparkfun.com/tutorials/serial-communication - about 2/3 down the page.

 

 

However, as noted in #2, it could happen to be "invisible"

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

Hi,

 

Sorry for not explaining the problem properly.

 

In my application with attiny4313 i will be controlling two 7-Segment LED drivers on which i want to display some data and the data i will receive from UART terminal.

 

I am setting the clock to 1Mhz and baud rate to 9600 and using 4Mhz external Crystal oscillator.

 

After some time I am not seeing any data on the terminal with the same baud rate, but 7-segment display is glowing and working fine as per my code.

 

Immediate after flashing the code everything is working fine, I am facing problem after testing for sometime.

 

Sorry that I am unable to mention what exact time I am getting the problem as it is fluctuating every time.

 

 

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

Post your code, schematic and photo of your actual setup.
.
There are several rules of thumb for designing digital circuits and laying out pcb.
.
David.

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

Hi David,

 

Please find the attached documents as you asked.

 

 

Regards & Thanks,

Chetan

Attachment(s): 

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

chetanhiremath wrote:

I am setting the clock to 1Mhz ...and using 4Mhz external Crystal oscillator.

 

That statement does not make sense.

 

Either you are running at 1MHz on the internal RC Oscillator OR you are running at 4MHz with an external crystal. Which is is?

 

If you think you are running with a 4MHz external crystal how have you proved that? What are your fuses set to?

 

 

 

chetanhiremath wrote:

I am setting the clock to 1Mhz and baud rate to 9600 ...

 

If you are running at 1MHz then what baud rate error does the datasheet tell you that you will have?

 

 

[E2A]

And, as I think you are really running at 1MHz on the internal RC oscillator....how stable is that oscillators's frequency?

 

 

"This forum helps those that help themselves."

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

 

Last Edited: Wed. Jan 17, 2018 - 09:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

chetanhiremath wrote:
Hi, using 4Mhz external Crystal oscillator.

The schematic shows just an external crystal - not an external oscillator.

 

If you don't understand the difference, see: http://www.avrfreaks.net/comment...

 

and note the correct spelling of "MHz" ...

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

Brian Fairchild wrote:
as I think you are really running at 1MHz on the internal RC oscillator....how stable is that oscillators's frequency?

especially with all those LEDs and all those drivers, I imagine it would warm up with time ...

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

How are the fuses configured?

David (aka frog_jr)

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

Your source code says:

#define F_CPU 1000000
...
void usartInitialisation(void) {
	/* Set baud rate */
	//UBRRH = (unsigned char)(MYUBBR>>8);
	//UBRRL = (unsigned char)MYUBBR;
	UCSRA = (1<<U2X);
	UBRRH = 0;
	UBRRL = 12;
	
	/* Enable receiver and transmitter */
	UCSRB = (1<<RXEN) | (1<<TXEN);
	
	/* Set frame format : 8 data, 1 Stop bit */
	UCSRC = (1<<UCSZ0) | (1<<UCSZ1);
}
...

So you must be running on 1MHz RC with 9600 baud.

This should be fine if you have stable power.   I suggest that you view the VCC with a scope.

The crystal would give you a more accurate 1MHz than the 1MHz RC.   But with unstable VCC both RC and crystal would be suspect.

 

Looking at your schematic and pcb layout,   you have large LED currents.     I would be happier with additional ceramic capacitors in your power regulators.    Electrolytic capacitors are not sufficient.

 

David.

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

Sorry for the few mistakes I have done and thanks for correcting me.

 

Yes, using 8MHz internal RC oscillator iFuse=64, running code at 1MHz and set baudrate accordingly to 9600.

 

baudrate setting:

UCSRA = (1<<U2X);

UBRRH = 0;

UBRRL = 12

 

especially with all those LEDs and all those drivers, I imagine it would warm up with time ...

 

I am not powering up board continuously for more than 30 mins, also when UART stops responding will flash code again and board starts working fine.

Last Edited: Wed. Jan 17, 2018 - 10:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How are the fuses configured?

Fuse values are, hFuse=DFh,iFuse=64h,eFuse=FFh.

 

 

 

Looking at your schematic and pcb layout,   you have large LED currents.     I would be happier with additional ceramic capacitors in your power regulators.    Electrolytic capacitors are not sufficient.

Hi David,

 

Thanks for the above suggestion, i will replace with ceramic capacitors and come up with results.

 

 

 

 

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

You have 8MHz RC with CLKDIV8 giving 1MHz

You have not enabled the Brown Out Detection.   This is unwise.

 

No,  you don't replace the electrolytics,  you add ceramic capacitors.

 

David.

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

Yes, I have not replaced electrolytics, just added ceramic capacitors.

 

You have not enabled the Brown Out Detection.   This is unwise.

 

As i am new to Atmel boards, i wasn't aware of this, please let me know what value would be suitable for BOD.

 

 

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

If your tiny4313 is running at 5V,  set the BOD to 4V.

 

This will probably reveal any power supply glitches.    But your scope would show you where and how your problems occur.

 

Can you control the average LED currents in software?   Reduce the brightness of the LEDs.   You will still get switching transients but the average currents will be smaller.   Less likely to cause Brown-Outs.

 

David.

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

For external 4MHz xtal, BOD=4.3v, clock/8 disabled, fuses should be set to:  H:D9 L:FD E:FF according to http://www.engbedded.com/fusecalc/

Note you will need to change line in code that sets F_CPU to 4000000UL for correct baud rate calc, and if any timers are used, may need a different pre-scale or settings to maintain current operations with 4x clock speed.

 

Jim

 

 

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

Are you saying 9600 @1MHz? That has a -7.0% error??

EDIT damn mobile phones, i see the U2X now so that should be OK.

Last Edited: Wed. Jan 17, 2018 - 03:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
UCSRA = (1<<U2X);

I think you missed this!

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

The OP's problem is simple...he's running off the 1MHz RC oscillator which, although factory calibrated, is calibrated at 3V and 25degC. He's running at 5V and it's inside a box so all bets as to the actual frequency are off.

"This forum helps those that help themselves."

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

 

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

I disagree. Most ascii letters are going to be detected. Yes, there will be some Framing errors.
My money is on bad VCC.

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

chetanhiremath wrote:
also when UART stops responding will flash code again and board starts working fine.

I didn't get the meaning of "flash code"

İs it reprogramming the mcu?

Majid

Last Edited: Wed. Jan 17, 2018 - 06:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

chetanhiremath wrote:

also when UART stops responding will flash code again and board starts working fine.

 

m.majid wrote:
I didn't get the meaning of "flash code"

İs it reprogramming the mcu?

That is the usual meaning.

 

@chetanhiremath: What happens if you just force a hard reset without re-flashing the code?

 

What is your process for re-flashing the code - is it just a quick ISP, or do you open the box, remove the chip, etc ... ?

 

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

Floating GND between Computer and PCB may cause this problem, not connection or loose connection GND

When programming MCU the GND connection establishes via programmer and works fine
After disconnecting programmer, probably bad connection of GND of serial port cause not to see data

J3 in PCB is 4 pin
İn photo seems 9 pin D-connector true?

I suggest recheck the connection between 9 pin D-connector and J3 of PCB, be sure GND is steady and true

Majid

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

Yes, reprogramming the MCU.

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

What happens if you just force a hard reset without re-flashing the code?

Even if I do the hard reset, result is same LEDs work properly as they glow according to code but will get nothing on the serial terminal.

 

 

What is your process for re-flashing the code - is it just a quick ISP, or do you open the box, remove the chip, etc ... ?

I will open the box, inside I have a PCB with programming pins i don't need to remove IC , just need to connect ISP to programming pins and flash the program.

 

 

 

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

Brian Fairchild wrote:
The OP's problem is simple...he's running off the 1MHz RC oscillator

Should be easy to test this hypothesis - just use an external oscillator, and see if the problem persists.

 

Tracking down intermittent problems like this is bad enough without having gross sources of doubt & uncertainty like an RC oscillator!!

 

EDIT

 

The schematic & PCB layout show that a crystal is already supported in the designed - so why on earth would you not use it?!

 

surprise

 

Last Edited: Thu. Jan 18, 2018 - 09:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

This is the only comment I have for people who use RC oscillators with uarts.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

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

It seems really weird that flashing the program would make a difference that resetting doesn't make. What else changes when flashing?

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

What happens if you just force a hard reset without re-flashing the code?

chetanhiremath wrote:
Even if I do the hard reset, result is same LEDs work properly as they glow according to code but will get nothing on the serial terminal.

 

 

What about a power-cycle?

 

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

Hello,

 

Sorry as i took much time for testing, below are the results of my testing.

 

We have tested the board by feeding 5V to IC directly(by passed the driver to convert 12 v to 5v, given directly 5v to IC) and tested the board continuously for  3 days.

 

1)I have changed the code little bit just by adding a counter and delay of 1 sec in while loop and printing the count on terminal every sec once.

2)No voltage dip occured through out the testing.

3)After 2 days uart stopped responding, after that i flashed code again to IC but there is no response from UART even after flashing the code.

4) I have read the code from flash memory when code stooped working , .HEX file which i am loading and what i read back from IC are totally different, i guess code got corrupted.

 

 

Please suggest me on the above , if any other input is required from myside , please let me know.

 

 

Regards & Thanks,

Chetan

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

The hex files won’t be the same - the compiler only generates hex records for the data it wants to store. When you dump the flash to hex, it has a direct image. The major difference will be the unused areas that default to 0xff.
The old dos cmd debug allowed you to load hex files and compare them. Its long gone from Windows methinks.

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

Reading the flash as a bin file, and doing a hex2bin on the programming file should help ... ?

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

Post both hex files.

"This forum helps those that help themselves."

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

 

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

Please find the attached hex files.

 

Working.hex - working hex file

Corrupted1.hex - code read from IC when uart stopped working

Attachment(s): 

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

chetanhiremath wrote:
.HEX file which i am loading and what i read back from IC are totally different
Compare the code read back after fail to code read back immediately after re-programming...

(Also, if you set lock bits then you will not read back valid code.)

David (aka frog_jr)

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

Compare the code read back after fail to code read back immediately after re-programming...

 

(Also, if you set lock bits then you will not read back valid code.)

Yes i have compared the codes as you told, both are different.

 

And i haven't set any lock bits.read back immediately after programming and code i am flashing were same.

 

Only after flash got corrupted, i am not reading proper things from flash.

 

I have checked previously that, code 

 

 

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

chetanhiremath wrote:
read back immediately after programming and code i am flashing were same.

How, exactly, are you doing the comparison?

 

The hex files you posted earlier had different line lengths for the 'Corrupted1.hex' and 'Working.hex' files - so a simple text compare is never going to work...

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

awneil wrote:

The hex files you posted earlier had different line lengths for the 'Corrupted1.hex' and 'Working.hex' files - so a simple text compare is never going to work...

 

They are very different. I had a programmer window open so loaded 'corrupted1', blew it into a chip and then verified against 'working'.

 

 

"This forum helps those that help themselves."

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

 

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

Brian Fairchild wrote:
They are very different.

Yes, agreed; just wondering how the OP actually did the comparison - because, as noted, a simple text "diff" won't work.

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

Brian Fairchild wrote:
They are very different.

"Different" as in chunks that might indicate corruption, or "different" as in "this makes no sense at all"?

 

[edit]  I'm in the middle of making my own "consistent format" set of files, from OP's posted attachments.  I have doubts about the "working" flash image to start -- it looks nothing like a typical AVR8 app that comes out of a compiler.  And it doesn't make much sense for an ASM app either.

 

OP -- is "working" the output of a compiler?

 

Strike that, perhaps/probably -- further effort to disassemble could well show that the beginning of 'working" is indeed a set of RJMPs that would indicate a vector table.  And indeed, "corrupted" looks a mess [compared to what one would expect from an AVR8 app].

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Mon. Jan 29, 2018 - 07:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

Brian Fairchild wrote:
They are very different.

"Different" as in chunks that might indicate corruption, or "different" as in "this makes no sense at all"

 

Different as in 'I can't find a single byte that's the same'.

 

 

"This forum helps those that help themselves."

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

 

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

By way of example...

 

</p>
<p>+00000000:   2000        TST       R0             Test for Zero or Minus<br />
+00000001:   42D0        SBCI      R29,0x20       Subtract immediate with carry<br />
+00000002:   FC00        SBRC      R0,0           Skip if bit in register cleared<br />
+00000003:   FB39        RSBC.L    R16,R16        32-bit Reverse Subtract with Carry<br />
+00000004:   928035E5    STS       0x35E5,R8      Store direct to data space<br />
+00000006:   8000        LDD       R0,Z+0         Load indirect with displacement<br />
+00000007:   9896        CBI       0x12,6         Clear bit in I/O register<br />
+00000008:   0000        NOP                      No operation<br />
+00000009:   0000        NOP                      No operation<br />
+0000000A:   FC00        SBRC      R0,0           Skip if bit in register cleared<br />
+0000000B:   0B3F        SBC       R19,R31        Subtract with carry<br />
+0000000C:   0802        SBC       R0,R2          Subtract with carry<br />
+0000000D:   0000        NOP                      No operation<br />
+0000000E:   FC00        SBRC      R0,0           Skip if bit in register cleared<br />
+0000000F:   39B9        CPI       R27,0x99       Compare with immediate<br />
+00000010:   7156        ANDI      R21,0x16       Logical AND with immediate<br />
+00000011:   D397        RCALL     PC+0x0398      Relative call subroutine<br />
+00000012:   FC01        SBRC      R0,1           Skip if bit in register cleared<br />
+00000013:   0B3F        SBC       R19,R31        Subtract with carry<br />
+00000014:   0802        SBC       R0,R2          Subtract with carry<br />
+00000015:   0000        NOP                      No operation<br />
+00000016:   0000        NOP                      No operation<br />
+00000017:   0000        NOP                      No operation</p>
<p>

 

 

"This forum helps those that help themselves."

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

 

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

Beginning of "working" looks like an AVR app -- a jump to the reset code at A9, followed by a vector table all pointing to the default:

Default vector code looks OK, too.

 

Now let's try the "after"...

Gibberish.  And the gibberish continues to the end of flash, not to the end of program as in the "working" version.  So either OP's flash read-back mechanism needs work, or a rogue SPM?  If the latter, how could it march through all of flash without overwriting itself, and all the other precautions?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

@OP

 

have you enabled the BOD as suggested above?

"This forum helps those that help themselves."

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

 

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

theusch wrote:

... or a rogue SPM?  If the latter, how could it march through all of flash without overwriting itself, and all the other precautions?

 

I did have a quick look for any SPMs in there but didn't find any.

"This forum helps those that help themselves."

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

 

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

Brian Fairchild wrote:
I did have a quick look for any SPMs in there but didn't find any.

 

IME AVR8s don't get corrupted flash, and we have field production units (many industrial) well into six figures over the years.  Now, weird things do happen with hard noise (which violates Absolute Maximum Ratings).  But I've never seen flash corruption much less trashing of entire flash memory.

 

For our sanity check, OP should verify the read-back mechanism; e.g. program a unit then read back and compare.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

#1

chetanhiremath wrote:
using USART to display few commands on terminal, immediate after code everything will be working fine i will be getting commands on terminal but after some time say after a day or a two,everything else works proper except USART it won't display anything on terminal.

.
#7
chetanhiremath wrote:
After some time I am not seeing any data on the terminal with the same baud rate, but 7-segment display is glowing and working fine as per my code.

.
İf content of flash differs from original program, according to #1 and #7 how do other parts of program works fine?
.

Majid