[Openec] Ladies and Gents, we have a "blinking brick"!

[Frieder Ferlemann]

Hi Richard,

Richard A. Smith schrieb:
> Frieder Ferlemann wrote:
> 
>>
>> Strangely this does not result in the PowerLED toggling at the same
>> intervalls (screenshot appended).
> 
> I bumped up the unapproved size limit for the list to 200k.

Thanks - the screenshots will only be slightly better (the floppy on
the oscilloscope is not functioning so I'm shooting by hand).

>> The long high intervall there repeats about once every 5 seconds
>> (probably a reset issue). Yet the shorter intervals are not equidistant
>> either.
> 
> Odd.  One possibility is that access to the SPI flash is arbitrated
> between both the LPC bus and the 8051.  The in a 3700 CPU gets priority.
> (3700B fixes that).  We have had cases were the CPU can starve the 8051
>  of ROM access cycles and cause watchdog time outs and other timing
> issues.  So if the CPU is somehow resetting or (running a big noop loop)
> and every 5 seconds and tying to access the FLASH ROM then it might be
> causing this.
> 
> Use another channel on your scope and see if the LPC LFRAME signal is
> getting asserted a lot during the long pulse.

I have not yet tried to power up the XO so LFRAME is statically
low (measured).

To check whether the PLL is stable I used a short endless loop
which toggles the power LED.
This is the assembly listing (cut and paste from main.rst)


                           1025 ;       main.c:231: while(1)
   032B                    1026 00108$:
                           1027 ;       main.c:233: LED_PWR_ON;
                           1028 ;       main.c:234: LED_PWR_OFF;
   032B 90 FC 21           1029         mov     dptr,#_GPIOD08
   032E E0                 1030         movx    a, at dptr
   032F 44 02              1031         orl     a,#0x02
   0331 F0                 1032         movx    @dptr,a
   0332 E0                 1033         movx    a, at dptr
   0333 FA                 1034         mov     r2,a
   0334 54 FD              1035         anl     a,#0xFD
   0336 F0                 1036         movx    @dptr,a
                           1037 ;       main.c:266: debug_uart_ping();
   0337 80 F2              1038         sjmp    00108$

and a screenshot measured at the driving transistor.
PLL seems to be stable. And there seems to be no problem
about every 5 seconds either. Unfortunately I probably
won't find much time to check whether its IRQ/Timer/whatever
related until about Sunday. (Maybe switching on the Test Mode
for the timer was not wise - just toggling without the IRQ
looks fine now).


>> Another flash related topic: during my updating the OLPC I have
>> lost the content of the uppermost 1 kByte of the flash.
>> I backed it up first (at least I thought so) with OFW
>> to an USB stick (IIRC with read-flash u:\flash.bin)
>> but when I tried to reinstall that image it turned out
>> to be only 1047552 bytes (instead of 1048576 bytes) long.
>> Is this known/intended?
> 
> Hmmm... I can't really say that I've used read-flash.  Perhaps it did
> not save the manufacturing info because the write procedure reads that
> from the laptop and merges it into the image you are about to write.

Before resorting to read-flash I had tried to use ./forth spiflash.dic
to read the flash but it would not let me:

ok read-flash myfile.rom
spi! <--deferred word not initialized

So I gave OFW a go and tried my luck there. Unfortunately I had only
a short glance at the file length and as it was above 1E6 bytes it
looked OK to me.

Greetings,

Frieder

-------------- next part --------------
A non-text attachment was scrubbed...
Name: short_loop.jpg
Type: image/jpeg
Size: 41804 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/openec/attachments/20070823/e0c31b20/attachment-0001.jpg