Code only runs after flash as

[gerrykurz]

What I don't get is that xrun and xgdb seem to switch trst at different times than rst and everything seems to work fine.

So what is the relationship between rst and trst and as well between rst and the mode pins?

Are the mode pins sampled in hardware at the rising edge of rst? Or are they sampled in firmware by the boot rom a short time after rst?

The reason I put the strong pullup on trst is that it's rise time orginally was worse than rst so I thought that rst was missing the mode setting (although in all cases the processor accesses flash so that doesn't make sense.

I tried holding trst low out of power up (booting via jtag) and then setting trst high and then cycling rst (as xgdb does).

Is the timing between resetting the core and resetting the jtag really that critical at power up and if so why?

Somehow xrun or xgdb manage to get the processor out of the power up state and get it to boot normally.

What I am going to do now is run xflash which will get the code to boot from flash then
issue a hardware reset to see what happens ( i will try both with and without the xtag connected)

[gerrykurz]

So out of power up my device does not boot from flash

I program the flash with xflash and at the end of the programming cycle, xgdb via xtag does a hardware reset and the device boots up

Subsequently without power cycling, I do a hardware reset and the device does not boot up.

Someone explain that please.....

[gerrykurz]

so the difference between xflash/xgdb reset and simple hardware reset is that xgdb issues two resets after programming the flash, the first with TRST low (booting into JTAG) and the second with TRST high (booting from flash)

xgdb reset after flash programming

Why does it do this?

It seems like something is happening here because doing a simple hardware reset with TRST high does not boot successfully.....

[infiniteimprobability]

Hi, looking at your schematic, we noticed a possible cause of this issue. TRSTn and RSTn are not asserted at the same time during power on reset. From the design checklist:

H.3 Power on reset
The RST_N and TRST_Npins are asserted (low) during or after power up. The device is not used until these resets have taken place.

Try tying these together - (I see you are using open drain drivers so this should be OK).

[gerrykurz]

OK but my design is based on the AVB endpoint design and these pins are not tied together in that design.

If this is so important, why does the AVB endpoint design work?

And why does it boot, when xgdb asserts TRST before RST?

[segher]

If you do this, make sure you tie RST and TRST together
_only on the chip side_. You do not want to do a system
reset whenever you pull TRST ;-)

So your RST signal then goes to both the RST and the TRST
pins, and the TRST signal goes to the MODE pins only. This
is a well-tested design and I recommend it.

And yes, the MODE pins are sampled at the rising edge of
RST. So you need to make sure they stay stable until reset
is done.

[gerrykurz]

Ok I have modified my circuit so that RST and TRST are identical.

New RST & TRST

Unfortunately, I based my hardware design on the AVB Endpoint reference design so there is no way I can separate TRST from the MODE pins on this board.

However, here is what I have done:

New Schematic

Unfortunately, the device still does not boot out of power up but now I can get it to boot successfully by doing one or more (up to 5 or 6) resets after the initial power up reset. Interestingly, a long reset pulse never works and only ones on the order of 100ms work. Also doing a long reset pulse seems to get into a mode where it takes more short pulses to get it to boot.

There is definitely still a problem but at least now my ARM supervisor can reboot the XMOS chips until they start up so I can finally move forward.

I am thinking that this is worthy of a bug report now as I am doing everything that is recommended for power up and it does not seem to be the xn file as it does boot successfully with the two chip xn file.

Still a lot of unanswered questions for me though.......

[infiniteimprobability]

OK, that's some progress. I'm glad the solution is close. Having to assert up to 5 or 6 resets is absolutely a work around though - clearly not a solution for production. At this stage I'm not sure why it takes so many - it would require further debugging on your board to do that.

If the AVB ref design has bugs - that must be addressed. However, I looked at the XK-AVB-LC-SYS schematic and both TRSTn and RSTn get asserted by the supervisor at power on (see below attachment)..although both can be asserted independently by the debug adapter. Use of TRST (ie asserted at reset) is mentioned twice in the datasheet.

So what is the relationship between rst and trst and as well between rst and the mode pins?

At power up, both trst and rst must be asserted. There is additional state in the chip that needs to be reset by TRST, over and above the RST line. Hence the documentation related to this in the datasheet, and ref designs assert TRST at power on.

Are the mode pins sampled in hardware at the rising edge of rst? Or are they sampled in firmware by the boot rom a short time after rst?

Rising edge of reset

If this is so important, why does the AVB endpoint design work?

Because TRST is asserted by POR

And why does it boot, when xgdb asserts TRST before RST?

TRST gets asserted. Looks like it can be before RST, but still needs to happen on power up.

[segher]

You still don't hold the MODE pins at the
proper value while reset is in progress.

[infiniteimprobability]

You still don't hold the MODE pins at the
proper value while reset is in progress.

Good catch - that would do it! A quick xrun --dump-state would hopefully have revealed that (Ie. CPU waiting from something other than SPI/link as Mode2/3 are not at correct levels when sampled)

Let us know how you get on - hopefully this solves it once and for all!