Running micro and debugger to find problem with code?

[Okada]

If you don't have any problem in posting the .hex file then post it with your exact circuit and I will debug it and tell what is the problem.

 

[treez]

Thanks,

The capture only saves what you see on the screen to a file, it will not store anything you can't also see.

..we did actually manage to save some data to file during one period....but we did not see anything on the black screen of realterm during this period......we were indeed trying to get data to be on the realterm screen, but we only managed this for a few minutes , and then it stopped, and we havent been able to get it back on the screen since. We would like it on the screen all the time (as well as to file), so that we can see that it is working.

We are using windows OS....it looks like one of the later ones, at least windows 8, but i will check when back at work

 

[andre_luis]

We can scope the ttl output of the micro, and that is always sending data......but that comes through a ttl to usb converter, and then onto the PC.....

One of the first hypotheses that came to mind it was the possibility that the Baud Rate setting of the microcontroller was not correctly calculated; In addition, it is expected that you are using crystal oscillator on this circuit. However, the well defined behavior you've reported (stop recording after a while), induces the possibility that the issue is not necessarily hardware-related. Are you able to check if the amount of characters saved to the file is, let's say, an integer number which suggests that somewhere on system or tool such treshold is configured ( eg. a multiple 10, (sub)multiple of 1024 ) ?

 

[FvM]

We can scope the ttl output of the micro, and that is always sending data...

Fine, so you also checked the exact baud rate and correct framing?

 

[bepobalote]

USB-TTL converter with fake FTDI chips combined with original FTDI software driver?

 

[betwixt]

If it runs perfectly then stops, most likely it is configured to use XON/XOFF protocol and an XOFF was received. If I'm right, make sure handshaking is turned completely off.

Brian.

 

[treez]

One of the first hypotheses that came to mind it was the possibility that the Baud Rate setting of the microcontroller was not correctly calculated; In addition, it is expected that you are using crystal oscillator on this circuit.

Thanks, youve got a good point...we are not using a crystal oscillator, just the micro's internal oscillator...maybe this is our problem?...the micro does get well hot as its encased in a non ventilated LED enclosure with 30W of leds pouring heat into the internal ambient.

 

[andre_luis]

...we are not using a crystal oscillator, just the micro's internal oscillator...maybe this is our problem?...the micro does get well hot as its encased in a non ventilated LED enclosure with 30W of leds pouring heat into the internal ambient.

I'm sure that this is the cause of the problem; Internal oscillators are strongly affected by temperature variation of the chip. Although UARTs are made in such a way that accept a considerable difference between remote TX and local RX rates ( up to ~5% for 8N1 ), the fact that these values are often defined by internal timers with values varying at low resolution steps, it is not improbable that the calculated baud is at the edge limit of the detectable range, instead of centered at the optimal value. The only thing that I can suggest as a work around solution is to reduce the Baud downto a lower rate, or even to experiment setup neighborhood values, but as FvM has mentioned, it is important to measure with an oscilloscope its exact value in order to know exactly what is happening to decide the appropriate action.