Error handling strings in a 8051

Question

I am using a Texas Instruments CC1110, which is based on the 8051 microcontroller. I'm programming it using the IAR Embedded Workbench.

I have written a function named sendChar that sends a 8-bit char over the UART interface. Running the following code:

sendChar('H'); sendChar('e'); sendChar('l'); sendChar('l'); sendChar('o'); sendChar(' '); sendChar('W'); sendChar('o'); sendChar('r'); sendChar('l'); sendChar('d');

Results into the expected behavior of Hello world being sent over the UART channel. But then defining the sendString function as:

void Serial::sendString(char *str) { unsigned int i; for(i = 0; i < strlen(str); i++) this->sendChar(str[i]); }

and running the following code:

sendString("Hello world");

results in 0xFF being sent more than 100 times.

I have noticed that sending the strlen output with the sendChar function reveals that the wrong string length is being generated. For example, if I run the following code:

char str[100] = "Hello world"; sendChar(strlen(str));

I receive 101 instead of 11 as one would expect.

What am I doing wrong?

Edit

If I run the following code:

char str[100] = "Hello world"; sr.sendChar(str[1]); sr.sendString(str);

one would expect to receive eHellow world, but instead I receive 101 dots . (0xFF).

Edit 2

Complete code:

#include <ioCC1110.h> #include <ioCCxx10_bitdef.h> #include <math.h> #include <string> void sendChar(char c); void sendString(char *str); void main(void) { CLKCON = 0; // Crystal oscillator, no pre-scaler U0CSR |= U0CSR_MODE; // USART0 in UART mode P0SEL |= BIT3 | BIT2; //P0.2 and P0.3 as peripherials // Baud rate = 9600 (9597) U0GCR |= 8; U0BAUD = 131; // Enable Rx and Tx interrupts IEN2 |= IEN2_UTX0IE; URX0IE = 1; while(P0_4); // Wait for P0.4 char str[100] = "Hello world"; sr.sendString(str); while(1); // Wait so main() never ends } void sendString(char *str) { while (*str) sendChar(*str++); } void sendChar(char c) { U0DBUF = c & 0xFF; while(!UTX0IF); UTX0IF = 0; }

Edit 3

I ran a simple main:

int main( void ) { char str[] = "Hello world"; CLKCON = 0; // Crystal oscillator, no pre-scaler P2DIR = 1; // P2.0 as output P2 = 0; char l = str[2]; Serial sr; while(P0_4); sr.sendString(str); while(1); }

and debugged it. Here is a screenshot of the value of the str array. Its full of dots, as I reported previously.

Any idea on what's causing that?

I suggest you find the source code of the sendChar(..) function and check what it requires. Also check what your startup C-code (crt0?) does with initializing the various program sections. — Oldfart
– Oldfart, Commented Feb 4, 2018 at 18:51
It's been some years, but why are you enabling interrupts based upon the flag, if your code doesn't use any interrupt events? Why bother with IEN2 or URX0IE? — jonk
– jonk, Commented Feb 4, 2018 at 20:01
I wonder if there is some problem with your compiler setup. This behaviour would be expected if string constants are not being output correctly. And usually strings are the main use of read-only data, which has a special section for it... — Stack Exchange Broke The Law
– Stack Exchange Broke The Law, Commented Feb 4, 2018 at 23:51

jonk · Accepted Answer · 2018-02-04 18:56:46Z

I think you have more than one problem. Since you don't identify your compiler, nor how you set it up, it's going to be hard to help with precise instructions.

Let's start with problem #1.

Given your last test, it sounds to me like strlen() isn't working.

The sizeof() function, which you aren't using here, is evaluated at compile time and might have returned a large number since its job is to tell you the known size of a buffer like this.

But strlen() evaluates at run-time and should technically report the actual string length after initialization with the string. If this string is placed statically (outside of a function at the "module/file level"), then this initialization should take place prior to main() starting up (by hidden assembly code.) If this string is placed as a function-local variable, then this initialization takes place every single time the function is called (I remember the days, though, long before the first C standard arrived when such initialization was ignored.) Either way, your code should not be able to call strlen() before initialization takes place. So strlen() should always be able to "see" the string.

So either strlen() isn't working, or it is. If it isn't working, you need to find out why. If it is working, then your initialization string isn't being properly initialized (or it is being initialized with garbage or some foreign language multi-byte mess.) If that's the case, you need to track that down as well.

One thing to try, in order to verify that the string buffer is being initialized is to STOP TRYING to use string functions on it. Obviously, that is NOT WORKING for you. So now, try and dump out a few byte values as integer numbers. See what is in that buffer. Verify!!!

I'm also not entirely sure if your receiving program is getting the right number of bytes, or not. I'd like you to confirm or deny that question in my mind. I think you are saying that it is getting lots more characters. And, if your strlen() result is counting lots of characters, then it makes sense that lots of characters are being sent out. But I'd like you to talk a little more about this. Just because I might pick out something from what you add.

The other problem I see is that your receiver (whatever it is that is "getting" the characters being sent along) isn't getting the right values. This can be for several possible reasons. Since this is asynchronous communications (as I gather it), it's possible that the bit rates don't match up right between sender and receiver. Did you make sure to initialize the serial library correctly? On both ends? This could also account for different numbers of characters being sent than received, as well as the garbage you see. It's vital that you get these things matched up right.

Another possibility is that your sending library is using one stop bit and your receiving side expects two stop bits, for example.

Another possibility is that your receiving code/device/whatever cannot handle back to back characters. It has some stupid, idiotic delay inside of it that prevents it from properly parsing a continuous stream of asynchronous characters. But it can receive them one at a time, with breaks of time in between. So you get stuff that seems right when you use a separate call, each time. Because there is a LONG delay in between. But when you send out a string, the sending code just RAMS IT OUT FAST, back to back, and your receiver just gets overwhelmed and cannot keep up.

For now, that's all I can easily imagine. So try these few things earlier than later:

Verify that you are initializing the asynch rate properly with the library you are using on the transmitter side.
Verify that you are using the same rate properly on the receiver side.
Verify that the clocks used on both sides are capable of providing those rates within the appropriate error bars for async (about 2% or less.)
Verify that that the number of stop bits match up, or that the transmitting side uses MORE stop bit time than the receiving side, if they don't match.
Track down what is being placed in your string buffers. Don't assume. Verify. Check the first 10 bytes. Print their byte values as integers and see what they are.
Scan through the string buffer looking for a 0 byte. When you find the first 0 byte, tell us at which buffer index it occurs at.
Hook up your receiving device to some other source. Verify that it can receive a continuous string without error.
Tell us what compiler you are using.

I'm using the IAR Embedded Workbench. I'm not using any libraries, I made the functions myself. I'm viewing the data on an Oscilloscope so I can see exactly what bits are being sent. I think it may have to do something with the C++compiler. If I run the exact same code on a C project it works flawlessly, but in a C++ one it does not. Any ideas? — jagjordi
– jagjordi, Commented Feb 4, 2018 at 18:58
He said it worked with compiled characters, which excludes baud rate etc. Each error seems to involve a static string which is supposed to come from an initialized section. — Oldfart
– Oldfart, Commented Feb 4, 2018 at 18:58
@oldfart In cases like this, I accept very little of what the OP mentions as "true". Best to walk through some thinking. And the fact that there is a difference calling the char output one at a time vs the string output is a worry. — jonk
– jonk, Commented Feb 4, 2018 at 19:01
@jagjordi How is your C++ set up? When I use one here, I may very well find Unicode or multi-byte characters in the buffer. Or I might wind up using functions that expect them, and don't get them. Verify your buffer contents. Assume nothing. — jonk
– jonk, Commented Feb 4, 2018 at 19:02
@jagjordi If you can, dump out the buffer as integers. Can you use a printf() here and use %d or %x as the format specifier? Just print out the first 10 bytes or first 6 bytes. Something. You need some details. — jonk
– jonk, Commented Feb 5, 2018 at 2:35

Oldfart · Accepted Answer · 2018-02-05 14:06:40Z

Use:

while (*str) sendChar(*str++);

You might want to add carriage returns if the string has line feeds:

while (*str) { if (*str==0x0A) sendChar(0x0d); sendChar(*str++); }

Your latest debug data shows what I have been expecting all along: your string array does not get initialized. Although this is not strictly correct according to the C/C++-code, it does not surprise me. When working with micro controllers there are often limitations to what is supported by the compiler. I suspect your compiler does not support initialisation of variables on function call.

I suggested some time ago to make the string global. The reason is that most MCUs have code in the crt0.s to copy values from ROM to RAM on startup for initialized variables. The copy has to be done because you specified the string as 'changeable' thus it must reside in RAM. If you make the value

const char str[100] = "..";

The string is likely to be mapped to the ROM area as there is never need to change it. Check your compiler manual which should have a section on how variables are mapped depending on how you define them.

Thanks, but that didn't solve my problem. Please see my edit. — jagjordi
– jagjordi, Commented Feb 4, 2018 at 18:35
What difference between this and the asker's code will make it work? This may be more compact and slightly more efficient but I don't see how it's substantially different in operation. — Stack Exchange Broke The Law
– Stack Exchange Broke The Law, Commented Feb 4, 2018 at 21:35
@immibiss This avoids strlen which maybe flawed if e.g. he wrote it himself. — Oldfart
– Oldfart, Commented Feb 4, 2018 at 22:18

Stack Exchange Network

Error handling strings in a 8051

Edit

Edit 2

Edit 3

2 Answers 2

Hot Network Questions

Error handling strings in a 8051

Edit

Edit 2

Edit 3

2 Answers 2

Related

Hot Network Questions