| View previous topic :: View next topic |
| Author |
Message |
aly
Guest
|
| B1 silicon Errata for 18f8722 |
 Posted: Fri Dec 19, 2008 6:43 am |
 |
|
Hi,
I have ordered 18f8722 ICs for my completed project. I got them and have SPI problem. I found B1 silicon errata and tried to solve the problem but I couldn't.
Is there anyone that handle this problem with ICs that has,
DeviceID : 00010100001;
RevID : 00010 ??? |
|
 |
Ttelmah
Guest
|
|
| Posted: Fri Dec 19, 2008 8:28 am |
|
|
This erratum, will not cause any nomal SPI operation to give problems. It only gives a problem, if you turn off the SPI, with the buffer full.
I have used the SPI on this chip with no problems at all, including using the same code on the older A1 silicon, which has a nuber of other issuse. Are you sure that your SPI code is capable of working?. Have you tried the same code, with a different PIC?.
However a search here, will find that I don't use CCS's code at all for SPI/I2C. I consider their routines 'poorly suited' for interrupt based SPI, and even more poorly documented...
Best Wishes |
|
|
aly
Guest
|
|
| Posted: Fri Dec 19, 2008 9:19 am |
|
|
The only difference between my working device and not working is the deviceID of the ICs(18f8722).
If not working IC replace with the other IC (both of them has the same firmware), system works fine.
NOTE: I use hardware SPI and CCS codes for spi communication. I tried all possible spi setup. And I also checked the signal with a oscilloscope. Signal timings seems to be good.
This is a part of my code that controls Atmel's Dataflash;
| Code: |
void memo_page_read (BYTE which_chip,int16 page_add,int16 byte_add,int16 data_len,BYTE *ptr_data_buff)
{
int16 i;
page_add<<=2;
if (byte_add & 0x0100) page_add |= 0x0001;
if (byte_add & 0x0200) page_add |= 0x0002;
flash_select(which_chip);
spi_write(0xd2);
spi_write(page_add >> 8);
spi_write(page_add);
spi_write(byte_add);
//DUMMY BYTES
spi_write(0xFF);
spi_write(0xFF);
spi_write(0xFF);
spi_write(0xFF);
for (i=0;i<data_len;i++)
{
*ptr_data_buff=spi_read(0);
ptr_data_buff++;
}
flash_deselect(which_chip);
}
/*//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////*/
void flash_select (BYTE chip)
{
switch(chip)
{
case Info_Recorder :output_low(Info_Recorder_pin);break;
case Event_Recorder:output_low(Event_Recorder_pin);break;
default:break;
}
delay_us(1);
}
/*//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////*/
void SPI_Init (void)
{
setup_spi(SPI_MASTER|SPI_L_TO_H|SPI_CLK_DIV_16);
delay_ms(2);
output_low(Info_Recorder_pin);
output_low(Event_Recorder_pin);
delay_ms(2);
output_high(Info_Recorder_pin);
output_high(Event_Recorder_pin);
delay_ms(2);
}
|
|
|
|
Ttelmah
Guest
|
|
| Posted: Fri Dec 19, 2008 9:43 am |
|
|
You don't show the 'flash_deselect' code, which is the only routine that could hit that erratum....
Best Wishes |
|
|
aly
Guest
|
|
| Posted: Fri Dec 19, 2008 9:49 am |
|
|
oopss.
Waiting your suggestions...
Thank and regards.
| Code: |
void flash_deselect (BYTE chip)
{
delay_us(1);
switch(chip)
{
case Info_Recorder :output_high(Info_Recorder_pin);break;
case Event_Recorder:output_high(Event_Recorder_pin);break;
default:break;
}
}
|
|
|
|
Charlie U
Joined: 09 Sep 2003
Posts: 183
Location: Somewhere under water in the Great Lakes
|
|
| Posted: Fri Dec 19, 2008 12:24 pm |
|
|
It looks like in your spi init routine that you are setting up the spi to
operate in Mode 1. I did a quick review of the Atmel website, and it
looks like most if not all of the data flash parts require either mode 0 or 3.
To operate in mode 0 you should add SPI_XMIT_L_TO_H to your or'd
setup parameters. Trying to talk to a peripheral in the wrong mode may
sometimes work depending on exact timing, but could vary from chip to
chip either master or slave.
Many people that post here use some variation of defines for the spi modes like the following:
| Code: | #define SPI_MODE_0_0 SPI_L_TO_H|SPI_XMIT_L_TO_H // 0x4000
#define SPI_MODE_0_1 SPI_L_TO_H // 0x0000
#define SPI_MODE_1_0 SPI_H_TO_L // 0x0010
#define SPI_MODE_1_1 SPI_H_TO_L|SPI_XMIT_L_TO_H // 0x4010
|
Then they just include the mode in the setup. |
|
|
aly
Guest
|
|
| Posted: Mon Dec 22, 2008 1:44 am |
|
|
thanks you,
It's Ok now with mode change. But doesn't it seem to be so strange.
I just replaced the same IC with different id and I wasted my week.
Anyway, thank you all.
Thanks and regards. |
|
|
Ttelmah
Guest
|
|
| Posted: Mon Dec 22, 2008 3:30 am |
|
|
The thing is that with the timing set 'wrong', it'll still work, if the clock signal is fractionally delayed compared to the data sampling. I'd suspect you were finding a tiny timing error in the old IC, which just happened to allow the incorrect setting to work. The new IC, is timing more correctly, and showing the error. Probably a matter of a few nSec difference in the actual gate timings inside the chip....
Best Wishes |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
