 |
 |
| View previous topic :: View next topic |
| Author |
Message |
affonso.industra
Joined: 31 Jan 2013
Posts: 6
|
| Trouble with PIC24EP512GU810 and PCD Compiler |
 Posted: Thu Jan 31, 2013 9:37 am |
 |
|
Hello,
My name is Alex and I'm developing a firmware for PIC24EP512GU810 using PCD compiler from CCS.
I'm facing some troubles with I2C using PCD compiler: my code works fine, but when I reset the PIC24 by MRCLR (using PICkit 3) the I2C stops working - all other parts of the code restart and work fine, but only I2C stop to work. After a new power on (turn off, wait some seconds and turn on again), the I2C works fine again, but if I reset the PIC24 by MRCLR, I2C stop to work.
Here are some parts of my code:
| Code: |
#include <24EP512GU810.h>
#fuses HS,NOPROTECT,NOWDT, NOALTI2C2
#use delay(clock = 70000000, crystal=20000000)
// UART1:
#pin_select U1TX=PIN_D15
#pin_select U1RX=PIN_D11
#use rs232(baud=115200,UART1, XMIT = PIN_D15, RCV = PIN_D11, PARITY = N, BITS = 8,STOP = 1, STREAM = IHM1)
// UART2:
#pin_select U2TX=PIN_F0
#pin_select U2RX=PIN_D12
#use rs232(baud=115200,UART2, XMIT = PIN_F0, RCV = PIN_D12, PARITY = N, BITS = 8,STOP = 1, STREAM = IHM2)
#use i2c(master, sda=PIN_F4, scl=PIN_F5, fast = 400000, force_hw, stream = I2CDAC)
...
i2c_start(I2CDAC);
i2c_write(I2CDAC, endereco_i2c);
i2c_write(I2CDAC, 0x20);
i2c_write(I2CDAC, temp_pos_msb);
i2c_write(I2CDAC, temp_pos_lsb);
i2c_stop(I2CDAC);
|
I don't know why, but if I use the directive below it works better:
| Code: | #zero_ram
#BUILD(RESET=0x0000,INTERRUPT=0X0004)
|
I compared the asm code with or without this directive, but I could not understand the differences on that.
Even more, if I use the option force_sw on directive "#use i2c()", it works fine all the time:
| Code: |
#use i2c(master, sda=PIN_F4, scl=PIN_F5, fast = 400000, force_sw, stream = I2CDAC) |
Could you help me with this?
Thanks a lot for any assistance!
Best regards,
Alex |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19333
|
|
| Posted: Thu Jan 31, 2013 9:53 am |
|
|
First, try enabling BROWNOUT in the fuses. There is an erratum for this chip, which _requires_ this to be set....
Might be your problem.
Come back if this doesn't improve things.
Best Wishes |
|
|
affonso.industra
Joined: 31 Jan 2013
Posts: 6
|
|
| Posted: Thu Jan 31, 2013 10:29 am |
|
|
| Ttelmah wrote: | First, try enabling BROWNOUT in the fuses. There is an erratum for this chip, which _requires_ this to be set....
Might be your problem.
Come back if this doesn't improve things.
Best Wishes |
I used both fuses BROWNOUT and NOBROWNOUT and the results were exactly the same as described before - it didn't work. Do you have any other idea about this issue?
About this errata of BROWNOUT fuse: where is it available? At Microchip? I didn't find it yet.
Thanks,
Alex |
|
|
affonso.industra
Joined: 31 Jan 2013
Posts: 6
|
|
| Posted: Thu Jan 31, 2013 12:14 pm |
|
|
Doing some tests I noticed that after I2C stops working, which occur after a reset condition, I2C only starts working again after a new power up. It seems to be impossible to put I2C working again without a new power up.
Could this problem be a compiler problem? Or, are there any problems with my code? |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1322
|
|
| Posted: Thu Jan 31, 2013 7:23 pm |
|
|
| Try disabling the I2C module both using the enable bit in the control register and in the peripheral module disable (PMD) register. Wait a slight bit of time and re-enable them. The I2C modules on a lot of the PIC24 chips are riddled with hardware issues. The errata is located a couple links below the data sheet of a pic on the microchip website page for the chip. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Fri Feb 01, 2013 12:10 am |
|
|
Did you check if I2C failure is caused by a specific I2C device that locks the bus? This may happen if e.g. an ongoing I2C transaction is interrupted by the reset, or an illega bus sequence is generated otherwise.
In this case, a dedicated I2C reset sequence acording to the NXP I2C specification should help. |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Fri Feb 01, 2013 7:17 am |
|
|
| It is likely CCS isn't ready for this chip. I never could get the CCS debugger to work with this chip even with a simple flash a led test project. It is is a bit cumbersome to get this chip oscillating with an external oscillator but it does eventually oscillate. The enticements to use this chip is its ability to handle lots of code with higher MIPS but then again lots of code means debugging support is also needed. Until simple things work reliably using this chip may not be a smart choice. |
|
|
affonso.industra
Joined: 31 Jan 2013
Posts: 6
|
|
| Posted: Fri Feb 01, 2013 10:16 am |
|
|
| Douglas Kennedy wrote: | | It is likely CCS isn't ready for this chip. I never could get the CCS debugger to work with this chip even with a simple flash a led test project. It is is a bit cumbersome to get this chip oscillating with an external oscillator but it does eventually oscillate. The enticements to use this chip is its ability to handle lots of code with higher MIPS but then again lots of code means debugging support is also needed. Until simple things work reliably using this chip may not be a smart choice. |
Douglas: I have a very complex code working for this part and everything seems to work fine...
I tested this I2C trouble and discovered that this happens only when I reset the PIC by PICkit 3 and I2C continues working fine after a reset from an external WDT in my board...
I have already reseted my PIC by external WDT more than 2000 times and I2C continues working fine (I wrote a code to test that). But, a single reset using PICkit 3 stops only I2C and all other parts continue working (TIMERs, UART, etc).
For me, it seems to be a problem of PICkit 3 or maybe some thing wrong with this part or this unit that I'm testing, but this model seems to be very nice, up to now...
Thanks,
Alex |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Fri Feb 01, 2013 4:22 pm |
|
|
| I also loaded a very lengthy chunk of code and it would run well as long as I never tried to debug it. By well I mean it displayed the results I expected and that I had got from the same code in another chip. Now the debugger needs resources... stack and code space that's usually high in ROM. The CCS debugger is probably broken on this chip so I suspect other things might also be broken...and in case some suspect the PGD PGC ports aren't correct. I'm definitely using the right one both in FUSES and ICD=xxxx. Anyway it isn't the code size since simple code also bombs the debugger...most of the time it can't sync to the freq and occasionally runs a few lines and freezes. |
|
|
|
|
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
