This is the mail archive of the ecos-discuss@sourceware.org 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: 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


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