L2 boot problems

[tek66tim]

Hi,

I'm having a problem booting an L2 device. I can boot the chip from a file loaded with the flash tools (and Xtag programmer) through the IDE v11.2.2, but when I use those tools (command line) to dump a hex file (image) and later use my software to upload the image to the flash over the L2's serial port, the L2 refuses to boot up.

I wrote my own windows program that my customers use to "field program" the devices. I've done this for designs with L1's and G2's but for some reason the L2 doesn't want to cooperate.

Before I get hammered for using old tools, let me say this is a hardware redesign from G2 to L2 the code was written with 11.2.2 tools and worked fine (with G2's), still works fine if I program from the IDE.

Any ideas would be welcome

Thanks,
Tim

[XMatt]

I would suggest getting the tools to dump out where the processor is once you have booted with your image. Using the .xe file you made the hex image from do the following.

xrun --dump-state program.xe

This should at least give you an idea where the program is. If you post the output from this then someone can take a look at where the application has got to in the boot process.

[tek66tim]

Hi Matt,

Here is the dumpstate text after I tried booting from my dumped image.

***** Active Threads *****
2 stdcore[1] hwthread 0 0xffffc0a6 in ?? ()
* 1 stdcore[0] hwthread 0 0xffffc300 in ?? ()


Thread 2 (stdcore[1] hwthread 0):
***** Call Stack *****
#0 0xffffc0a6 in ?? ()
***** Disassembly *****
0xffffc0a6: in (2r) r1, res[r0] *
0xffffc0a8: setd (r2r) res[r0], r1
0xffffc0aa: in (2r) r2, res[r0] *
0xffffc0ac: ldw (lru6) r4, dp[0x7]
0xffffc0b0: mkmsk (rus) r5, 0x20
***** Registers *****
r0 0x2 2
r1 0x0 0
r2 0x87 135
r3 0x10000 65536
r4 0x80063d8e -2147074674
r5 0x0 0
r6 0x0 0
r7 0x0 0
r8 0x0 0
r9 0x0 0
r10 0x3 3
r11 0x1 1
cp 0x0 0
dp 0xffffc344 -15548
sp 0x0 0
lr 0xffffc09c -16228
pc 0xffffc0a6 -16218
sr 0x40 64
spc 0x0 0
ssr 0x0 0
et 0x0 0
ed 0x0 0
kep 0x0 0
ksp 0x7 7
Thread 1 (stdcore[0] hwthread 0):
***** Call Stack *****
#0 0xffffc300 in ?? ()
***** Disassembly *****
0xffffc300: waiteu (0r) *
0xffffc302: stw (2rus) r0, r0[0x0]
0xffffc304: stw (2rus) r0, r0[0x0]
0xffffc306: stw (2rus) r0, r0[0x0]
0xffffc308: stw (2rus) r0, r0[0x0]
***** Registers *****
r0 0x10000 65536
r1 0x10100 65792
r2 0x10300 66304
r3 0x10200 66048
r4 0x20000 131072
r5 0xf009300 251695872
r6 0xffffffff -1
r7 0xc0 192
r8 0xedb88320 -306674912
r9 0x4e6be2ef 1315693295
r10 0x60 96
r11 0x0 0
cp 0x0 0
dp 0xffffc344 -15548
sp 0x0 0
lr 0xffffc222 -15838
pc 0xffffc300 -15616
sr 0x51 81
spc 0xffffc218 -15848
ssr 0x0 0
et 0x5 5
ed 0x20000 131072
kep 0x0 0
ksp 0x7 7
C:\Program Files\XMOS\DevelopmentTools\11.2.2>exit

Thanks,
Tim

[XMatt]

It does not look like the flash has been programmed correctly, you are getting an exception in the boot ROM when it is attempting to boot from flash. I would suggest checking that you can read back the flash via xflash and then check the image is as expected.

[tek66tim]

Hi Matt,

I was having trouble with --read-all usage but I got it through trial and error.

Thanks
Tim

[segher]

It is trying to boot an image of size 0x0f00d300 which is
really not going to work. Strange number, how did that
end up in flash!

[tek66tim]

Hi All,

Found my problem, it was an addressing issue in my write and read routines to and from the flash. I guess that's why it appeared to verify inside my windows app. I fixed it and it's booting fine.

Thanks for pointing out the use of the command line tools to help in debugging. I don't use them much and overlooked them.

Thanks,
Tim