0
votes

I am using PICKit3, MikroC PRO for PIC v6.0.0, PIC18F45 @ 8MHz and RN-42 bluetooth module. I'm connecting to the RN-42 module both from the laptop and from my Android app and i am sending a password. The weird thing is that the PIC sometimes says that the password is correct, but sometimes it doesn't. I am sending the same string. While testing, it happened to not accept the pass only the first time and all other attempts were accepted. The UART baud rate is 9600 set on both the PIC and the RN-42. RTS & CTS on the RN-42 are not connected.

I tried also:

char password[] = "abc";
char password[4] = "abc";
char password[5] = "abc\0";
char *password = "abc\0";

strcmp(input, "\0"); after the UART1_Read_Text(input, "|", MAX_UART_RX_CHARACTERS);

But it's the same... What could be the problem, is it in my code or is it possible to be and issue inside the MikroC functions?

void authenticate() {
     char input[MAX_UART_RX_CHARACTERS + 1] = "";
     char password[] = "abc\0";
     unsigned char ready = 0;

     Delay_ms(500);
     UART1_Write_Text("TRobot\n");

     while (connected && !ready) {
           if (UART1_Data_Ready()) {
              TMR0ON_bit = 0;
              time_out = 0;
              UART1_Read_Text(input, "|", MAX_UART_RX_CHARACTERS);

              if (strcmp(input, password) == 0) {
                 UART1_Write('y');
                 serve();
              } else {
                 UART1_Write('n');
                 disconnect();
              }

              ready = 1;
           }

           if (time_out) {
              disconnect();
           }
     }
}

UARTx_Read_Text() Prototype:

void UARTx_Read_Text(char *Output, char *Delimiter, char Attempts);

UARTx_Read_Text() Description:

Reads characters received via UART until the delimiter sequence is detected. The read sequence is stored in the parameter output; delimiter sequence is stored in the parameter delimiter.

This is a blocking call: the delimiter sequence is expected, otherwise the procedure exits (if the delimiter is not found).

Parameters :

Output: received text Delimiter: sequence of characters that identifies the end of a received string Attempts: defines number of received characters in which Delimiter sequence is expected. If Attempts is set to 255, this routine will continuously try to detect the Delimiter sequence.

Example:

Read text until the sequence “OK” is received, and send back what’s been received:

UART1_Init(4800);                         // initialize UART1 module
Delay_ms(100);

while (1) {
  if (UART1_Data_Ready() == 1) {          // if data is received 
    UART1_Read_Text(output, "OK", 10);    // reads text until 'OK' is found
    UART1_Write_Text(output);             // sends back text 
 }
}
5
In the case where it seems to not match, you could try sending a hexdump of the input back via UART1_Write_Text (or via any other debug channel you have available). Seeing what is there might shed some light. (For example perhaps it's a flow control problem and the first character is being mangled sometimes, etc.)M.M
I have PICKit3 only and i can use it as a debugger. I am using MPLab v8.92 and i will try debugging it. Tell me more about the hexdump please.Ted Tedson

5 Answers

3
votes

Probably UART1_Read_Text() doesn't behave as expected. I looked for documentation/source for that (non-standard) function, but failed to find any.

Make sure it properly terminates input with a '\0' character when the user presses return.

1
votes

you can do a strlen(input) to see if there are invisible symbols behind or compare the arrays value by value to see where the difference is.

Also strncmp(input, password, strlen(password)); might help. This would ignore all symbols behind the length of password which will make abcd a valid password, so be afraid of this.

1
votes

strcmp() returns different value with the same input

No it does not. When presented with identical inputs, strcmp() will return identical output. Clearly you are not passing identical inputs to the different calls to strcmp(). You'll need to do some debugging to inspect the values and so find out where they differ.

1
votes

I solved the problem. I found out that the issue occurs after calling the disconnect()

Normally when the input differs the password the disconnect() is called. I've noticed that when a new connection is made and the right password string is sent, two additional bytes are added to the beginning of the input string every single time. I made a simple debugging using UART1_Write_Text(input).

The disconnect function is setting the RN-42 module into command mode, killing the connection and exiting command mode. The RN-42 red LED starts blinking fast and then slows down which means that it's not in CMD mode anymore. I just removed the disconnect function and put a timeout of 5000ms between the password attempts. But i still don't know what exactly causes the problem.

void disconnect() {
     UART1_Write('$');
     Delay_ms(100);
     UART1_Write('$');
     Delay_ms(100);
     UART1_Write('$');
     Delay_ms(100);
     UART1_Write('K');
     Delay_ms(100);
     UART1_Write(',');
     Delay_ms(100);
     UART1_Write('-');
     Delay_ms(100);
     UART1_Write('-');
     Delay_ms(100);
     UART1_Write('-');
     Delay_ms(100);
     UART1_Write('\n');
     Delay_ms(100);
}
0
votes

It looks like the read functions gets data wrongly. Seems interrupts disabled. It's recommended to enable IRQs and receive data by interrupts. Otherwise you will have data loss.

Anyway it is helpful to compare 1. what the device gets physically and 2. what dropped to memory after read function worked.

  1. watch by oscilloscope - it is short sequence of bytes, which is easy to see in there.

  2. you can output through a different interface, if any, or debug it with JTAG.

Please include any results and update question so anyone would be able get more understanding and give a better answer,