[En-Nut-Discussion] SRAM errors on ETHERNUT 1.3H
Pascal Jean
I want to use ETHERNUT1 without NUT/OS.
I designed a unit test of the external SRAM memory similar to the program
BASEMON.
I write 0xFF throughout memory then I do a reading verification.
I see mistakes in the following address ranges:
0x1300-0x1316
0x1700-0x1716
0x1B00-0x1B16
0x1F00-0x1F16
0x2300-0x2316
...
For each address range, the false values are identical (I use AVRDRAGON with
JTAG to put a breakpoint and read the SRAM). Addresses suggest that the
problem is related to the address line A9-A10 and I wonder if this is
notan RTL8019's
mistake ?
So I think it's not a memory error. The NAND gate on the signal A15 is not
broken.
I see the same problem in the function of XMemTest BASEMON except that this
function does not report the problem to display! (static variables store the
last error but are not displayed!).
Would you ever encountered this problem or an idea of the origin of this
problem?
Thank you !
Best regards.
Pascal
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
Harald Kipp
On 29.03.2012 17:17, Pascal Jean wrote:
> I want to use ETHERNUT1 without NUT/OS.
> I designed a unit test of the external SRAM memory similar to the program
> BASEMON.
The Realtek connection to the memory bus is really tricky.
To avoid this, you can follow
http://www.ethernut.de/en/hardware/enut1/
"How to Make Rev-G and Rev-H Compatible to Rev-F"
Otherwise you need to emulate the Realtek's EEPROM. If not executed, the chip will interfere with the memory bus and spoil your memory test.
http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/nut/arch/avr/board/ethernut1.c
Background: The RTL80192AS incorrectly negotiates the link. The switch thinks, it is half-duplex, but the RTL8019 uses full-duplex. If the RTL8019 transmits a packet while the switch is transmitting, the switch will discard the packet. To avoid this, the RTL8019 must be set to half-duplex. However, this can be done via EEPROM only, which is not available on Ethernut 1. Rev-F boards "emulated" the EEPROM by setting all bits to 1 (via resistor), which automatically enables full-duplex. So we need to set a specific EEPROM bit to 0. The solution was to emulate the EEPROM by the ATmega. In order not to waste port pins for this, Ethernut 1 temporarily uses the upper address bits to emulate an EEPROM.
As I told you, quite tricky.
Regards,
Harald
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion