UART1_Write_Text issue

[rabrabengineer]

Hi to all
I have two question, I am working a critical safety project and I adopted MikroC compiler because I am familiar with it. I don't thing this is good enough if the compiler is not suitable for this kind of project. Please advice me on this matter.
This will get me to my next question; I am using PIC18F4620 at PLL(8Mhzx4). I am using the UART to send AT commands to WI-FI module. The Wifi module respond by OK, ERROR or send a value if the AT command is an inquiry.
In my development I worked on stage by building up on task; ie when I develop one task and it works, I move the to next on. When I add variables and codes (which are independent from the first task) , these mess up the output of the UART in the first task even it was working before I add the second task. Sometime even just adding a completely new variable will mess up the UART output in the first task.
To explain the issue more, when I put debugging UART_Write_Text () to see my AT command outputted properly and when It did, I just comment or delete the debugging instruction, this make the UART send garbage on the top of the AT commands.
Another weird issue is that the response from the Wifi module appear mixed up with the AT commands (UART output) which should be at the UART input.
After a while, I learned to ignore this problem then it fix its self then it comeback and so on.
I am bit worried for the type of my application I am working on, as this will not be acceptable ( safety critical)
I am sorry explaining the issue without showing the code but I hope you got the idea.
Please can any one help?
Best


Note: baud rate tried
4800
9600
38400

[filip]

Hi,

Please, can you tell me which compiler version are you using ?
Which WiFI module are you using ?
Can you reproduce this issue in any other case without the WiFi module ?

Regards,
Filip.

[rabrabengineer]

Hi
Thank you for the reply.
I am using MikroC Ver 6.2.2 and Microchip RN171XVW-I/RM WiFi Module.
Just yesterday it did happened again. The UART1 ouput was OK then I added some interdependent code for new functionality and the same part of the output was messed up. Then I added a dummy code such as memset(str_hex, 0, 5) before the code section responsible outputting my AT commands and it seem resolve the issue even the variable str_hex has nothing to do with that section of code.
This morning I tried to recreate the problem without the wifi module by commenting the memset(str_hex, 0, 5) but I couldn't recreate the issue again even after removing the dummy instruction.
From time to time while I am progressing the UART1 output still get messed up and it is consistent when it occurs. However I couldn't reproduce it this morning which make things more strange.
Any idea why?
Thank you.

[rabrabengineer]

I starting getting suspicious about MikroC 6.2.2 compiler, on the top of the issue I mentioned earlier, just yesterday I found out new very very weird issue.
To mark a position in the code, I put a mealiness text such "ddd" knowing that later on when I went to go back to the same position in my code, I will compile the project and the compiler will flag it out as an error. To my surprise the compiler didn't generate an error, and the project was compiled successfully. I though I am getting tired then I called my colleagues and we did make sure that the files are for the same project files by opening them from the project manager, we repeat the same operation and the compiler didn't flag out the added text as an error.
I delete the hex file and compiler the project and new hex file was generated even there is a big rubbish text added.

I am at the end of my project and It is too late to choose another compiler.
At the moment my only option is to re-install the compiler.
Does any one experienced this compiler issue or can anyone help?

[rabrabengineer]

Update!
Even after I re-install the compiler ver 6.2.1 and Ver 6.2.2. still got the same issue.

[filip]

Hi,

I apologize for this issue.

Is it possible to attach the minimal project that demonstrates this issue ?
Since we don't have the RN171 module, could we test this in some different manner ?

Regards,
Filip.