Code only runs after flash as

[gerrykurz]

I have some code that will only run if I do a Flash As from xTime Composer.

The code is apparently written to flash and then it runs.

However, if I power cycle the hardware, it doesn't run.

From xTime Composer, if I do a Run As, if doesn't work.

And if I do a Debug As, the program suspends with the following message:

.gdbinit: No such file or directory.
auto-solib-add on
Undefined command: "auto-solib-add". Try "help".
attach --adapter-id _J2U6OBg
0xffffc070 in ?? ()

[segher]

You can probably ignore the GDB warnings and errors here.

0070 in the ROM is where it halts if boot mode is "no boot"
(also known as "JTAG boot"). But you wanted it to boot
from SPI flash. Check the MODE pins?

[larry]

Does Debug As switch the IDE into Debug perspective? What is the failure mode, does the IDE continue to run? Is the application clearly not running?

Can you see a similar issue with another application? What about a simple hello world?

Flash programming is normally followed by a board reset, which would be identical to an subsequent manual reset. Not sure why the application would run in one case and not the other.

[gerrykurz]

Hi,

I upgraded to community version 13.2.1, created a new workspace and now I can flash, run and debug just fine.

However, my hardware does not boot reliably from flash. It never boot correctly out of a power up, and I need to reset the chip to get it to boot (and even this is intermittent, sometimes needing several successive resets to boot up)

The chip always boots in flash mode and starts accessing the flash chip every time (except out of power up) but the chip select waveform is different when it boots successfully from when it doesn't.





Anybody seen this kind of behavior before?

[segher]

Those "extra chip selects" are probably when the port is
tristated, which happens when it is reset. You see it at
the start of the sequence as well.

Your board seems to be quite noisy (or the measurement is).

When it doesn't boot it still reads the full boot image from
flash. Use the debugger to see where it stopped -- my best
bet is it found the checksum is wrong. But it could be
anything :-)

[gerrykurz]

The result is very consistent from when it boots to when it doesn't boot. When it boots, there are always the extra chip selects and when it doesn't boot, they are not there.

Why would it get the checksum right sometimes and not others?

So to use the debugger, I would attach the debugger to the running process after booting from flash, is that correct? Because when I load the code from the debugger it works.

I am not quite sure how to do this....

Yes I noticed the noise as well, I think it related to the scope probes but I will look into it further.

[segher]

The result is very consistent from when it boots to when it doesn't boot. When it boots, there are always the extra chip selects and when it doesn't boot, they are not there.

Yes; it looks like it simply stops running code after reading
everything from SPI.

Why would it get the checksum right sometimes and not others?

Because it didn't receive the correct data.

So to use the debugger, I would attach the debugger to the running process after booting from flash, is that correct?

That is correct. The manual will tell you how to (I hope),
I've never used the IDE so I can't tell you. But it is a very
common thing to do ;-)

[mon2]

Is the power supply clean and well filtered ?

Proper power sequencing of the power supplies ?

How far is this SPI flash in the PCB layout from the CPU ?

How many layers is this PCB ?

Which brand and P/N of the SPI flash is being used on this board ?

Can you post the SPI flash schematic portion of your design ?

May be a stretch but we did observe a difference in the pin strength drive ability between Winbond (was weaker) and Spansion (was better) during our exhaustive review of the QUAD SPI modes and XMOS IP. We had some long wires to our DUT and also to our multiple logic / bus analyzers which could not be avoided and believe to be the root cause of our problems but Spansion kept on trucking in all conducted tests. When reported to Winbond that Spansion worked where they failed, they presented us with another generation of their SPI flash devices which should be public and available now through distributors like Digikey - the new SPI flash devices from Winbond feature a pin strength register which was missing from the tested components. However, it is important to note that the XMOS boot rom code is NOT using QUAD SPI mode but rather the most common across vendors and standard SPI mode. We did not observe any issues in standard SPI mode between Winbond and Spansion.

Summary - Recommend that if you are using the Winbond brand, consider to bring in the Spansion version of the same just for a quick test. Just the same, can you remove the non-working SPI flash from your board and transplant onto the XMOS original slicekit for similar testing ? Does the XMOS original slicekit boot every time with your same SPI flash device ?

Will be nice to apply a SPI bus analyzer, if available, into your DUT to view the results.

[gerrykurz]

Hi,

I am back to this problem again after working on a bunch of other stuff.

So can someone from XMOS please respond to this, it is a serious problem.

Why can the flash chip be programmed from xTime Composer over and over again without any errors and yet when it tries to boot, something goes wrong.

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

Can I get the source code for the boot rom so I can run it in the debugger to see where it is failing?

How can I debug the boot from flash process?

I really need some help here......

[Hagrid]

Do you have external pullup resistors on the chip select line(s)? Add a 10kohm to each chip select and to the spi clock line if possible.