[ECOS] Running Firmware from external SRAM on AT91SAM7SE512

[ECOS] Running Firmware from external SRAM on AT91SAM7SE512

[ShiangLei]

Did anyone run its firmware from external SRAM (total 2MB address starts from
0x20000000)?
I am using the BDI2000 emulator to run the firmware. 
I have moved my firmware from the flash memory to the external SRAM, and I
encountered a problem that I cannot resolve. The firmware hang on the
cyg_thread_delay() function.  When stop the BDI2000, the external SRAM
become all 0xFF.
Did anyone has experience to resolve the issue?
 
-- 
View this message in context: http://old.nabble.com/Running-Firmware-from-external-SRAM-on-AT91SAM7SE512-tp26674151p26674151.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Running Firmware from external SRAM on AT91SAM7SE512

[Tom Deconinck]

On Mon, Dec 7, 2009 at 10:11 AM, Shiang Lei <slei02@yahoo.com> wrote:
> Tom:
>
> Thanks for e-mail me. My CPU is ARM 7 and the code can run on the external
> SRAM. The problem happened when running the cyg_thread_delay(). Timer
> interrupt occured inside the subroutine. I cannot step through the
> subroutine, it will not fail and can't exit either. If I let it ran and stop
> the BDI, the SRAM has been wiped out. No trace I can use to debug the
> problem.
>
> Regards,
> Shiang Lei
>
>

On AT91SAM7SE512 it is certainly possible to run code from SRAM and
SDRAM, I have done it in the past.
You need to figure out where you are jumping to when the interrupt
occurs and if the interrupt controllers are all mapped into the
correct address range. Check the ELF file to be sure.
Also, verify that your ELF file fits completely into the SRAM,
otherwise strange things are bound to happen.
The BDI probe will most likely reset the SRAM when stopped (if I
remember correctly).

Regards,
Tom

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Intel 82541 chipset (Pro/1000 GT Desktop adapter)

[Jim Bradleigh]

Hi,

I`ve been trying (with some success) to get the Intel 82544 driver to handle a standard 'Intel Pro 1000/GT Desktop adapter' (82541PI chipset). Apart from a tweak to fix EEPROM access (identical to the i82546 change) I can`t get it to work correctly.

The driver is running and I can see eCos ARP requests going to the driver, a few interrupts (Tx done?) being generated then things go silent. Its almost as if there is no incoming network traffic (therefore no Rx interrupts)

The internal state confirms the link as up and running at 100Mb/s (LED's also confirm) through successful auto-neg.

Does anyone have any idea's on why interrupts would not be occuring? (there's network traffic, mainly broadcast ARP's at the minute) or does anyone have this card up and running? I`ve stepped through alot of the driver execution and nothing appears too out of the ordinary.

Jim


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Intel 82541 chipset (Pro/1000 GT Desktop adapter)

[Jim Bradleigh]

"The internal state confirms the link as up and running at 100Mb/s (LED's also confirm) through successful auto-neg."

I got this part wrong, the register's show that the link is not 'up and running' - I`ll try to ignore auto-negotiation see if i can get it working..

Jim



----- Original Message ----
From: Jim Bradleigh <jim.bradleigh1@btinternet.com>
To: ecos-discuss <ecos-discuss@ecos.sourceware.org>
Sent: Monday, 7 December, 2009 15:26:37
Subject: [ECOS] Intel 82541 chipset (Pro/1000 GT Desktop adapter)

Hi,

I`ve been trying (with some success) to get the Intel 82544 driver to handle a standard 'Intel Pro 1000/GT Desktop adapter' (82541PI chipset). Apart from a tweak to fix EEPROM access (identical to the i82546 change) I can`t get it to work correctly.

The driver is running and I can see eCos ARP requests going to the driver, a few interrupts (Tx done?) being generated then things go silent. Its almost as if there is no incoming network traffic (therefore no Rx interrupts)

The internal state confirms the link as up and running at 100Mb/s (LED's also confirm) through successful auto-neg.

Does anyone have any idea's on why interrupts would not be occuring? (there's network traffic, mainly broadcast ARP's at the minute) or does anyone have this card up and running? I`ve stepped through alot of the driver execution and nothing appears too out of the ordinary.

Jim


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss