Re: [Ltib] Curious phytec LPC3250 S1L problem

[Craig Day]

Hi Travis,

This problem is most likely due to not handling GPI_3 correctly in your system. See the following post: http://www.phytec.com/kb/index.php?article=303

Hope this helps.

cheers,
Craig
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Travis Imken <address@hidden> wrote:

Hello there,

I realize that this email is a little out of place on the LTIB mail list, but I am hoping someone may have the knowledge to help me; otherwise, I am sorry to bother you with this email (and feel free to point me in a different direction). 

I am a student working with a Phytec LPC3250 board for a school project. I am running into an issue with the S1L as I try to migrate our SOM from the development board to a custom interface board.

Every time we power the LPC3250 on our interface board, the S1L seems to remember no settings (prompt name, image location, etc.) Below is the message we get:

Using default system configuration

Phytec LPC3250 board
Build date: Dec  4 2008 09:45:09
PHY3250>info
Prompt bootup timeout (secs) = 50000
FLASH device : detected
 Number of FLASH blocks   : 4096
 FLASH pages per block    : 32
 FLASH bytes per page     : 512
 Total FLASH size (Mbytes): 64
Stage 1 loader number of blocks used: 25
File loaded in memory: None
No image stored in FLASH
Autoboot source                  : Disabled
SDRAM type/size: Low power SDRAM 64MB
MMU : Enabled
ARM system clock (Hz) = 208000000
HCLK (Hz)             = 104000000
Peripheral clock (Hz) = 13000000
Ethernet MAC address: 50:ed:f4:01:fd:ec
NAND FLASH vendor    : 0x20
NAND FLASH device ID : 0x36

From here, we are able to load u-boot from the SD card, mount it into the flash, and then boot from it (like setting up the SOM for the first time). U-Boot does use all of the boot variables stored in the flash from the SOM's time on the development board. It will then boot into Linux with no issues. However, if power is cycled, we again get the same message of "Using default system configuration" and nothing will happen; it remembers none of the settings. This includes something as basic as changing the prompt name.

The curiosity of the problem comes when we place the SOM back onto the Phytec development board. Upon powering the LPC3250 on the dev board, it boots complete fine; no settings have to be changed or altered. I get the feeling that I am missing something basic but we have stared at this problem for hours with no victory. Why can the S1L not find the information it needs to boot on our board but is completely fine on the development board? Where is this information located? What could cause it to not be found, be saved, and then be completely fine on the dev board?

I realize that without knowledge of our board it's hard for y'all to help trouble shoot this problem, but right now we are just fishing for leads to investigate.

For reference, here is the 'info' from the S1L for the same SOM when it is on the phytec dev board:

Phytec LPC3250 board
Build date: Dec  4 2008 09:45:09
Autoboot in progress, press any key to stop..
phy3250-linux>info
Prompt bootup timeout (secs) = 2
FLASH device : detected
 Number of FLASH blocks   : 4096
 FLASH pages per block    : 32
 FLASH bytes per page     : 512
 Total FLASH size (Mbytes): 64
Stage 1 loader number of blocks used: 25
File loaded in memory: None
FLASH image first block used  : 25
FLASH image blocks used       : 10
FLASH image sectors used      : 298
FLASH image size in bytes     : 152220
FLASH image load address      : 0x83fc0000
FLASH image execution address : 0x83fc0000
Autoboot source                  : FLASH
Autoboot image type              : RAW
SDRAM type/size: Low power SDRAM 64MB
MMU : Enabled
ARM system clock (Hz) = 208000000
HCLK (Hz)             = 104000000
Peripheral clock (Hz) = 13000000
Ethernet MAC address: 50:ed:f4:01:fd:ec
NAND FLASH vendor    : 0x20
NAND FLASH device ID : 0x36
phy3250-linux>

I want to add a couple of points to highlight what we've been trying so far:

1) Having the watchdog enabled or disabled (via electrical connection) did not affect the problem. 

2) We have confirmed that the /SERVICE pin is connected to ground as it is on the Development board. We have also tried removing a 0-ohm resistor from this line on our board to pull it high as well, but it made no difference. We came across this idea from a paragraph in chapter 8.1 of the LPC3250 hardware manual.

Thanks for your time. 
Travis