We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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.
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.
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!
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.
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.
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.
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.
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.