| View previous topic :: View next topic |
| Author |
Message |
georpo
Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.
|
| PIC24FJ256GA110 VS PIC24FJ128GA110 |
 Posted: Wed Mar 30, 2022 6:50 am |
 |
|
Hello!
I have a finished working code for PIC24FJ256GA110 and I want to change to PIC24FJ128GA110 because of availability.
When I change to "#include <24FJ128GA110.h>" I get:
"*** Error 96 "v1.c" Line 32(5,49): Baud rate out of range"
I compared the 2 .h files, they are the same except of course for the size.
Any ideas?
Thanks in advance.
| Code: |
#include <24FJ128GA110.h>
#device ADC=10
#FUSES NOWDT //Watch Dog Timer
#FUSES NOPROTECT //Code not protected from reading
#FUSES FRC_PLL //Internal osc + PLL
#FUSES NOIESO //Internal External Switch Over mode disabled
#FUSES NOPR //Pimary oscillator disabled
#FUSES OSCIO //OSC2 is general purpose output
#FUSES NOCKSFSM //Clock Switching is disabled, fail Safe clock monitor is disabled
#FUSES NOWRT //Program memory not write protected
#FUSES NODEBUG //No Debug mode for ICD
#BUILD (stack=1024)
#use delay(int=32M)
#use fast_io(A)
#use fast_io(B)
#use fast_io(C)
#use fast_io(D)
#use fast_io(E)
#use fast_io(F)
#use fast_io(G)
#pin_select U1TX = PIN_D8
#pin_select U1RX = PIN_A15
#pin_select OC1 = PIN_F4
#use rs232(BAUD=115200,UART1,ERRORS,stream=COM1)
#word LATA=getenv("SFR:LATA")
#word LATB=getenv("SFR:LATB")
#word LATC=getenv("SFR:LATC")
#word LATD=getenv("SFR:LATD")
#word LATE=getenv("SFR:LATE")
#word LATF=getenv("SFR:LATF")
#word LATG=getenv("SFR:LATG")
#word TRISA=getenv("SFR:TRISA")
#word TRISB=getenv("SFR:TRISB")
#word TRISC=getenv("SFR:TRISC")
#word TRISD=getenv("SFR:TRISD")
#word TRISE=getenv("SFR:TRISE")
#word TRISF=getenv("SFR:TRISF")
#word TRISG=getenv("SFR:TRISG")
#word PORTA=getenv("SFR:PORTA")
#word PORTB=getenv("SFR:PORTB")
#word PORTC=getenv("SFR:PORTC")
#word PORTD=getenv("SFR:PORTD")
#word PORTE=getenv("SFR:PORTE")
#word PORTF=getenv("SFR:PORTF")
#word PORTG=getenv("SFR:PORTG")
|
_________________
George. |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Wed Mar 30, 2022 7:35 am |
|
|
hmm, I'd think either Baudrate not within 3% rule (?) of the actual speed or can't get that speed with the clock.....
but..
I suspect maybe a header file bug ?? as the 2 PIC are 'similar' ?? |
|
|
georpo
Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.
|
|
| Posted: Wed Mar 30, 2022 7:43 am |
|
|
they are both on the same pdf, the same family. only the size changes. I compared the 2 header files with notepad ++. they are the same. if I set for example baud rate 256000 it compiles so it is not a matter of speed.
it should just work out of the box
_________________
George. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Wed Mar 30, 2022 7:46 am |
|
|
You'll need to contact CCS.
Almost certainly something incorrect in the database entry for the smaller
chip.
It's accepted for the 192, and the 256, but not the 128. They all have the
same specs (beware the RC oscillator is not accurate enough if you are
at anything other than 'room temperature'). |
|
|
georpo
Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.
|
|
| Posted: Wed Mar 30, 2022 8:00 am |
|
|
can I fool the compiler to compile somehow?
is it acceptable to have 2 declarations of use delay?
_________________
George. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Wed Mar 30, 2022 8:36 am |
|
|
| you could just load the UART SFRs with the correct bits...... |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1907
|
|
| Posted: Wed Mar 30, 2022 8:42 am |
|
|
Just set the baud rate register(s) manually.
For example:
| Code: | #word WHATEVER_REG = getenv("SFR:WHATEVER_REG")
// set baud rate yourself
WHATEVER_REG = 0x8745; // for example, read the data sheet to figure out the correct register(s) and register value(s) |
|
|
|
dyeatman
Joined: 06 Sep 2003
Posts: 1933
Location: Norman, OK
|
|
| Posted: Wed Mar 30, 2022 9:28 am |
|
|
It does appear to be an issue with the device file.
The 128 device file says BRGH cannot be set to 1 and the 256 allows it.
The family datasheet shows BRGH set to 1 as an option so this apparently is wrong in the 128 header file.
_________________
Google and Forum Search are some of your best tools!!!! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Wed Mar 30, 2022 9:56 am |
|
|
Do you have the IDE?.
If so you can fix this. Tools, Device Editor. Select the 128. Then in errata
(bottom slightly right of centre of the page), untick 'BRGH can not be 1',
and save.
The chip has got a couple of UART errata, but not this one.
Tell CCS though, they will almost certainly fix the database in a few hours.
The easy way though it just to add BRGH1OK to your #use rs232 line,
which overrides this on chips that have problems with this bit... 
#use rs232(BAUD=115200,BRGH1OK,UART1,ERRORS,stream=COM1) |
|
|
georpo
Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.
|
|
| Posted: Wed Mar 30, 2022 10:06 am |
|
|
Yes I have IDE.
I will try the
#use rs232(BAUD=115200,BRGH1OK,UART1,ERRORS,stream=COM1)
and I will update here.
Thanks a lot for all your support guys!!!
_________________
George. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1345
|
|
| Posted: Wed Mar 30, 2022 2:01 pm |
|
|
| Out of curiosity, could it be errata related? Maybe the two different sizes were in different chip revisions? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Thu Mar 31, 2022 12:39 am |
|
|
I checked the errata sheet, and the chip doesn't have the BRGH erratum.
This has been quite common. I think 'by default' the code CCS use to
generate the database, sets this erratum bit. It was so common in the
earlier PIC's (probably 90+% of the early PIC's had this fault). I don't think
any PIC24 does. You'll find threads here from 10+ years ago, when the
first chips started to appear that didn't have this fault, with the compiler
almost universally refusing to set the bit. This was why CCS added the
BRGH1OK flag, so you could override the compiler it it was setting this,
on chip that didn't have the problem.
Slowly the database has got better, so it is now 'rare', and it is rather
unusual to have it on just one chip in a 'family'. You'd have expected
the database entries to all have been done at the same time. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
