MikroC Ethernet lib RX filters wrong ...

[srdjan]

At our products (devices) this issue was signaled when was changed PIC18F452 with PIC18F4520.

- Yes, thats how we found it also.

Also appear randomly, not to all PIC18F4520 in my case.

- That's exactly the point. It looks like that this silicon bug exists only in A revisions of mentioned MCUs. We would be making an exception if we put this in the library. We can not go through all existing erratas implementing silicon revisions specific workarounds.
We'll have to think about this and make the final judgment. If we do it, it will be done in all pic18 family i2c libraries.
If anyone should have some additional comments or suggestions, I'll be more than happy to listen, as always

[yo2lio]

Questions :

How many MCU's with this BUG exist now on the market ?

What happened when users (customers) get one of this MCU's, and try to work with I2C library ?

I tell you what happened , FIRST IMPRESSION, BUG in I2C library and post this on the forum.
This it's not the real true !

Now, in all my programs with PIC18 , where I use I2C library , I put described sequence in ERATA, before of I2C_Init routine. Just in case.

[srdjan]

Questions :

How many MCU's with this BUG exist now on the market ?

What happened when users (customers) get one of this MCU's, and try to work with I2C library ?

I tell you what happened , FIRST IMPRESSION, BUG in I2C library and post this on the forum.
This it's not the real true !

Now, in all my programs with PIC18 , where I use I2C library , I put described sequence in ERATA, before of I2C_Init routine. Just in case.

OK,
You got me there. If nobody else abjects here this till Monday, I'll implement this workaround in the library.
Thanks.

[srdjan]

Questions :

How many MCU's with this BUG exist now on the market ?

What happened when users (customers) get one of this MCU's, and try to work with I2C library ?

I tell you what happened , FIRST IMPRESSION, BUG in I2C library and post this on the forum.
This it's not the real true !

Now, in all my programs with PIC18 , where I use I2C library , I put described sequence in ERATA, before of I2C_Init routine. Just in case.

OK,
You got me there. If nobody else abjects here this till Monday, I'll implement this workaround in the library.
Thanks.

Done, as promised.

[yo2lio]

Hi,

New datasheet available for PIC18F97J60 family.

Date : 13 February 2008.

http://ww1.microchip.com/downloads/en/D ... 39762d.pdf

Interesting :

Chapter 18.2.1.1 Reading and Writing to the Buffer

[srdjan]

Hi yo2lio,

Hi,

New datasheet available for PIC18F97J60 family.

Date : 13 February 2008.

http://ww1.microchip.com/downloads/en/D ... 39762d.pdf

Interesting :

Chapter 18.2.1.1 Reading and Writing to the Buffer

I did not notice any differences, in this chapter, in new and data sheet I already have. Could you be more specific?

[yo2lio]

Hi yo2lio,
I did not notice any differences, in this chapter, in new and data sheet I already have. Could you be more specific?

Probably my datasheet was very old !

[srdjan]

Hi yo2lio,
I did not notice any differences, in this chapter, in new and data sheet I already have. Could you be more specific?

Probably my datasheet was very old !

I downloaded mine on 24/12/2007.
However, I have found something that worries me :

While sequentially reading from the receive buffer, a
wrapping condition will occur at the end of the receive
buffer. A read of EDATA from the address programmed
into the ERXND Pointers will cause the ERDPT
registers to be incremented to the value contained in
the ERXST Pointers. Writing to the buffer, on the other
hand, does not result in automatic wrapping.

Did i get it right? Write pointer EWRPT does not wrap automatically. This was not the case with enc. I'll have to check the library for this implementation.
Have you experienced some problems so far with this issue?

[yo2lio]

Did i get it right? Write pointer EWRPT does not wrap automatically. This was not the case with enc. I'll have to check the library for this implementation.
Have you experienced some problems so far with this issue?

No because in my library I don't use wrapping condition for the TX buffer.

Each packet start at the TXSTART address ... I don't use circular buffer for the TX buffer.

[bruno]

@Srdjan :

yes it is the same for ENC28J60 :

3.2.3 READING AND WRITING TO
THE BUFFER
The Ethernet buffer contents are accessed from the
host controller though separate read and write pointers
(ERDPT and EWRPT) combined with the read buffer
memory and write buffer memory SPI commands.
While sequentially reading from the receive buffer, a
wrapping condition will occur at the end of the receive
buffer. While sequentially writing to the buffer, no wrapping
conditions will occur.

anyway, as Florin I don't use circular buffer to transmit too

[srdjan]

Hi,
You are both totally right, which makes me an ...
I guess that I'll have to take some rest...