 |
 |
| View previous topic :: View next topic |
| Author |
Message |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
 Posted: Tue Aug 16, 2005 6:12 pm |
 |
|
It may be that you have found a new silicon bug.
To try to narrow down the problem, I would disable anything unusual.
I notice that you're using the EMCU fuse. You might try disabling that,
and disable interrupts, and anything else that might cause the processor
to act weird. I assume that you'd have to add a little dummy code to
get the program out to the same size as before.
---------------
In this thread from late 2002, they're discussing a bug that occurs
when a jump or call is done across an address boundary, but your
problem occurs before a major boundary.
http://www.ccsinfo.com/forum/viewtopic.php?t=360 |
|
 |
raljones
Joined: 11 Aug 2005
Posts: 11
|
|
| Posted: Wed Aug 17, 2005 12:55 pm |
|
|
I pretty much need all the interrupts I'm using, if I turn any off it won't work.
I've tried turning off the EMCU fuse. Kills external RAM access, but otherwise has no effect.
I'm still perusing the data sheet and erata documents.
Here is my port initialization. I think it's all ok.
I don't think I'm setting the "don't take BRA" bit.
| Code: |
void init_pic_io() // initialize hardware
{
setup_external_memory(EXTMEM_BYTE_SELECT);
#USE STANDARD_IO(a)
#USE STANDARD_IO(b)
#USE STANDARD_IO(c)
#USE STANDARD_IO(d)
#USE STANDARD_IO(e)
#USE STANDARD_IO(f)
#USE STANDARD_IO(g)
#USE STANDARD_IO(h)
#USE STANDARD_IO(j)
// Port A init
output_low(PIN_A0); // SCK - SPI bus clock
output_low(PIN_A1); // SDI - SPI bus Data in to peripheral
output_float(PIN_A2); // SDO - SPI bus Data out from peripheral
output_high(PIN_A3); // /CS A/D 24 bit REF / MEAS detectors
output_high(PIN_A4); // /CS A/D 12 bit TEMP / PWR / AUX
output_low(PIN_A5); // n/c
output_high(PIN_A6); // /reset out
// Port B init
output_float(PIN_B0); // Interrupt input from keyboard
output_float(PIN_B1); // Interrupt input from Expansion module
output_float(PIN_B2); // Flow Switch input
output_float(PIN_B3); // Maintenence mode switch input
output_float(PIN_B4); // Front Panel Zero Button input
output_float(PIN_B5); // Front Panel Pressure Button input
output_high(PIN_B6); // PGC pin to programmer / debugger
output_high(PIN_B7); // PGD pin to programmer / debugger
// Port C init
output_low(PIN_C0); // n/c
output_low(PIN_C1); // n/c
output_low(PIN_C2); // n/c
output_low(PIN_C3); // I2C SDA
output_low(PIN_C4); // I2C SCL
output_low(PIN_C5); // COM1, RS485 Driver Enable, Active High, receive mode default
output_high(PIN_C6); // COM1, RS485 TX Pin (don't init TX to low, screws things up!)
output_float(PIN_C7); // COM1, RS485 RX Pin
// Ports D&E are used for External RAM access
// Port D init
// Port E init
// Port F init
output_float(PIN_F0); // -RS232 select input // 0 = selected
output_float(PIN_F1); // -RS485 select input // only one of these 3 should
output_float(PIN_F2); // -Ethernet select input // be selected at a time
output_low(PIN_F3); // Ethernet select output, 1 = power on to Ethernet port
output_high(PIN_F4); // -Ethernet reset output, 0 = reset Ethernet port
output_low(PIN_F5); // Lamp Control, 1 = lamp on
output_low(PIN_F6); // Heat On, 1 = heater on
output_low(PIN_F7); // Valve, 1 = Autozero Valve on
// Port G init
output_low(PIN_G0); // COM2, RS485 Driver Enable, Active High, receive mode default
output_high(PIN_G1); // COM2 TX (don't init TX to low, screws things up!)
output_float(PIN_G2); // COM2 RX
output_float(PIN_G3); // AUX1, Optically isolated input
output_float(PIN_G4); // AUX2, Optically isolated input
// Port H init
// output_low(PIN_H0); // XRAM A16
// output_low(PIN_H1); // XRAM A17
// output_low(PIN_H2); // XRAM A18
// output_low(PIN_H3); // XRAM A19
output_low(PIN_H4); // n/c
output_high(PIN_H5); // csx1
output_high(PIN_H6); // csx2
output_high(PIN_H7); // csx3
setup_external_memory(0x31); // byte select mode, 0 wait states
dac_out(0);
ibuf1[0] = '\x0'; // init com1 buffer
bidx1 = 0; // and index
init_ibuf2(); // init buffer
setup_timer_1(T1_INTERNAL|T1_DIV_BY_8);
set_timer1(62500); // set for 10ms interrupt
enable_interrupts(INT_TIMER1); // allow timer interrupt
enable_interrupts(INT_RDA); // allow UART1 interrupt
enable_interrupts(INT_RDA2); // allow UART2 interrupt
enable_interrupts(GLOBAL);
}
|
|
|
|
Marko
Guest
|
|
| Posted: Wed Aug 17, 2005 11:15 pm |
|
|
I have a similar problem with 18F6720, it hangs when I want to send data
over rs232. I discovered, that the TXSTAx register and some other registers are not set, but in the .lst file is all OK. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Aug 18, 2005 1:00 am |
|
|
How much more do you want to experiment with this chip or this PIC ?
What if they didn't really fix the problem with corrupted instruction
fetches at frequencies above 4 MHz, that's mentioned in the A3 errata ?
If you want to do experiments, you could try locking out the compiler
from using the last 1 KB in that range. The #org statement shown below
will do that. This will force the compiler to move some functions above
the 0x8000 address boundary. The chip may behave differently.
I don't know -- do you want to trust it ? In the latest errata for the
Rev A4 chips, they still say it has the reset bug. CCS doesn't try to
compensate for that bug by implementing the suggested work around
of a NOP at 0x0000. CCS has a GOTO instruction at 0x0000.
You could try other things such as seeing if the problem is sensitive
to heat or cold: Freeze the PIC with freeze-spray.
| Quote: |
#include <18F8720.H>
#fuses XT, NOWDT, NOPROTECT, BROWNOUT, PUT, NOLVP
#use delay(clock=4000000)
// Prevent the compiler from using the last 1KB in the first 32K of ROM.
#org 0x7C00, 0x7FFF {}
void main()
{
while(1);
} |
|
|
|
raljones
Joined: 11 Aug 2005
Posts: 11
|
|
| Posted: Thu Aug 18, 2005 1:14 pm |
|
|
Guess what?
I updated MPLAB from Ver 6.2 to Ver 7.0 and the problem vanished.
I guess this is why lots of other people weren't having this same problem.
Thank you all for your help, I'm going to get back to work. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Aug 18, 2005 1:25 pm |
|
|
What do you think was causing the problem ?
Right here you said:
| Quote: | | Without the debugger, it hangs, but there is no way to see where. |
So that means the chip failed when running in standalone mode.
So how could MPLAB affect that ?
With the upgrade to vs. 7.20, you would likely get a new ICD2 firmware.
If the programming algorithm in the ICD2 wasn't working correctly
for the 18F8720, I suppose that bits in the program memory might
be flakey ? Bits in certain sections of memory might not be
programmed thoroughly enough, so that they could sometimes be
read as a 1 when they should be 0, and vice versa ? This might
explain it. |
|
|
merca
Guest
|
| Re:Crash when code size exceeds 32k |
| Posted: Fri Sep 16, 2005 4:21 am |
|
|
I have the same problem, and I would like to know if you are resolve the problem ?
I'm using 18F8720 and when I exceed 50% of ROM, the program no start at the power on.
I've compiled it on version 3.203 of CCS.
Thanks |
|
|
chargedneuron2
Guest
|
|
| Posted: Tue Mar 25, 2008 1:21 am |
|
|
I have the same issue with the PIC16F77 with the v 4.069 compiler. Program hangs at power up when the code exceeds 50%
Anyone got an idea here? |
|
|
chargedneuron2
Guest
|
|
| Posted: Tue Mar 25, 2008 1:27 am |
|
|
Found my issue and I am not afraid to admit it was my fault... (sorta)
You MUST be sure that MPLAB has the correct device selected even if you select a device in CCS.
I called for a PIC16F77 but MPLAB was set to a PIC16F74. My ICD2 knew I didnt have the space to store my program and so it didnt program beyond 50%... |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
