Stream failure on serial coms

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

Hi,

I'm encountering a rather bizarre problem. The stream output on my atmega644PA sometimes fails and the only fix appears to be reprogramming it.

:?

I know the stream is failing because the single char output function still works.

Any idea what's causing this? I had the same problem on a 324PV as well.

I've included the project file rather than just the code.

There seems to be no pattern to it. Sometimes it fails on startup, sometimes midway through test run and sometimes it functions without any issues.

Attachment(s): 

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

printf()'s in an RXC ISR? You sure?

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

You need to do some serious pencil and paper work.

You have a USART1_RXC interrupt enabled with no ISR().
You have USART0_RXC interrupt disabled. There is an ISR() that does appalling things like call printf().

Design your program properly with correct ISR()s etc. Follow the general principle of 'quick service and leave'. Any complex processing can happen in the foreground.

I am surprised that you do not crash on entry!

David.

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

clawson wrote:
printf()'s in an RXC ISR? You sure?

Yes? And? How/Where else am I supposed to do it? If I manual send characters from it is going to take just as long.

If I use scanf, then the program will freeze until someone types in at a prompt.

david.prentice wrote:
You need to do some serious pencil and paper work.

You have a USART1_RXC interrupt enabled with no ISR().
You have USART0_RXC interrupt disabled. There is an ISR() that does appalling things like call printf().

Design your program properly with correct ISR()s etc. Follow the general principle of 'quick service and leave'. Any complex processing can happen in the foreground.

I am surprised that you do not crash on entry!

David.

There is an ISR for USART1_RXC.
I have the interrupt disabled for USART0_RXC.

While I appreciate the criticism, I'd prefer it if you pointed me in the right direction if you know of a better way, rather than telling me I haven't done my design properly, especially considering this is the first time I've done a system of this complexity and scope.

Do you think this is causing my stream to fail spontaneously? Because I was having this problem back in july before I implemented the interrupt functionality.

I'm not sure I understand the problem with printf?

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

ZAPrime wrote:
clawson wrote:
printf()'s in an RXC ISR? You sure?

Yes? And? How/Where else am I supposed to do it? If I manual send characters from it is going to take just as long.

If I use scanf, then the program will freeze until someone types in at a prompt.

The interrupt routine should just buffer the data. Send it out with printf in your main loop, NOT during the interrupt. Interrupt triggers, read the data, stick it at the end of the buffer, update the pointer, go back to whatever it was you were doing before the interrupt triggered. Printf takes more than a few cycles to finish sending even a single character, most likely your ISR is taking longer to finish than the frequency of the interrupt itself.

Quote:
Do you think this is causing my stream to fail spontaneously?

Yes. Run some simulations you will see the result.

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

So basically, I should execute the menu from my code? Can do.

I can't get the simulator to run consistently. it gets lost somewhere in the LCD routines.

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

Quote:

it gets lost somewhere in the LCD routines.

So stub the busy wait while trying to simulate.