Matrix user forums

I seem to have the same problem with as a previous poster with RS232 on an 18F25K22, I checked my FCD file and it is the same as the new one provided in that post. I can transmit but not receive. Simulation using VNet works fine in both directions. I also can prove that data is getting to the PIC, the baud rate and other serial setting are fine as I can transmit strings with no problems. Setting the RS232 macro to echo returns various corrupt chars suggesting a framing or baud error but I can't find one. My logic analyser says the baud rate is spot on.

Incoming serial has a variety of problems depending on how I try to capture it.

Using ReceiveRS232String I get only one character of a 60-70 char string. And even that is not correct.
Looping round ReceiveRS232Char and converting each char to a string and concatenating, I can sometimes get the first 20 or so chars correctly then the remainder becomes 0x40 or 0x80, with a few apparently random chars at the end.
Looping round ReceiveRS232Char and writing the returned values to an integer array (avoiding using strings) I get a stream of 0x40 or 0x80 (occasionally other chars).

Tweaking various things I sometimes I get nothing at all. Sometimes it seems like the RX interupt doesn't fire at all (don't know what changes that causes this, most of time the interrupt is OK). I've also tried polling instead of using the interrupt, same problem. I'm running the PIC at 8Mhz and comms at 9600 which doesn't seem too onerous to me. I've tried hardware flow control with no success. I am using a PICkit 3 and Flowkit to program and debug. I wondered if maybe the debug was slowing things down but, as much as I can test without the debugger, there still seems to be a problem.

I am using the Char Receive type of Int (extended data) with 8bit data because 0xFF is a legitimate value in the serial data I'm trying to read so I can't use that as timeout return. It did seem to work better with Byte receive type but this might have been my imagination. I've reached the end of my creativity in thinking up new tests to try.

In my FCF, attached, there is a macro, UARTC0_RX_INT, that have the three different serial reading strategies described above. I just change the switch to try any of them. There are also a lot of other macros disabled or bypassed to simplify the code. I've tried various options in the chip configuration that might have some bearing on the serial port but I am a bit in the dark on most of those.

Also, probably another issue, but breakpoints don't seem to work when using the FlowKit debugger.

Hopefully someone can spot an issue in my code or have had similar experience.

Thanks.

Hello,

The problem is likely to be caused by your configuration settings.

First of all the oscillator is set to XT, XT for an 8-bit PIC is 4MHz or under. HS is probably the setting you want.

4X PLL - this multiplies the oscillator speed by 4. Does this match your hardware and the clock speed in the project options. If in doubt then try a 1 second flasher test.

At the moment for bytes to be received correctly via the UART your config assumes you are using a 2MHz crystal which is then multiplied by 4 to give the 8MHz specified in the project options.

Thanks Benj, your help is much appreciated.

Yes, the config was set up wrong. In desperation I'd been playing with these and had neglected to put it back to HS and turn off 4xPLL before I sent the file to you. With HS and no 4xPLL I get the first 20 chars or so correctly, the rest are wrong and not as many as there should be. Interestingly the echo is worse, showing only maybe 10 or 14 chars correctly then not even trying to echo the rest except for a little burp about 200ms later and another 200ms after that. Led timing tests work OK and the baud rate is only a bit out at 9615.

I spoke to soon about transmit working OK. On trying a longer string a similar thing happens on TX too, first few chars are OK then the rest are missing. A tiny clue might be that there is a 3ms pause between each TX char.

Can you think of anything else to try? This is a commercial project and I should have this done by the end of the week. getting nervous!

If anybody reading this has good experience with PIC's, C code, Flowcode and thinks they could help with this problem, I am willing to pay to get this problem resolved quickly. There will also be some significant follow on work for which I am looking for an experienced embedded coder. Let me know.

Hello,

As your using an interrupt to receive the characters what about switching off the RS232 flow control and seeing if this makes any improvement.

That was the first thing I tried and should be off in the file I sent you. Though I do wonder if maybe the code does things that don't entirely match the flowchart. Yesterday I also tried using software option in the RS232 options, just to see if anything changed, it didn't, not at all. That suggests to me that we can rule out some peculiarity of the hardware port and maybe puts the spotlight more on the code. I want to try a faster clockspeed using the internal 16Mhz clock. It seems that I would need to set the Internal Oscillator Block in chip configs but would then need to manually set something in OSCCON to set the speed. Can you suggest what that might be?

Thanks again.

OK, I tried to run it with an internal osc but could not get it to work at all. I reverted to the 8Mhz crystal and applied the 4xPLL, and what d'ya know, the RS232 started working properly. I had tried the 4xPLL before with no success. Not sure what I did differently but, hey, it works now. RX and TX work fine. I would not have thought that 9600 baud serial was that onerous for an 8Mhz clock but I guess it it needed a bit more oomph. Anyway, I still want to try and get 16Mhz internal working. I had the internal osc block set and a C code icon with OSCCON = 0x70 (also tried 0x71) at the start of the Flowcode, but the processor does not appear to run at all, or at least the Flowkit ICD did not run. Is there some other config I need to get the internal osc setup to work?

Also, I still have issues Flowkit. Most of the time breakpoints don't halt operation (occasionally they do) and I can only set global variables in the watch window, locals refuse to add to the list. Any ideas on this?

Thanks yet again.

Hello,

Try changing your C code for the OSCCON register to lowercase. All the registers are lowercase in BoostC.
You should be able to add local variables with the flowkit but they will only appear in the list when you are inside the local macro.

The breakpoints should be working correctly. Maybe try increasing the ICD delay in the project options to see if this is what is causing problems.

Ben,

Still experiencing a lot of weirdness both from the code and Flowkit. Attached is a recent revision of my project. As long as I run a fast enough clock (I am using either 8Mhz xtal and 4xPLL or a 16Mhz xtal, both versions seem to work OK, or at least 16Mhz with 4xPLL does not fix any further problems). I can TX without problems now, and RX is usable but with some peculiarities, for instance: The code attached has an interrupt driven RX routine that works fine unless I have a line that concatenates the incoming chars . The final bit causes the whole concatenation to be stuck at 21 characters long even though the RX_Str var is 200 chars long. Without that bit it works fine. Can you think why? If there is some known quirk here I'd like to understand it so I don't but my head against it again.

As for the Flowkit, well it helps when I run a faster clock, I can now set watch variables but it's still not stopping for breakpoints. Increasing the delay as you suggested does nothing except slow things down a lot.

I also got the internal osc to run (changing from upper to lower case osccon as you said) but found this oddity: If using the internal osc and 4xPLL then the clock config has to be set to osconn setting to get the correct timing. But if I run an external xtal and 4xPLL the clock config needs to be set to the xtal x 4. Trivial detail but it took me hours to work that out.

Thanks for your patience with me!