RE: [ECOS] 28Fxxx Flash query problem

["Steven Clugston" <steven dot clugston at newcastle dot ac dot uk>]

>-----Original Message-----
>From: ecos-discuss-owner@ecos.sourceware.org 
>[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of 
>Andrew Lunn
>Sent: 23 June 2008 16:54
>To: Steven Clugston
>Cc: ecos-discuss@ecos.sourceware.org
>Subject: Re: [ECOS] 28Fxxx Flash query problem
>
>
>On Mon, Jun 23, 2008 at 04:22:57PM +0100, Steven Clugston wrote:
>> I'm trying to add flash support to a board that has a single 
>> 28F320C3-T part. I've included the Intel flash_28fxxx and generic 
>> flask packages and provided a platform flash package as well.
>> 
>> To test this I've created a Redboot RAM Elf image built from 
>cvs which 
>> I upload and start from an older Redboot image installed a couple of 
>> years ago on separate internal flash.
>> 
>> The problem is that when I run the image, it hangs in 
>> flash_28fxxx_parts.inl flash_query function:
>> 
>> void
>> flash_query(void* data)
>> {
>>     volatile flash_data_t *ROM;
>>     flash_data_t* id = (flash_data_t*) data;
>>     flash_data_t w;
>> 
>>     ROM = (volatile flash_data_t*) CYGNUM_FLASH_BASE;
>> 
>>     w = ROM[0];
>> 
>>     CYGHWR_FLASH_WRITE_ENABLE();
>>     
>>     ROM[0] = FLASH_Read_ID;
>> 
>>     // Manufacturers' code
>>     id[0] = ROM[0];
>>     // Part number
>>     id[1] = ROM[1];
>> 
>>     ROM[0] = FLASH_Reset;
>> 
>>     CYGHWR_FLASH_WRITE_DISABLE();
>>     
>>     // Stall, waiting for flash to return to read mode.
>>     while (w != ROM[0]);
>> }
>> 
>> Using a hardware debugger to interrupt execution is it 
>always stuck in 
>> the while loop at the end of this function. If I force the program 
>> counter back to the start of the function and step though it works 
>> fine, the flash chip returns the correct manufacturer and parts id's 
>> and I get all the Redboot 'fconfig' commands.
>> 
>> Strangely, (perhaps because the code has been inlined?) if I set a 
>> breakpoint to catch it before it goes through they don't 
>> seem to work 
>> and it still drops through to the while loop, and the debugger gives 
>> register locations instead of memory addresses for variable 
>> locations.
>> 
>> Does anybody have any ideas how to tackle this?


>Do you have an MMU? Have you configured the address space to 
>be none caching, write through etc.
>
>         Andrew

Thanks (again) Andrew.

Its an MPC555, so it doesn't have an MMU or data/instruction cache to
worry about.
As far as I understand there's just two USIU memory controller registers
to set, BR0 and OR0 for chip select CS0 which the flash is on.
I've set these to the same as the manufacturer uses with U-Boot and I've
check that the values make sense, burst inhibit, 16-bit port etc.

I've just tried stepping through the code again and for some reason it
seems to execute non-sequentially, it jumps around in the flash_query()
function which causes the variable 'w' to get read after Read_ID has
been written to the flash so the while() loop always hangs as 'w' has
the manufacturer's code instead of the original flash value in it.

I've checked that the HAL_DCACHE macros are empty for this platform and
as far as I know I've not got any compiler optimisation turned on so I
am foxed as to why this is happening.

Any ideas?

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