Re: Redboot hanging during boot on EP9302

Hi Andrew,

You misaddressed this to ecos-devel-owner instead of ecos-devel. I've CC'd 
it to ecos-devel for you in case anyone can help.

For what it's worth, in the 9 times out of 10 it works, is it solid? Might 
it be worth trying out the eCos "heaptest" test (perhaps increasing the 
iterations) to verify the stability of SDRAM in case the timings are marginal?

Jifl

Andrew McKay wrote:
> Hey guys,
> 
> I'm having issues with our EP93xx hanging during reboots with an 
> external watchdog.  It crashes 1 out of every 10 reboots or so.  I the 
> code is crashing in two places (that I've found so far).  The first is 
> when the code attempts to jump to code in RAM copied out of flash.  The 
> second is when the Intel Strata flash driver copies it's routine to RAM 
> and tries to jump to it.  The second case is a bit silly because the 
> code is already executing from RAM.  I think that it makes the 
> assumption that it is executing in Flash, that's why the driver makes 
> another copy of a routine in RAM.
> 
> The EP93xx code I'm using is from Cirrus Logic's 1.3.0 patches that they 
> supplied with the processor.  I also have their 1.4.5 patches, though 
> we're not using that code for our current bootloader.  On a quick look 
> it didn't appear that there was any major differences in SDRAM setup and 
> configuration.
> 
> Anyways the ep93xx's platform set up code the following happens:
> 
>         ldr     r0,=__rom_vectors_lma   // Relocate FLASH/ROM to RAM
>         ldr     r1,=__rom_vectors_vma   // ram base & length
>         ldr     r2,=__ram_data_end
> 20:     ldr     r3,[r0],#4
>         str     r3,[r1],#4
>         cmp     r1,r2
>         bne     20b
> 
>         //Jump to ram
>         //
>         ldr     r0,=30f
>         mov     pc,r0
>         nop
>         nop
>         nop
>         nop
> 30:
>         // Turn on Green LED, Turn off the Red LED.
>         //
>         ldr     r1, =EP9312_LED_DATA
>         ldr     r0, [r1]
>         eor     r0, r0, #(EP9312_LED_GREEN_ON | EP9312_LED_RED_ON)
>         strb    r0,[r1]
> 
>        .endm
> 
> In cases where it fails it never gets to the code in RAM.
> 
> I added a check in between the copy and the jump.
> 
> //lets do a compare of copied data!
>         ldr     r0,=__rom_vectors_lma
>         ldr     r1,=__rom_vectors_vma
>         ldr     r2,=__ram_data_end
> 25:     ldr     r3,[r0],#4
>         ldr     r4,[r1],#4
>         cmp     r3,r4
>         beq     26f
>         //If we get here our copy was corrupted!  Turn on LEDs to warn!!!
>         ldr     r3,=0x80840040
>         ldr     r4,=0x0
>         str     r4,[r3]
> 26:     cmp     r1,r2
>         bne     25b
> 
> When the board crashes booting up, the LEDs I turn on in this code are 
> on signaling that the copy failed.
> 
> I suspect there is possibly an issue initializing the SDRAM on a warm 
> boot.  I don't suspect it's an issue with NOR flash for two reasons.  
> First, I have checked the setup for NOR Flash and it is running with the 
> most conservative timings possible.  Secondly, code is executing out of 
> NOR flash prior to the jump to RAM.
> 
> I'm currently going through the SDRAM initialization code to see if I 
> can find a problem, but so far I haven't.  Though I'm not through all of 
> it with a fine tooth comb yet.
> 
> I can work around the problem by using an external watchdog to reboot 
> the system if the jump isn't successful.  However I don't like that as a 
> permanent solution because it's coving up an underlying issue with SDRAM 
> as far as I can tell.
> 
> Does anyone have any ideas, solutions, or recommendations?  Any help at 
> all would be greatly appreciated.
> 
> Andrew McKay
> Iders Inc.
> 


-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine