 |
 |
| View previous topic :: View next topic |
| Author |
Message |
dDelage
Joined: 10 Sep 2022
Posts: 20
|
| serial transmit data truncation 16F18855 |
 Posted: Sun Feb 18, 2024 10:54 pm |
 |
|
I ran into a couple issues while trying to verify some code I had written. The code appears to work just fine, but I was looking for visual confirmation. Here is the bare minimum code to reproduce the issues:
| Code: |
#include <16F18855.H> //includes #device spec rev5
#id CHECKSUM //stores the checksum, doesn't affect program
#use delay (INTERNAL=4MHZ) //Says INTERNAL OSCILLATOR is 4MHz rev5
#PIN_SELECT U1RX=PIN_C7 //PPS chip, this is required
#PIN_SELECT U1TX=PIN_C6
#USE RS232 (UART1, BAUD=9600, parity=N, bits=8, ERRORS, DISABLE_INTS,TIMEOUT=5 )
char data[32]; // the actual buffer
int process = 0; // process flag
void serial_in();
void main();
#INT_RDA // interrupt on serial data receive
void serial_in() {
char schar = getc();
if (schar == 0xd) {
process = true;
}
}
// MAIN
void main() {
enable_interrupts(INT_RDA); //SERIAL ReceiveDataAvailable
enable_interrupts (GLOBAL); //interrupt
data = "aaaaaaaabbbbbbbbccccccccdddddddd";
while (true) {
if (process) {
process = false;
printf("this is a string with a bunch of characters.\n");
printf("in the main program, three printf()s cause truncation.\n");
printf("array: \n");
for (int i = 0; i < 32; i++) {
printf("%x ", data[i]);
}
printf("\n");
}
}
}
|
When compiling, I get this warning:
| Quote: | >>> Warning 230 "C:\Users\daved\Documents\designs\SuperTimerRev5\ST2-500-firmware\ArrayTest.c" Line 29(1,1): String truncated CHECKSUM
|
The initialization string is 32 characters long, same as the array it is getting put in. Is the warning because there is an implicit \0 at the end of the literal string, making it really 33 characters long?
The other, more important, issue is that when I send the contents of the data[] array to the serial port, it doesn't show all of the array elements. In the code above, if I remove the first two printf() statements, I do see all the elements of the array. If I put one printf() in, I see all the elements of the array. But with both of them, the array gets truncated -- not even the trailing \n gets sent.
According to my serial port monitor software, with both initial printf() statements, the first one goes as its own message, but the second one gets combined with the array output, and then gets truncated. I tried putting a delay between the second printf() and the loop, but that didn't fix anything.
The second printf() has more characters than the first, so if the first one is long enough to go as its own message, why not the second?
Thanks in advance. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19238
|
|
| Posted: Mon Feb 19, 2024 1:46 am |
|
|
| Quote: |
The initialization string is 32 characters long, same as the array it is getting put in. Is the warning because there is an implicit \0 at the end of the literal string, making it really 33 characters long?
|
Yes.
You can prove this easily enough. Shorten the string by one character.
The 'string' is actually 33 characters long.
I'm puzzled what your three printf's have to do with anything?. The warning
happens without any of the code. Just the data declaration.
How are you displaying the output data from the serial?.
Suspect your output program is what is truncating the displayed data
not the code. |
|
|
waffles
Joined: 21 Dec 2021
Posts: 6
|
|
| Posted: Mon Feb 19, 2024 1:58 pm |
|
|
| Have you tried removing DISABLE_INTS from your #USE RS232 definition? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9120
Location: Greensville,Ontario
|
|
| Posted: Mon Feb 19, 2024 3:08 pm |
|
|
don't see any 'fuses' but IF the WDT is enabled, it might be reseting PIC just at the right(wrong) time ??
as for the 'dummy data' you're sending.. I prefer the alphabet-number sequence..makes it easier to see than trying to count is it 5 or 6 'a's I should be sending.......
agree !! buffer size should be bigger, heck make it 40 or 64 bytes if you have lots of RAM. |
|
|
dDelage
Joined: 10 Sep 2022
Posts: 20
|
|
| Posted: Mon Feb 19, 2024 8:52 pm |
|
|
| Ttelmah wrote: |
I'm puzzled what your three printf's have to do with anything?. The warning
happens without any of the code. Just the data declaration.
How are you displaying the output data from the serial?.
Suspect your output program is what is truncating the displayed data
not the code. |
The compiler warning was one issue and the truncation was a separate issue. They happen to be in the same code because of how I'm testing.
I have a Windows app written in Delphi that is communicating with the PIC. (for now) the Delphi app sends messages to the PIC, and the PIC responds. I also have a serial port monitor (commercial Windows software) that is inspecting and displaying the traffic. It is the serial port monitor that is showing me the truncation. My Delphi app isn't built to handle these test messages from the PIC.
| waffles wrote: |
Have you tried removing DISABLE_INTS from your #USE RS232 definition?
|
I admit that I have not tried this. From the limited information in the help pages, it looks like DISABLE_INTS is something that is beneficial to me. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1319
|
|
| Posted: Tue Feb 20, 2024 8:25 am |
|
|
| dDelage wrote: |
| waffles wrote: |
Have you tried removing DISABLE_INTS from your #USE RS232 definition?
|
I admit that I have not tried this. From the limited information in the help pages, it looks like DISABLE_INTS is something that is beneficial to me. |
Out of curiosity why do you think it will be beneficial here? I only see the one shared variable and it is atomic relative to the architecture. What is the disable_ints providing you? From my perspective it is not a safe thing to do as you risk overflowing your receive buffer and losing incoming data while doing your printfs |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19238
|
|
| Posted: Tue Feb 20, 2024 8:32 am |
|
|
No.
DISABLE_INTS is really only for people using software serial. If you are
using the hardware, only has any use when hardware interrupt priorities
are used.
What compiler version????
Vital to see if there are any transmit problems. |
|
|
dDelage
Joined: 10 Sep 2022
Posts: 20
|
|
| Posted: Tue Feb 20, 2024 10:02 pm |
|
|
| jeremiah wrote: |
Out of curiosity why do you think it will be beneficial here? I only see the one shared variable and it is atomic relative to the architecture. What is the disable_ints providing you? From my perspective it is not a safe thing to do as you risk overflowing your receive buffer and losing incoming data while doing your printfs |
Keep in mind that this is the (more or less) minimum code to generate the behavior that I am seeing. In the real code, we have multiple timers that interrupt, too.
Ttelmah: compiler version is 5.109
Thanks |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19238
|
|
| Posted: Wed Feb 21, 2024 2:33 am |
|
|
Interrupts are inherently atomic. Unless you are using hardware interrupt
priorities (so have one interrupt as 'FAST' or 'HIGH'), interrupts cannot
interrupt each other. All disable_interrupts will cause with the UART
hardware is prevent a receive interrupt while transmitting, which increases
the risk of a UART overflow.
It really was designed for the software UART, where having an interrupt
inside a transmission will corrupt the byte. For the hardware UART, it should
only be used if you are one of the very few people using something like
and interrupt transmit, with higher priority interrupts also running. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19238
|
|
| Posted: Wed Feb 21, 2024 4:06 am |
|
|
I realise there is a glaring problem in the code as you post.
Basic fault.
data = "aaaaaaaabbbbbbbbccccccccdddddddd";
That is not legitimate 'C'. To copy the array you have to use strcpy, not
=.
I had omitted this line, and was just coding the printf statements, with
data initialised at declaration. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19238
|
|
| Posted: Thu Feb 22, 2024 3:23 am |
|
|
OK.
Something is fundamentally wrong with the code on this chip.
Just tried the experiment of running in a simulator (problem, but I don't
have one of these chips). Compiling on the 16F18445, the code (with the
errors corrected), runs. Do the same on the 18855, and it doesn't work
correctly.
Going to work through the listings with the data sheet, and try to see
what is going wrong.
Test code;
| Code: |
//#include "16F18855.H" //Trying two different chips
#include "16F18445.h"
#device PASS_STRINGS=IN_RAM
#FUSES NOWDT //make sure the watchdog is off
#FUSES NOPPS1WAY
#id CHECKSUM //stores the checksum, doesn't affect program
#use delay (INTERNAL=4MHZ) //Says INTERNAL OSCILLATOR is 4MHz rev5
#PIN_SELECT U1RX=PIN_C7 //PPS chip, this is required
#PIN_SELECT U1TX=PIN_C6
#USE RS232 (UART1, BAUD=9600, parity=N, bits=8, ERRORS )
char data[32]; // the actual buffer
int process = 0; // process flag
#INT_RDA // interrupt on serial data receive
void serial_in(void)
{
char schar = getc();
if (schar == 0xd) {
process = true;
}
}
// MAIN
void main() {
enable_interrupts(INT_RDA); //SERIAL ReceiveDataAvailable
enable_interrupts (GLOBAL); //interrupt
strcpy(data, "aaaaaaaabbbbbbbbccccccccddddddd");
while (true)
{
if (process)
{
process = false;
printf("this is a string with a bunch of characters.\n");
printf("in the main program, three printf()s cause truncation.\n");
printf("%s array: \n",data);
for (int i = 0; i < 32; i++) {
printf("%x ", data[i]);
}
printf("\n");
}
delay_cycles(1); //for debugging
}
}
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19238
|
|
| Posted: Thu Feb 22, 2024 8:44 am |
|
|
How are you testing this?.
With the code modified as I show (so the proper way to load strings),
it works perfectly on the latest version of MPLAB, but does show a problem
on the previous release. On the current release, works OK for both chips.
Looks like the MPLAB simulator has a problem, which may be what you were
seeing, but the fact that you were trying to pass a pointer to a ROM
string, and not telling the compiler to handle this may also have been
causing issues. |
|
|
dDelage
Joined: 10 Sep 2022
Posts: 20
|
|
| Posted: Fri Feb 23, 2024 9:56 pm |
|
|
| Ttelmah wrote: | How are you testing this?.
With the code modified as I show (so the proper way to load strings),
it works perfectly on the latest version of MPLAB, but does show a problem
on the previous release. On the current release, works OK for both chips.
Looks like the MPLAB simulator has a problem, which may be what you were
seeing, but the fact that you were trying to pass a pointer to a ROM
string, and not telling the compiler to handle this may also have been
causing issues. |
I'm testing with a physical 16F18855. I have the CCS C compiler and Delphi running on my computer. I program with an ICD-U64 connected to one USB port, and my Delphi application sends serial to the PIC with a USB-Serial adapter running on COM3.
The 16F18855 is on our custom PCB, and looks to be working properly when our regular firmware is connected. There is one point where we send several lines of data back to the Delphi app over serial, and prior testing showed that to be working correctly.
I added the five updated (3 new/2 change) lines from the code you posted into my test program--one at a time--and, except for the compiler warning going away with strcpy(), I noticed no other changes. Serial output still gets truncated.
I had thought that disabling the WDT would cause the PIC to hang when the serial data gets truncated, but no. It keeps running. |
|
|
dDelage
Joined: 10 Sep 2022
Posts: 20
|
|
| Posted: Fri Feb 23, 2024 10:15 pm |
|
|
More testing.
The serial port monitoring software I'm using shows me that the string that gets truncated is 100 characters long. That's a strangely rounded number to be coincidence, so I removed 10 characters from the second printf() statement. Sure enough, I got 10 more of the truncated characters back.
This makes the think it's a transmit buffer issue, or something similar. However, what I still don't understand is why the first printf() goes as its own message and the second printf() gets to wait for the loop to finish before sending. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19238
|
|
| Posted: Fri Feb 23, 2024 10:57 pm |
|
|
There is no transmit buffer,
I think you have a receive issue in your monitoring software. |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
