Matrix user forums

Hi,
I installed FC8 recently and experienced the same issues as those experienced by mnf. I uninstalled and reinstalled FC8, without success and then followed Daniels advice which resolved the problem (viewtopic.php?f=78&t=21435).

After experiencing some problems with RS232 communications on a custom board, I went back to basics and, using FC8.2.1.13, Eblocks and an example flowchart (that just echoed typed characters back to source, downloaded from https://www.matrixtsl.com/wiki/images/5 ... mple3.fcfx), I got the following results:
PIC16F877A - default settings - Typed char echoed correctly
dsPIC30F4013 - UART channel 1 - Typed char echoed correctly
PIC24FJ128GA202 - UART channel 1, pins B0 and B5 - Typed char echoed correctly
PIC24FJ128GA202- UART channel 1, pins B8 and B13 - Typed char echoed correctly
PIC24FJ128GA202- UART software channel (still on pins B8 and B13), Tx and Rx Alt pin selection = No, - garbage returned
PIC24FJ128GA202- UART software channel (still on pins B8 and B13), Tx and Rx Alt pin selection = Yes - garbage returned
PIC24FJ256GA406 - Custom PCB with all UARTs set to software channels, using various pins, - garbage returned

It seems that the problem only exists when using the UART software channel option and I found that the typed characters are corrupted on receipt by the MCU. I have tested the UARTs specifically but the problem also appears to be with the SPI.

I repeated these tests using FC7.3.0.7 and the results were exactly the same as above. It seems that whatever caused the problem has effected both FC7 and FC8, so I’m pretty well stuck.

Is there a way to resolve this, please?

Kind regards.
Leo

What baud rate are you using?
Could you try just sending characters in a loop with delay between and check the baud rate with an oscilloscope or similar if you have one?
Thanks

I'm using 9600,8,N,1, no flow control.

Unfortunately I do not have an oscilloscope available.
BTW, I forgot to mention that a "Hello World" gets through to the terminal emulator just fine.

Regards.
Leo

Hi Leo,
I have found that software is a bit out.
What I did was send a U and check with a scope or digital analyser the time for 1 bit, then current baud = 1/time.
Then I adjusted custom baud until the time was spot on.
I could always get the software UART to display chars correctly using that method.
Unfortunately if you not got the equipment it will be very tricky to do.

Hi Martin

I hadn't even thought about doing that sort of adjustment. I'll get hold of an oscilloscope and give it a go.

The confusing thing is that I've done several projects using FC (all of which included serial comms) and so far haven't experienced any baud issues. I'm seeing the current problem on a project developed using FC7 and have over 200 of these units in the field. So it's a case of - it worked and now it doesn't. I would like to find out what has changed.

Anyway, thanks for your input.

Regards.
Leo

Hi Leo,
Also when using software UART with interrupts, the faster the interrupt the more chance of corruption will occur.
That's because the interrupts will stretch the pulses.
If you would have had the 12F, 16F or 18F device, I could have set hardware up to determine best baud value.

leoo wrote:PIC24FJ128GA202- UART software channel (still on pins B8 and B13), Tx and Rx Alt pin selection = No, - garbage returned
PIC24FJ128GA202- UART software channel (still on pins B8 and B13), Tx and Rx Alt pin selection = Yes - garbage returned

This is puzzling, but you would not select alt pin as that would only apply to hardware.
So it should be having no effect?

Hi Martin,

Yes, I misunderstood the alt pin usage, but included it in the test because it was there. I think there are still many little (or big?) things that I don't understand about the intricacies of FC.

I found a copy of my project (on a different PC) that didn't have all the UART and SPI connections defaulted to channel 1. When I set the project up the same way in FC8 it complied and ran with only minor changes that were required due to the difference in the EB023 component. So everything appears to be working as it should (and I may owe Microsoft an apology).

Thanks and regards.
Leo