| View previous topic :: View next topic |
| Author |
Message |
stinky
Joined: 05 Mar 2012
Posts: 99
Location: Central Illinois
|
| printf only working for two characters |
 Posted: Thu Oct 24, 2013 3:54 pm |
 |
|
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
|
|
|
stinky
Joined: 05 Mar 2012
Posts: 99
Location: Central Illinois
|
|
| Posted: Thu Oct 24, 2013 9:06 pm |
|
|
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
|
|
| Posted: Thu Oct 24, 2013 9:48 pm |
|
|
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
|
|
| Posted: Fri Oct 25, 2013 7:57 am |
|
|
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: 19499
|
|
| Posted: Fri Oct 25, 2013 8:36 am |
|
|
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: 19499
|
|
| Posted: Fri Oct 25, 2013 9:02 am |
|
|
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
|
|
| Posted: Mon Oct 28, 2013 12:33 pm |
|
|
| Thanks guys. Reply back from CCS support is that this compiler bug has been fixed and will be available in release V5.014 |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
