CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

UART problem in dsPIC30F4011 ?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
small_chick



Joined: 17 Jul 2012
Posts: 53

View user's profile Send private message

UART problem in dsPIC30F4011 ?
PostPosted: Fri Nov 23, 2012 10:29 am     Reply with quote

I'd like to send only one character into Hyperterminal at each time writing into U2TXREG. But when I used the following code, it gave me 8 similar characters. I can't explain why this happened like that. I hope someone can help me ! i use a hardware crystal 10MHz.
Code:

#include    <30F4011.h>
#device PASS_STRINGS = IN_RAM
#fuses XT_PLL4,NOWDT,PUT64,BROWNOUT,BORV42

void main()
 {
     U2BRG = 64; //baurate = 9600
     U2MODE=0x8000;
     U2STA =0x0400;
     while(UTXBF_2);
     U2TXREG = 0x39;
     while(1);
 }
temtronic



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Nov 23, 2012 2:32 pm     Reply with quote

Generally speaking...manually setting up registers is not a 'good idea'.
99% of 'help' here uses the C compiler functions that CCS has designed/tested and supplies. They are known to work.

I, for one, have no idea if your assignments/values are correct and there probably aren't too many using the 30F series either.

Honestly, I'd try one of the examples CCS supplies for 'serial' communications, again, they are known to work and would be a good starting point/

hth
jay
small_chick



Joined: 17 Jul 2012
Posts: 53

View user's profile Send private message

funny thing !!!
PostPosted: Sat Nov 24, 2012 10:23 am     Reply with quote

i think this problem is not easy to explain ! i've tried to use supported function by CCS and realize this interesting thing.
Compare two kind of coding following:
*1st case:
Code:

#include     <30F4011.h>
#device PASS_STRINGS = IN_RAM
#fuses XT_PLL4,NOWDT,PUT64,BROWNOUT,BORV42
#use delay(clock=40000000)
#use rs232(baud=9600,parity=n,bits=8,stop=1,uart2)
 void main()
{   
    putc('a');
    puts("chanh");
    while(1); 
}

then the result is:
"achanh
achachaachaachanh
achachanh
"
(three lines in Hyperterminal as above)

*2nd case:
Code:

#include     <30F4011.h>
#device PASS_STRINGS = IN_RAM
#fuses XT_PLL4,NOWDT,PUT64,BROWNOUT,BORV42
#use delay(clock=40000000)
#use rs232(baud=9600,parity=n,bits=8,stop=1,uart2)
 void main()
{   
     putc(getc());
    putc('a');
    puts("chanh");
    while(1);
}

then from the Hyperterminal, i type 1 character 'q' => the result is:"qachanh"
It seems like that dsPIC30F4011 need to receive before transmitting ! Hope you give some comments, maybe it's not a solution! just share our thoughts together ! Very Happy
gpsmikey



Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA

View user's profile Send private message

PostPosted: Sat Nov 24, 2012 10:58 am     Reply with quote

Seems very odd - this is actual hardware you are running on and that is the entire code you show in your example ? What version of the compiler are you running ?

A couple of things come to mind to try assuming the above is true:
in the end "while" loop, add code to the loop at the end and see if the compiler does it differently ( while(1) {x=1;} ) or something like that that does nothing, but force the compiler to deal with it differently. You also should check the erata sheet for that chip and see if there are any known issues. I certainly don't see anything in your code that could cause it to go around the code multiple times (which is what it looks like it is doing). It almost sounds like (from your example) a flag bit in the uart is not getting cleared properly. I think I better go make coffee ... brain is fuzzy.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3
Ttelmah



Joined: 11 Mar 2010
Posts: 19551

View user's profile Send private message

PostPosted: Sat Nov 24, 2012 12:05 pm     Reply with quote

I'd say, either the watchdog is getting enabled, and the chip is therefore restarting, or you have a glitch on the power supply, and the chip is doing a brownout restart. Either would explain what you are seeing.
The brownout in particular, does have a wide range in the data sheet. If I remember correctly BORV42, can actually trigger as high as 4.7v on some chips. I had a batch a while ago, that triggered well above the rated figure....

Best Wishes
small_chick



Joined: 17 Jul 2012
Posts: 53

View user's profile Send private message

PostPosted: Sat Nov 24, 2012 7:12 pm     Reply with quote

Ttelmah wrote:
I'd say, either the watchdog is getting enabled, and the chip is therefore restarting, or you have a glitch on the power supply, and the chip is doing a brownout restart. Either would explain what you are seeing.
The brownout in particular, does have a wide range in the data sheet. If I remember correctly BORV42, can actually trigger as high as 4.7v on some chips. I had a batch a while ago, that triggered well above the rated figure....

Best Wishes

I have disabled WatchDog => it can't work !
Maybe you're right about Brownout mode!
Now, it works better, I have had some changes:
1/-add a delay about 20(ms) at first in void main().
2/-config line at the top as follows:
Code:
#fuses XT_PLL4,NOWDT,PUT64,BORV27,NOBROWNOUT

Very Happy
Ttelmah



Joined: 11 Mar 2010
Posts: 19551

View user's profile Send private message

PostPosted: Sun Nov 25, 2012 1:48 am     Reply with quote

Just because it is disabled in the code you post, doesn't mean it is disabled in the chip. Depending on what programmer you are using, the fuse might not be being erased, or might be being set by a 'setup' option somewhere. The only way to be 'sure' is to read the fuses back from the chip, and verify the corresponding bit.
I really would suspect you have got spikes on your power rail though. The processor _must_ have decoupling with really good high frequency behaviour (this means something like ceramic, or polyester capacitors, _not_ electrolytic), right close to the chip. I'd be suspicious you are actually getting tiny spikes as things happen...

Best Wishes
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group