This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Philips LPC2294


On Mon, Sep 06, 2004 at 10:14:30AM +0100, Nick Garnett wrote:

| Xavier <xavier@localhost.localdomain> writes:
| 
| > Neglecting the stuff inside the #ifndef/#endif the assumption here, I believe, is that 'ram' is
| > at 0x0, and 'rom' is at 0x__exception_handlers (or there about); and as such, the swi interrupt
| > needs to be relocated from ram to rom.  In the case of the LPC2xxx, this isn't true; well, I'm
| > certain that this isn't true of the LPC2294 and neighbors, not certain about the whole LPC2xxx
| > family.  None the less, when the instruction:
| > 
| >         str r2,[r0,#0x08]
| > 
| > is executed, the processor hangs.  I believe that a 'undefined_instruction' exception occurs,
| > and then .... well, everything melts down.  This particular assumption occurs at a number of
| > points during the bootup procedure, 'warm_reset' and 'start'.
| 
| Other members of the LCP2xxx family have an mechanism for remapping
| the lowest 64 bytes from various different memory areas. eCos should
| run with RAM mapped in there.  You need to work out how to make
| that happen.

OK, got that part worked out .... <sigh> ... I guess I 'glossed over' that tidbit ...

Setting MEMMAP = 0x2 did the trick.

| Even if the above str instruction is writing to ROM, it should not
| generate an invalid instruction exception, or freeze the CPU. Maybe
| the system is freezing waiting for the write to complete, or

Possible -- I don't know what, exactly, was going on.

| something. How are you currently debugging this? If you are using a
| JTAG debugger and that hangs, then something hardware related is
| happening.

I wish.  Much more 'brute force' -- CYGHWR_LED_MACRO, occasionally, just occasionaly that is, life sucks.

Now I seem to be stuck looping back to 'reset_vector' after getting into 'start'.  Strange.
What could cause it to jump back to 'reset_vector'?  ... hmmm ... must dig further.
However, I am making progress ... slow progress, but 'progress' none the less.

| > One more thing, while not critical, but thought I should ask:
| > 
| > According to this comment, found in packages/hal/arm/arch/v2_0/src/vectors.S:
| > 
| >         // Run kernel + application in THUMB mode
| >         THUMB_MODE(r1,10)
| > 
| > The kernel and application will be runin thumb mode, I would prefer to run in ARM mode as that will
| > enrichen the instruction set, and I'm not (currently) concerned about the memory savings (waste?)
| > (though, that may change).
| 
| That macro only switches to Thumb mode when you explicity configure
| eCos to run in Thumb mode. By default it runs in ARM mode. Take a look
| at the definitions of the macro at the top of the file.

Yes, I found that shortly after hitting 'send' ...

Thank you for your response.

| -- 
| Nick Garnett                    eCos Kernel Architect
| http://www.ecoscentric.com/     The eCos and RedBoot experts
| 
| 
| -- 
| 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]