Code only runs after flash as

[gerrykurz]

Ross, do you mean have I tried booting without the xtag plugged in? If so, yes.

I am not sure how this is relevant, perhaps you could explain more.

Segher,

How are you able to tell this from the dump state? It seemed to me that it was hanging in ram in my application. You are saying that it is hanging in the second stage bootloader trying to output to a channel? How are you able to determine this?

Why are the channels not working? What should I be looking for to solve this?

I am feeling frustrated that there is not sufficient documentation for me to understand this on my own and I have to depend on "xmos experts" who seem to have information that is not available to other engineers trying to use these chips.

Why is the bootloader source code not available?

Do I have to purchase the enterprise version of the tools to get this information?

I considered this but when Dave Bennett the Director of North American Sales did not give me an answer as to the level of support I could expect for a $5K expenditure, I decided not to go ahead.

So what is the deal here, if I spend $5K do I get all the support I need?

Having expressed this frustration, I am also extremely grateful for all the help I have received on this forum.

[segher]

The dump tells you the state of all processors
in the system. From the pc ("process counter")
you see most are in rom, all at the same spot;
from the code there (helpfully dumped) you
see it is doing the first "in" instruction, which
is immediately followed by a "setd". It seems
to be always here when you dump the state,
so the input is blocked (i.e., there is nothing
on that channel).

The "missing documentation" is called
"experience" I'm afraid.

Have you verified that all power is stable,
clocks are stable, and reset signals have no
glitches, and all that is sequenced correctly?

I don't know why the runtime / bootloader /
etc. code are not open source. Lack of time
maybe, or there is a feeling there is something
to hide. You can look at the binaries though.

[gerrykurz]

OK I see what you are saying segher, that in fact thread 1 is actually in the boot loader and the symbolic references from the xe files are actually a bit of red herring as the binary code at 0x10730 is the same in all cases even though dump state uses a different symbolic reference depending on the build of the xe file.

What also confused me was the statement from the debug boot thread

If the PC is in RAM (0x10000 - 0x20000) then you are in your application.

It sure would make debugging this a lot easier if the source code for the boot loader could be made available. I may be able to understand why it is not open source but surely it could be provided in cases like this to help resolve the issue in a more timely fashion.

I would be happy to sign an NDA to get this.......

One question that comes to mind is why is tile 1 stuck as it uses an internal link which presumably should be fine.....

So it seems my only recourse is to use modified xn files in a trial and error basis possibly in conjunction with the "hidden" features of xflash until I get it working....

Hey colin how did you find out about these?

[colin]

If your binary is compiled with a multi-node XN file then the second stage bootloader will always setup the defined network. It doesn't matter that no application code will target the slave node. You will need to recompile your binary with a modified XN if you want to test boot on a single node.

Xflash issues an xgdb command to reset the device after programming (xgdb --batch-silent --ex "connect" --ex "reset mode-pins nointerrupt" --ex "q"). You can see this if you add the --verbose option to xflash when programming your device. If you issue this xgdb command and the device boots successfully each time then it sounds to me like this issue with your boot failure is in the power sequencing of the devices.

[Ross]

Ross, do you mean have I tried booting without the xtag plugged in? If so, yes.

I am not sure how this is relevant, perhaps you could explain more.

I've seen some (bad) reset circuits broken by the presence of an xtag, that all ;)

[gerrykurz]

How do I get the hidden xflash command set and the xgdb command set?

Running these with the --help option does not give the information that is contained in these replies.

Due to this, I am having some trouble understanding your reply colin

Are you saying the after xflash runs, the application is run via xgdb (loaded via jtag) or that the device is reset and then boots out of the just programmed flash?

If the latter which seems to work, then I am not sure what is wrong with my power sequencing as I have examined it and it meets the specification published.

The only difference in my design from the slice kit boards is that my RST and TRST are connected as in the AVB Endpoint reference design. Since these boards work fine and boot from flash, I am assuming that my design should as well.

[segher]

How do I get the hidden xflash command set and the xgdb command set?

If the tool help or the manuals won't help you, help yourself!

"strings $(which xflash) | grep -- --" or similar.

For GDB, "help reset" at the command prompt (and "help help"
and "help info" and _read the manual_!)

Are you saying the after xflash runs, the application is run via xgdb (loaded via jtag) or that the device is reset and then boots out of the just programmed flash?

The device boots from flash. xgdb is just used to do the
reset.

If the latter which seems to work, then I am not sure what is wrong with my power sequencing as I have examined it and it meets the specification published.

Well, show us. You say it is all okay, but all evidence points
the other way.

We'll need to see the schematics for power, reset, mode pins,
and ideally also scope traces for the relevant signals (power
good, etc.)

[gerrykurz]

There is something extremely weird going on here....after xflash, it boots up fine however, if I try an emulate the xflash/xdgb reset sequence, it doesn't boot.???!!!

Anyway here is the requested data:

Schematic

Power Up Sequence

1V Ramp up

1V to Reset Delay

Reset Sequence

When xflash runs, just prior to prgramming the flash device, it executes an xrun command which does this reset sequence:

xrun reset sequence

After the flash is programmed, xgdb runs and two reset sequences occur:

1st xgdb reset sequence

2nd xgdb reset sequence

I have tried emulating these reset sequences but to no avail....so now the question is....

If sometime after power up, xgdb can issue a hardware reset and have the device boot from flash, why cannot I do the same thing from my arm micro?

[segher]

Oh, it is *that* board again, with the funny pullups.

I'll have to think about it a bit.

[segher]

So your RST has a much longer rise time than your TRST,
and it's not clear what value TRST (ergo the MODE pins) is
at when RST trips. It seems you release the signals in the
wrong order as well, but it's late, I dunno.

None of this explains the weird state the code gets in, or at
least I don't see it. But you could try putting the same value
resistor on RST as well, see if that helps anything...