This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RE: 28Fxxx Flash query problem
- From: "Steven Clugston" <steven dot clugston at newcastle dot ac dot uk>
- To: <ecos-discuss at ecos dot sourceware dot org>
- Date: Tue, 24 Jun 2008 16:58:01 +0100
- Subject: RE: [ECOS] 28Fxxx Flash query problem
>-----Original Message-----
>From: ecos-discuss-owner@ecos.sourceware.org
>[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of
>Andrew Lunn
>Sent: 24 June 2008 15:14
>To: Steven Clugston
>Cc: ecos-discuss@ecos.sourceware.org
>Subject: Re: [ECOS] 28Fxxx Flash query problem
>>...the first two C lines seems to be missing in the debugger.
>They are there, just mixed in. 0041AFA4 & 0041AFAC
The code at 0041AFA4 is where ROM address fetched.
The macro CYGHWR_FLASH_WRITE_ENABLE() I have defined to write to a
register on an external EPLD to enable the flash programming voltage.
I'm not sure what the exact interpreptation of CYGHWR_FLASH_WRITE_ENABLE
was supposed to be but the flash programming code doesn't work without
it, however I don't think you should need the programming voltage just
to read the chip's Ids, and as reads of these seem to work fine without
it. I still had the same problem before I defined the macro though.
0041AFAC is the loading of 'w'.
>Probably the debugger is having trouble mapping registers to
>variable. However r8 is used as w.
The debugger says ROM is r10, data is r3, and w is r8.
It can't find a symbol for id.
Also setting a breakpoint on 0041AFA0 don't work but 0041AFA4 does.
>> CYGHWR_FLASH_WRITE_ENABLE();
>> 0041AFA0: 3D600280 lis r11,640 <== r11 has 0x02800000 (external
address of EPLD base)
>> 0041AFA4: 3D40FFC0 lis r10,-64 <== r10 has 0xFFC00000 (flash
base address or ROM)
>> 0041AFA8: 616B100C ori r11,r11,0x100c <== bump r11 to
0x0280100C (Flash Vpp register in EPLD)
>> 0041AFAC: A10A0000 lhz r8,0(r10) <== r8 or 'w' get value read
from r10 (still flash base)
>
>Here is the load ROM[0]
>
>> 0041AFB0: 800B0000 lwz r0,0(r11) <== load word and zero, r11 =
0x0280100C
>> 0041AFB4: 7C0006AC eieio <== Enforce In-Order Execution
of I/O
>> 0041AFB8: 60000004 ori r0,r0,0x0004 <== toggle the Vpp bit in
EPLD reg
>> 0041AFBC: 900B0000 stw r0,0(r11) <== write it back out to
0x0280100C
>> 0041AFC0: 7C0006AC eieio
>>
>> ROM[0] = FLASH_Read_ID;
>> 0041AFC4: 38000090 li r0,144 <== load 0x90 (Flash query
code)
>> 0041AFC8: B00A0000 sth r0,0(r10)<== store 0xFFC00000 into r10
(was already there)
>>
>> // Manufacturers' code
>> id[0] = ROM[0];
>> 0041AFCC: A12A0000 lhz r9,0(r10)<== read Manufacture's code
0x0089 into r9
>> 0041AFD0: B1230000 sth r9,0(r3) <== store r9 into r3 (data
struct arg)
>> // Part number
>> id[1] = ROM[1];
>> 0041AFD4: A00A0002 lhz r0,2(r10) <== load contents at
0xFFC00002 (chip code 0x88C4) into r0
>>
>> ROM[0] = FLASH_Reset;
>> 0041AFD8: 392000FF li r9,255 <== load 0xFF into r9 (flash
reset code)
>> 0041AFDC: B0030002 sth r0,2(r3)<== store chip code in r3 (data
struct arg)
>> 0041AFE0: B12A0000 sth r9,0(r10)<== write reset code to flash
base
>>
>> CYGHWR_FLASH_WRITE_DISABLE();
>> 0041AFE4: 800B0000 lwz r0,0(r11) <== load r0 with contents at
0x0280100C
>> 0041AFE8: 7C0006AC eieio
>> 0041AFEC: 540007B8 rlwinm r0,r0,0,30,28 <== Toggle the Vpp bit off
>> 0041AFF0: 900B0000 stw r0,0(r11) <== write it back out again
>> 0041AFF4: 7C0006AC eieio
>>
>> // Stall, waiting for flash to return to read mode.
>> while (w != ROM[0]);
>> 0041AFF8: A00A0000 lhz r0,0(r10) <== read from flash base to r0
(0x0000FFFF)
>> 0041AFFC: 7C004000 cmpw r0,r8 <== compare with saved value in C
variable 'w'
>> 0041B000: 4D820020 beqlr
>> 0041B004: 4BFFFFF4 b flash_query+0x58 (0x41aff8)
>
>And here is the loop waiting for it to return back to the old value.
>
>The basic assembly language looks O.K, but im no expert with
>this CPU architecture. I would still suspect there is not a
>caching problem....
>
> Andrew
I agree that the assembly looks ok, although the order is a bit mixed up
from the C code, but still correct.
I've single stepped the assembly now that I know what each statement
does.
Always the first time through w gets loaded with the manufacuter's code
0x00B0.
If I reset the program counter to run through it again it then works.
It is as if something has already inadvertently written 0x90 to the
flash before it gets to flash_query(). I can't imagine what or where
though, suppose I'll have to do more single stepping from reset to find
out.
Thanks Andrew and Gary.
Steven
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss