16F877A - Uart Crash ?

Hi, as you probably have seen I am doing some pic-micro projects with the 877A following the Circuit Digest tutorials. This is not a priority for me but what I noticed today is perhaps a bug. I am not sure because I have little experience with Uart and serial monitor except some with Arduino and that was a few years ago.

It is from this webpage
https://circuitdigest.com/microcontroller-projects/uart-communication-using-pic16f877a
Compiled at once with MPLab XC8
Once loaded into Simulide 877A the program crashes on Power Circuit Button.
See picture and hex- and simu-file if needed.

Another question I have is about the MCU-Monitor screen. It looks as if you can bring Status and PC (or RC?) to the foreground with a click but that is not happening ? 



In the mean time I will take a closer look at the Simulide Mcu-tutorials and video's if I'm missing something. Thanks.

https://github.com/Alectus/Dump-sharing/blob/main/CD12_877A_UART.X.production.hex
same hex here with title CD12>
https://github.com/Alectus/uChip-controller-simulations
Simu>
https://github.com/Alectus/Dump-sharing/blob/main/CD9%2010%2011%2012_877A_UART%20Crash.simu

Ps, 0.4.14-SR4 Win64 loaded with the same Hex-file is not crashing on Start and is responding to keyboard input



I removed the 'IC-socket' Vdd/Vss wires but it made no difference in 4.15. Or in 4.14.
And now I am here, what is meant with MAIN MCU? Since only one can be in the central panel? Or is that option used in situations like in this video, around minute 5, where two simulations are opened and put next to each other
https://www.youtube.com/watch?v=WVBgmah6gE0

Once loaded into Simulide 877A the program crashes on Power Circuit Button.

Yes, this is an important bug afecting all PICs.
Solved in Rev 158.

Any crash is always an important bug, thanks for reporting.

Another question I have is about the MCU-Monitor screen. It looks as if you can bring Status and PC (or RC?) to the foreground with a click but that is not happening ?

This happens in several widgets, they look wrong depending on the screen dpi, theme, etc.
In some cases adjusting the font scale in simulide can help:
- Right-click in Circuit ->Properties ->Font Scale.
- Set a scale that fits to your screen. In your case <1, maybe 0.8 or 0.9.

I think there might be a problem here, not quite sure because I don't understand all of the coding. What I notice is that the circuit hardly responds to input signals but when I press Power Circuit button off and on than changes do occur. The code is from here and compiled with MPLab.
https://circuitdigest.com/microcontroller-projects/obstacle-avoiding-robot-using-pic16f877a



Hex-file CD23
https://github.com/Alectus/uChip-controller-simulations/blob/main/MPLAB_CD_HexFiles/CD23_Usonic_Robot.X.production.hex
Simu
https://github.com/Alectus/Dump-sharing/blob/main/CD%2021%20until%20xx_.simu

It is not obstructing with what I am doing so it's not urgent or something. Tried it in 0.4.14 and that didn't change much. Removed L293 and no difference either. Maybe you want to take a look but when you're busy it's not so important, for me anyway. The previous one, also with Ultra sensor and with a LCD responded very fast.
https://simulide.forumotion.com/t182-my-first-mplabx#983

At 0 Hz it's game over 

Sorry, maybe I made a mistake, it is responding in the 4.5 to 5V region on the ultra sensor. Didn't see it good until I placed the leds and the frequency meters. Very nice to have this sensor available, thanks.
When the sensor Volt has reached 0V or been turned off it doesn't come back to life without a Power Circuit reset. Maybe this is in the coding.
*****
I tried it with CD22, same thing. When the ultrasonic sensor In v=m has become 0 Volt it does not return to active anymore without power circuit reset. Minor detail and not shocking but a little bit confusing in the beginning.

When the sensor Volt has reached 0V or been turned off it doesn't come back to life without a Power Circuit reset. Maybe this is in the coding.

Indeed this is an error in simulide combined with "while loops" in the code.
Those while loops have no timeout, which is not a very good idea.
If something is not working exactly as expected the program can keep inside that loops forever.

The good part is that another problem was found and fixed in simulide. Thanks.

Sorry, maybe I made a mistake, it is responding in the 4.5 to 5V region on the ultra sensor.

That looks like another problem in that program.
Motors should run forward unless distance < 5;

I didn't tell it completely right, the motor is running in full spectrum but it was not responding to the infrared signals. Later I saw this line of code:
 if (RD2==1 && RD3==1 && distance<=5)//Both sensor is blocked
         {
         back_off(); 
         RC4=1; RC5=0; //Motor 1 reverse
         RC6=1; RC7=1; //Motor 2 stop  
         __delay_ms(1000);
         }
It's an and and condition. I should test longer next time before I post but it kept me busy already quite some time before I changed my set-up and saw better what was going on. I didn't know about the sensor and the for-while loop so that added to the confusion because I never had used that sensor before. Actually, I have but not in a  simulation. Thank you for explaining it and these sensors add some extra fun to Simulide, tnx.   

Arcachofo wrote:Yes, this is an important bug afecting all PICs.
Solved in Rev 158.

Hi,
This Uart example 
https://circuitdigest.com/microcontroller-projects/uart-communication-between-two-atmega8-microcontrollers
is working good. Serial monitor also responding. 
I have free trial Eltima but will be finished soon.



This is Avr, I forgot you said the problem you solved was with pic-micro controllers.