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

printf only working for two characters

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



Joined: 05 Mar 2012
Posts: 99
Location: Central Illinois

View user's profile Send private message

printf only working for two characters
PostPosted: Thu Oct 24, 2013 3:54 pm     Reply with quote

10LF322
PCM Version 4.141

Just setting up a simple test. PIC is connected to pickit2 using the UART tool. printf() doesn't seem to output more than 2 letters at a time. "hi" displays, but "hello" does not.

What have I missed here?
Code:
#include <10LF322.h>
#device adc = 8
#define OSCILLATOR 4000000
#use delay (internal = OSCILLATOR)
#fuses INTRC,NOBROWNOUT,NOWDT,NOPUT,NOMCLR,NOPROTECT,NOLVP,NOLPBOR,NOWRT,NODEBUG
#use RS232(baud = 9600,  XMIT = PIN_A0)

#define DELAY_TIME 3000

void main(void)
{
  while(1)
  {
    delay_ms(DELAY_TIME);
    printf("hi\n");
    delay_ms(DELAY_TIME);
    printf("hello\n");
  }
}
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Oct 24, 2013 4:19 pm     Reply with quote

Quote:
PIC is connected to pickit2 using the UART tool.

Read this thread about the requirements of the Pickit 2 uart tool
to recognize a carriage return / linefeed. It apparently has to be
done in a specific way:
http://www.ccsinfo.com/forum/viewtopic.php?t=51176

Also read this Keil article on implementing CRLF in a small embedded compiler:
http://www.keil.com/support/docs/1265.htm
stinky



Joined: 05 Mar 2012
Posts: 99
Location: Central Illinois

View user's profile Send private message

PostPosted: Thu Oct 24, 2013 9:06 pm     Reply with quote

Thanks PCM. I did some more digging shortly after I posted this.
When I watch my XMIT pin on the scope I see it issue the "hi" but then the pin just sits high for 6 seconds. It doesn't actually output anything when it gets to "hello world."
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Oct 24, 2013 9:48 pm     Reply with quote

Experiment. Find out what works, and what doesn't work. Try a more
simple program loop, like this:
Code:

void main(void)
{
  while(1)
  {
    delay_ms(1000);
    printf("1\r\n");
    delay_ms(1000);
    printf("2\r\n");
  }
}

Notice this has the \r\n pattern from the link that I provided.
stinky



Joined: 05 Mar 2012
Posts: 99
Location: Central Illinois

View user's profile Send private message

PostPosted: Fri Oct 25, 2013 7:57 am     Reply with quote

I experimented with the additional carriage return as you suggested. My gut tells me this isn't a formatting issue. I don't care if it spits out on one line, I care if it spits out anything!

take 2:
Code:
#include <10LF322.h>
#device adc = 8
#define OSCILLATOR 4000000
#use delay (internal = OSCILLATOR)
#fuses INTRC,NOBROWNOUT,NOWDT,NOPUT,NOMCLR,NOPROTECT,NOLVP,NOLPBOR,NOWRT,NODEBUG
#use RS232(baud = 9600,  XMIT = PIN_A0)

void wait(void)
{
  delay_ms(2000);
}

void main(void)
{
  while(1)
  {
    printf("hi");
    wait();
    printf("hey");
    wait();
    printf("hola");
    wait();
    printf("hello");
    wait();
  }
}


The first two printf() lines "hi" and "hey" print as expected. "hola" and "hello" print nothing. The partial assembly listing is as follows:
Code:
....................     printf("hey");
009D:  MOVLW  68
009E:  MOVWF  ??65535
009F:  CALL   @PUTCHAR_1_
00A0:  MOVLW  65
00A1:  MOVWF  ??65535
00A2:  CALL   @PUTCHAR_1_
00A3:  MOVLW  79
00A4:  MOVWF  ??65535
00A5:  CALL   @PUTCHAR_1_
....................     wait();
00A6:  CALL   wait
....................     printf("hola");
00A7:  MOVLW  04
00A8:  BSF    STATUS.RP1
00A9:  MOVWF  10D
00AA:  MOVLW  00
00AB:  MOVWF  10F
00AC:  BCF    STATUS.RP1
00AD:  CALL   @PSTRINGC7_60
....................     wait();
00AE:  CALL   wait


So my experiments have shown that if there are enough characters in the string the compiler creates a different routine and it's at that point that I don't see anything on screen. Again, the XMIT pin simply remains HIGH.

Obligatory quote from data sheet:
Quote:
Note 1: Bits IRP and RP1 of the STATUS register
are not used by the PIC10(L)F320 and
should be maintained as clear. Use of
these bits is not recommended, since this
may affect upward compatibility with
future products.

I'm certainly not wed to this part, it was just the first one I picked up yesterday. Perhaps I can't use it in this manner with the software RS232 functions.
Ttelmah



Joined: 11 Mar 2010
Posts: 19513

View user's profile Send private message

PostPosted: Fri Oct 25, 2013 8:36 am     Reply with quote

The fault is in the handling of strings in ROM. If you look, it is loading 10D with the number of characters to send, and then is meant to load 10F with 'where to start', but loads the same value for both routines....
It creates a data table to hold the bytes, but get just about everything wrong about the access....

You need to report this to CCS. Those chips were only added a short while before 4.141, and it looks as if quite fundamental bits don't work. That it has not been mentioned here before, possibly points to how many people are using these....
Unlike 99% of chips in this family, these allow the flash memory to be read. Hence the code is trying to use a routine to access it this way. On the other chips, this is not possible, and the code instead uses RETLW as a way of storing the bytes. If you code for the 10F222 instead, this style of access is used, and works.

The same fault exists in the current versions.

Best Wishes
Ttelmah



Joined: 11 Mar 2010
Posts: 19513

View user's profile Send private message

PostPosted: Fri Oct 25, 2013 9:02 am     Reply with quote

If you need to get it working temporarily, and have the device editor, if you edit the type, and change the 'flash access' from 'PIC16 32/32' (memory, flash access), to 'none', it'll then switch back to the default mode of accessing the ROM, and work.
The whole of this area appears flawed. Given that the erase and write latch sizes are 16/16, the 32/32 setting cannot be right, and it then as you have already spotted starts trying to use higher page accesses as well....

Best Wishes
stinky



Joined: 05 Mar 2012
Posts: 99
Location: Central Illinois

View user's profile Send private message

PostPosted: Mon Oct 28, 2013 12:33 pm     Reply with quote

Thanks guys. Reply back from CCS support is that this compiler bug has been fixed and will be available in release V5.014
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