Code only runs after flash as

[gerrykurz]

Thanks for your response and .....

What will the pullups do?

This still does not answer the question as to why the flash chip can be programmed over and over seemingly without an error but seemingly cannot be read correctly at boot time.

[Ross]

Either the xTime Composer flash programming routine does not verify the programmed code correctly or the boot rom has some kind of error.

The xflash tool does verify the image. There are no known issues with the boot code and there are millions of devices in production out there booting from flash...

You shouldn't require any external pull ups.

The bootcode is waiting at boot mode JTAG (waiting for program to be loaded over JTAG)

Have you been through the design checklist?

[segher]

How can I debug the boot from flash process?

Running

Code: Select all

xrun --dump-state

after an unsuccessful boot might show some clues.

[gerrykurz]

Thank you Ross for replying.

I assumed that xflash verified the image as that is what it says it does when it runs.

Also I understand that the boot rom code obviously works in the vast majority of implementations.

Yes I have been through the design checklist.

The boot rom code in this case in not waiting for JTAG as I can see on an oscilloscope that the xmos chip is reading data from the flash chip.

So the question remains unanswered as to what is the difference between xflash and the boot rom code that could cause the xflash program to work without failure and the boot rom code to fail.

Since the source code for either of these programs is not published, I am without resources to debug this on my own.

And thank you segher for your reply, however without source code or some more information about the boot rom process, a dump state may provide some clues to you but would not provide any such thing to me.....

The only thing that I can think of doing would be to run the boot rom code via the JTAG interface so I can see where it is failing.

Ross, can you provide me with the boot rom source code?

[infiniteimprobability]

Here's an FAQ with some further info on debugging the boot.

http://www.xcore.com/questions/3233/wha ... #node-3234

[segher]

Well. From what can be seen from the osc pics, I conclude
this happens, at unsuccessful boot:

- The system is reset. The rom code starts; it sees from
the mode pins that it should load an image from spi, and
boot that. It does that. That works.

We are now at that gap in activity on the spi lines, about
halfway.

- That loaded image sets up some things, and then loads
some more from spi. That works too.

Now we're at the end of spi activity.

- Then it seems to be active for a while longer.
- And then somehow it ends up in rom code?

The xrun command might give you some info where it
came from; the rom code to get here does not overwrite
many registers.

[gerrykurz]

Well the xrun command does not work as you have specified.

When I type xrun -- dumpstate or xrun --dump-state

I get the following error message

xrun: No .xe file passed to --dumpstate option

However from looking at the spi cs and clock signals on the scope, it seems clear that the first stage boot load is working correctly but then it goes off the rails on the second stage boot load

How do I create a custom or modified second stage boot loader?

I think what I would like to do is to slow down the spi clock speed to see if that works. Right now it bumps the clock up to around 3.5 MHz after the first stage boot load and then it seems to bump it up again to around 7 MHz. It also seems to get in loop where it is toggling the spi cs line at a rate of 3.5 KHz.

Any ideas about this?

Can I please get the source code for the second stage boot loader so I can try to understand what is happening?

[segher]

--dump-state-no-xe I think?

I don't think it is any stage of the loaders that is messing
up, but your application code. You'll need to debug some
more to find out for sure. Yes I realize this isn't so easy :-/

[segher]

Oh, and it seems like xflash --spi-div will let you control
the SPI frequency. Try --spi-div 50 or something like that
to make sure this isn't your problem.

[gerrykurz]

Hi segher,

It is hard to imagine that the application code is a problem when it runs fine when loaded with xrun or with xTimeComposer.....

The only problem seems to be reading from the flash device during boot up.....

xflash can program and verify the flash device just fine with never an error....

Thanks for the tip about xflash spi div, I will try that.....