Can't set 38400 baud @ 48Mhz

[skimask]

Hi all,
I'm trying unsuccessfully to get an 18f4550 to run 38400 baud when set as follows:

Define OSC 48
DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_SPBRG 77 ' 38400 Baud @ 0.16%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically

I'm using a 20Mhz crystal, Picbasic Pro 2.46, Mpasm 7.52. When it compiles it doesn't like the PBPPIC18.lib, it says the argument is out of range and only the least significant bits are used. If I change the OSC define to 20 it works fine, but then I can't use USB.

Thanks!

Jerry.

Have you tried HSER_BAUD 38400 instead?
Maybe SEROUT2 with a mode number of 6?
At least post the offending part of your .asm file so we can see which variables are causing the pain...

[b1arrk5]

Darrel,

I added your config lines, and commented out the lines in the 18f4550.inc file to do away with the overwrite errors, now I'm down to just these two,

Warning[202] \PBPPIC18.LIB 7695:argument out of range. least significant bits used.
Error[113]c:\pbp\usb18\march3.asm 177:Symbol not previously defined(_FCMEN_OFF_1H)

Skimask,
I tried the HSER_BAUD 38400, and it compiles fine, but the serial baud rate is not 38400. I have a program that is working great on an 16f877, and the hardware that it interfaces with will only work at 38400. If I stick the '877 in the same board it works perfectly, when I go back to the '4550 nothing happens, and when I tried a monitor program on another PC it shows garbage. I read in the manual that you won't always get an error if your define is incorrect, the compiler just ignores it. I suspect that I am overlooking something stupidly simple, but I'd rather look dumb and learn the answer than be dumb forever.

I ran out of memory on the '877, and I thought going to the '4550 and getting a USB port might be real handy later on.

Thanks guys for all your help. Have a great weekend!

Jerry.

[Darrel Taylor]

>> Error[113]c:\pbp\usb18\march3.asm 177:Symbol not previously defined(_FCMEN_OFF_1H)

You have an oldish version of MPASM. Change it to _FCMEM_OFF_1H. It was changed to FCMEN in the latest version.

If the other error is still there, you'll need to look in the .LST file, and search for [202].

[mister_e]

how about using the whole set bellow

    asm
    __CONFIG    _CONFIG1L, _PLLDIV_5_1L & _CPUDIV_OSC1_PLL2_1L & _USBDIV_2_1L  

    __CONFIG    _CONFIG1H, _FOSC_HSPLL_HS_1H & _FCMEN_OFF_1H & _IESO_OFF_1H 

    __CONFIG    _CONFIG2L, _PWRT_ON_2L & _BOR_ON_2L  & _BORV_2_2L  & _VREGEN_ON_2L   
    __CONFIG    _CONFIG2H, _WDT_OFF_2H 
    __CONFIG    _CONFIG3H, _MCLRE_ON_3H & _LPT1OSC_OFF_3H & _PBADEN_OFF_3H & _CCP2MX_ON_3H 
    __CONFIG    _CONFIG4L, _STVREN_ON_4L & _LVP_OFF_4L & _ICPRT_OFF_4L  & _XINST_OFF_4L & _DEBUG_OFF_4L 
    endasm

Sure this will not solve the warning 202...

I've tested it here... everything is clean.

[b1arrk5]

Thanks Darrel and Steve. No change. I did the online update yesterday for MicroCode Studio Plus, and I updated MPLAB. However after reading Darrel's reply I looked and found that it was using MPASM 3.x! I manually set it to use 5.06.4 (MPLAB is version 7.51) I found the error in the .lst file, but I don't know enough assembler to tell anything except that nowhere can I find an spbrgh register mentioned. If I am reading the datasheet correctly, when I enable the 16 bit baudrate generator I should have to set spbrgh (High byte) = 1, and spbrg (Low byte) = 56. I got these values from Steve's calculator program, which has never led me wrong! I did see on Bruce's website that PBP version 2.47 has some kind of fix for 18f devices to use spbrgh, so I think I'll give MELABS a call and inquire. I don't mind spending the money for the upgrade, I just hate waiting a week for UPS! Just as an after thought, did either of you verify that you were actually sending out serial at 38400? I can get it to compile fine using Skimask's suggestion, but the output is not 38400, even though there are no errors.
Thanks again!

Jerry.

[skimask]

I can get it to compile fine using Skimask's suggestion, but the output is not 38400, even though there are no errors.
Thanks again!

Jerry.

It worked for me, but maybe my crystal (10mhz using the 4xPLL) was being pulled off just far enough in the right direction to get the baud rate correct. The divider used for SERIN/SEROUT2 (1,000,000 / baud - 20) gets a bit low numerically in this case, even though the 'formula' says it's 'only' 4%+ off the mark.
And even though PBP 2.47 says it has a couple of extra defines and fixes specifically for PIC18Fxxxx and a couple of HSER fixes, surely you can set the bits in the middle of the program instead of letting PBP do it for you at the beginning...or something along those lines. Maybe PBP sets all the bits the first you use the command, so, send out a 'dummy' command, then try setting the bits manually after that? Who knows...might work...

[mister_e]

Yes the calc is good and PicMultiCalc.. of course

In fact i've tested with your crystal speed, my config fuses above, the DEFINEs generated by the PicMultiCalc, and add a HSEROUT ["Joyeux Noel et Bonne Année!!!",13,10] to do the test... all fine

So, OR your device programmer don't program the config fuse properly OR your crystal is pretty bad (2.00 MHZ instead of 20.00 MHz) OR your PIC is bad or Or the supply line is messy OR everything above + bad lucks (bad capacitor or bad value around the crystal)

I've tested with a USB to serial converter... still working.

If you want to use the EUSART, use the PicMultiCalc EUSART then paste the setting generated in your code. It have to work as well.

I don't know about the 18F fixes, but you could still write directly to the register instead of using DEFINEs to see if it solve some part of the problem.

we could still compile the code and send you the .HEX file. So you will know if it's related to V2.46... or back to the keyboard Just kidding!

Do you erase the PIC before programming it?