UART recieve value allways zero [FIXED]

[PICFriend]

Hi,

When i read out my Software RS232 component via (READ CHAR) gives back allways zero.
When i read out my Software RS232 component via (READ STRING) gives back allways "", means nothing.

What is wrong there?

Using FC 5.1.0 with PIC18F2550 20Mhz PLL. Targetfrequency 48Mhz.

Thanks

Carsten

[Benj]

Hello Carsten,

In the RS232 component properties are you using the legacy return type or the INT return type?

If you are using the INT type then you must use a INT variable to store the result of the RS232 read byte macro. You should then only get a value less then 256 when you have received valid data.

The legacy return type is always within the bounds of a byte with 255 representing no data available so if this is the case then you are either receiving valid 0's or more likely you are using the INT return type.

With PLLs and other more complex oscillator setups its worth checking the hardware is running as fast as expected. Have you done a trial 1 second flasher test program to make sure everything is setup correctly? Baud rates will probably not be correct otherwise.

[PICFriend]

Hi Ben,

I can´t get it work! Please tell me what is wrong with the "recieve".
The oscilloscope shows a bit with from 208us that gives 4808Bd.

When i send a ASCCII character "A" from PC to PIC RX (via MAX232) then i recieve the value 134, not 65.
The timeout is also strange, it seems to be faster finalised.
Everything other works fine for the moment.
The attached one is the little program.

Thanks

Carsten

PS: the flashertest was fine too, says the oscilloscope.

[medelec35]

Hi Carsten,
Would you like to try this and see if it works any better?

Martin

[PICFriend]

Hey Martin,

Thank you for check it, but it doesent work. You changed the frequency i´ve seen.
The Xtal is 18,432Mhz, prescaler by 5, PLL 96Mhz/2 means a frequency of 44,236800Mhz. Exactly baudrate is given.
But i also changed XTAL to 20Mhz prescaler by 5, PLL 96Mhz/2 means a frequency of 48Mhz -> same problem.
It had have put a logic analizer on the PIC RX line and that shows an 'A' or 65dec. The sending data are ok.
The PIC TX line is ok to says logic analizer!

There musst be something wrong or not exactly enough for bitbanging in the uart software mode.

Greetz

Carsten

[medelec35]

What I do to check baud rate is just Keep sending a "U" with a small delay e.g 2 ms in between.
measure tx line with a scope if you have one, then baud = 1/time duration of 1st space..
E.g 1st negative going pulse = 104us then baud is 1/104E-6 = 9615 BPS

To be honest I thought the PLL fixed the op at a set frequency so if xtal is 20MHZ then o/p = 48MHz
So I though if Xtal was 18MHz the o/p will not be 43.2MHz since all the different selectable options are for different crystals to only give an o/p of 48MHz.
But I could be totally wrong with that.
If I am wrong then Sorry.

Perhaps this could be clarified please?

Martin

[PICFriend]

Hello!

I´ve checked that pulse see picture below. Also i have changed the 20Mhz Xtal to another 20Mhz Xtal. No solution!

So the scope will be ok. What next? Perhaps i will change the PLL, but this i often used well.

[PICFriend]

Hey guys,

somthing strange with RS232; thats sure!!

When i write a litte programm with V4.5 then it works fine. (V4.fcf)
The same programm compiled with V5 don´t work.(V4_V5.fcf)
Everything i try doesn´t work. Don´t forget the timeout, it appears different to V4.5, please take a look here too.

Now it´s your turn.
Please!

The simplest thing makes me ever and ever again!
What is going on here, guys?

Ragards Carsten

[DirkB]

Hi,

the same problem with Midi Component. It doesn't works at all.

Regards

DirkB

[Benj]

Hello,

Right I see you are using a software UART in your program and that you are printing out the result even if invalid data has been received. I would pop in a decision icon after the RS232 receive macro and then only print out the number if Test is less then 255. You could also maybe get rid of the 100ms delay to try and ensure you don't miss any start bits from the transmitter. Lastly what about trying to reduce the timeout a bit to say 100 just to see if this helps.

I also notice that there is no configuration settings setup in your project options. Could be something to do with my setup as you say your 1 second flasher test went well.

PLLs come in various forms in the different devices. Some strictly multiply the input clock by 4, others allow for scaling of the input clock before multiplying by 4 and others also allow scaling of the multiplier.

[Benj]

Right I'm having a bit of a dig in, I have replicated your setup and am now also receiving 0's.

The mechanism seems to receive the data ok but only passes through 0. The transmit functionality is working well.

I'll let you know how I get on with resolving this problem.

[Benj]

Hello,

Right I have found the issue, It was a bug in the CAL UART file though I personally tested this file to death so really not sure where this bug came from.

To update the file on your system download the attachment below and copy the file into your "Flowcode/v5/Cal/PIC" folder.

PIC_CAL_UART.c

(20.11 KiB) Downloaded 295 times

This should also resolve any problems with the MIDI component too.

Let me know how you get on.

[medelec35]

Since bug has been confirmed and fixed, I have moved Topic Flowcode V5 Issues.