Booting from external SPI Memory, LPC3250

 Booting from external SPI Memory, LPC3250

Hi,

I am using Phytec LPC3250 board with uVision IDE.

I want my code to boot from an external SPI EEPROM that we connected via the extension board. (Removing J16 jumper) I can successfuly write and read the EEPROM. However, the boot does not occur.

When I used the EEPROM available on the PHYTEC board, there was no problem, the boot successfuly happened. I don't know why the same code in another EEPROM wouldnt work.

Can the problem be that the bootstrap code in the internal ROM can only boot with the EEPROM on the phytec board? The user manual says, any bootable SPI memory connected to SSP0 starts the boot procedure.

May that be possible? How can the bootstrap read the data from "any" SPI flash without knowing the opcodes, etc?

Thanks in advance.

 RE: Booting from external SPI Memory, LPC3250

Refer to the NXP LPC32x0 user manual.

It has a whole chapter (#35) describing the boot process.

There is nothing in the on-chip bootstrap code specific to (or that relies upon) the Phytec board.

 RE: Booting from external SPI Memory, LPC3250

Yes, I carefully read the chapter. It says no dependence on any chip.

However, I wrote my code to the flash correctly, but it doesn't boot.

Page0: First 528 bytes of the code
Page1: Next 500 byte of the code.
Page2:
- :
- :
- :
Pagen:

I correctly write the boot data format and the data length. Because I can rad them.

So why doesn't it boot? Can anyone please propose something?

 RE: I wrote my code to the flash correctly, but it doesn't boot

The fact that the bytes were correctly written into the flash does not guarantee that those bytes represent a valid, bug-free program!

 RE: I wrote my code to the flash correctly, but it doesn't boot

But,

The same code that I had written to the flash on the Phytec Board boots. So, I understand that the code is valid, bug-free.

What else can be the problem?

Thanks.

 What else can be the problem?

The details you've provided are pretty scant. You didn't mention what SPI flash your using and whether it is the same as the one on the Phytec board.

The obvious thing to do is look for the differences that might exist.

 RE: What else can be the problem?

The Flash I am using now is AT45DB321D.

The Flash on the Phytec board is AT25256A.

NXP says, boot happens when the read opcode is "0x03" and there are 2 or 3 address bytes. My new flash can also be read with "0x03" and has 3 address bytes.

I don't figure out the problem.

Thanks.

 RE: I understand that the code is valid, bug-free.

That isn't necessarily true - there could be some latent bug(s) that you just happened to get away with before...

 RE: I correctly write the boot data format and the data length. Because I can rad (sic) them

I presume you mean, "read" ?

If your read routines contain a bug that's complimentary to your write routines, that could make it appear to read correctly - but be wrong for execution.

eg, byte ordering...?

 SPI1_DATIN pin

Hi,

I found something in the user manual.

It says that the SPI1_DATIN pin should be cleared in order to tell the processor that an external SPI Flash (having 3 address bytes) is being used rather than the predefined one (having 2 address bytes).
It makes sense because the same code on the SPI EEPROM on Phytec board boots but an external one does not. Apparently the SPI1_DATIN pin is made HIGH!!!

So, how am I going to clear this pin? It is already connected to the SPI Flash. Shouldn't there be a jumper for this on the board? If so, how can I find the jumper?

Thanks for your helps.

 RE: SPShouldn't there be a jumper for this on the board?

That really is a question for the board manufacturer - it has nothing to do with Keil!

"how can I find the jumper?"

Ask Phytec - it's their board!

 RE: SPShouldn't there be a jumper for this on the board?

That was not the main question of my text.
The question is, should there be a jumper?

The SPI1_DATIN pin, which is the input pin for the SSP/SPI communication, is already connected to the SPI Flash (to the output pin of the flash). If I keep the pin low, how can the processor read the data out of the flash?

Therefore, maybe the jumper is not the way to clear that bit.

I hope I could tell my problem.

Thank you.

 RE: SPShouldn't there be a jumper for this on the board?

Don't you think that it is a question to the company who wrote the boot loader? If they have specified a specific behaviour for a specific signal, they must also have some view on how to get that signal to that pin.

For example - if the pin should be low forever, or if the board should have logic that holds the pin low for x microseconds after reset, or if they just expect the memory chip to hold the signal low until they sends the first command to the memory chip.

It is not a Keil problem, but if you do get an answer it may be a number of readers on this forum who would be interested in the answer.

 RE: SPShouldn't there be a jumper for this on the board?

As I stated at the start:

Refer to the NXP LPC32x0 user manual.

It has a whole chapter (#35) describing the boot process.

There is nothing there that describes any part of the inbuilt bootstrap code that is specific to the Phytec board.

 RE: SPShouldn't there be a jumper for this on the board?

To IB Shy:

I read that chapter many times. I know it has nothing to do with the Phytec board but, as I can succeed something on that board, and cannot succeed somewhere else it will be wise to see the difference between the new environment and the Phytec board.

And finally, considering this, I saw that the EEPROM on the Phytec board has a different communication procedure than the Flash I am working on now.

To Do Per Westermark:

It is a good way to ask the company writing the bootloader but they generally reply too late, therefore I prefer writing and discussing here.

Asking a hardware guy, I learnt that connecting a small resistance between the SPI1_DATIN pin and the flash, the problem can be solved. Without communication, it will feel low, and when the communication starts that small resistance won't affect the communication.

Tomorrow I'll try that and write you the result out of that.

Thanks for your helps.

 RE: SPShouldn't there be a jumper for this on the board?

I finally handled the problem.

Connecting a small resistance to the SPI1_DATIN pin the boot from the external SPI flash works out!!

Thanks a lot for your helps.