XU232 QSPI & Xlink boot

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
LumiCore
Member++
Posts: 21
Joined: Fri Jul 01, 2016 6:36 am

Re: XU232 QSPI & Xlink boot

Postby LumiCore » Wed Aug 17, 2016 1:12 pm

Hi Henk,

After finally finding by trial on error what the correct syntax is to get xflash to accept the --erase-all command, I'm posting it here for future reference:

Code: Select all

xflash --erase-all --target-file xnfile.xn
Maybe it is described somewhere in a manual but I couldn't find it, nor conclude it from the --help command.

Now the result after erasing and resetting. I hope I did what you've asked me to do..

Code: Select all

xrun: Program received signal ET_LOAD_STORE, Memory access exception.
      0xfff005b8 in ?? ()

      ***** Active Cores *****
        4  tile[3] core[0]  0xfff00518 in ?? ()
        3  tile[2] core[0]  0xfff00518 in ?? ()
        2  tile[1] core[0]  0xfff00518 in ?? ()
      * 1  tile[0] core[0]  0xfff005b8 in ?? ()

      Thread 4 (tile[3] core[0]):

      ***** Call Stack *****
      #0  0xfff00518 in ?? ()
      #1  0xfff00342 in ?? ()
      Backtrace stopped: previous frame identical to this frame (corrupt stack?)


      ***** Disassembly *****
      0xfff00518:       in (2r)         r1, res[r6] *
      0xfff0051a:       setd (r2r)      res[r6], r1
      0xfff0051c:       in (2r)         r2, res[r6] *
      0xfff0051e:       ldw (ru6)       r4, dp[0x0]
      0xfff00520:       mkmsk (rus)     r5, 0x20

      ***** Registers *****
      r0             0x0        0
      r1             0x0        0
      r2             0x0        0
      r3             0x40000    262144
      r4             0x200100   2097408
      r5             0x100200   1049088
      r6             0x10002    65538
      r7             0x80a      2058
      r8             0x0        0
      r9             0x10023    65571
      r10            0x3        3
      r11            0x40b      1035
      cp             0x0        0
      dp             0xfff01eb0 -1040720
      sp             0x7ff7c    524156
      lr             0xfff00342 -1047742
      pc             0xfff00518 -1047272
      sr             0x40       64
      spc            0x0        0
      ssr            0x0        0
      et             0x0        0
      ed             0x0        0
      sed            0x0        0
      kep            0xfff00400 -1047552
      ksp            0xfff00518 -1047272

      Thread 3 (tile[2] core[0]):

      ***** Call Stack *****
      #0  0xfff00518 in ?? ()
      #1  0xfff00500 in ?? ()
      Backtrace stopped: previous frame identical to this frame (corrupt stack?)


      ***** Disassembly *****
      0xfff00518:       in (2r)         r1, res[r6] *
      0xfff0051a:       setd (r2r)      res[r6], r1
      0xfff0051c:       in (2r)         r2, res[r6] *
      0xfff0051e:       ldw (ru6)       r4, dp[0x0]
      0xfff00520:       mkmsk (rus)     r5, 0x20

      ***** Registers *****
      r0             0x1        1
      r1             0x0        0
      r2             0x0        0
      r3             0x40000    262144
      r4             0xfff01ee8 -1040664
      r5             0x100200   1049088
      r6             0x2        2
      r7             0x80a      2058
      r8             0x0        0
      r9             0x23       35
      r10            0x3        3
      r11            0x0        0
      cp             0x0        0
      dp             0xfff01eb0 -1040720
      sp             0x7ff7c    524156
      lr             0xfff00500 -1047296
      pc             0xfff00518 -1047272
      sr             0x40       64
      spc            0x0        0
      ssr            0x0        0
      et             0x0        0
      ed             0x0        0
      sed            0x0        0
      kep            0xfff00400 -1047552
      ksp            0xfff00518 -1047272

      Thread 2 (tile[1] core[0]):

      ***** Call Stack *****
      #0  0xfff00518 in ?? ()
      #1  0xfff00342 in ?? ()
      Backtrace stopped: previous frame identical to this frame (corrupt stack?)


      ***** Disassembly *****
      0xfff00518:       in (2r)         r1, res[r6] *
      0xfff0051a:       setd (r2r)      res[r6], r1
      0xfff0051c:       in (2r)         r2, res[r6] *
      0xfff0051e:       ldw (ru6)       r4, dp[0x0]
      0xfff00520:       mkmsk (rus)     r5, 0x20

      ***** Registers *****
      r0             0x0        0
      r1             0x0        0
      r2             0x0        0
      r3             0x40000    262144
      r4             0x200100   2097408
      r5             0x100200   1049088
      r6             0x10002    65538
      r7             0x80a      2058
      r8             0x0        0
      r9             0x10023    65571
      r10            0x3        3
      r11            0x40b      1035
      cp             0x0        0
      dp             0xfff01eb0 -1040720
      sp             0x7ff7c    524156
      lr             0xfff00342 -1047742
      pc             0xfff00518 -1047272
      sr             0x40       64
      spc            0x0        0
      ssr            0x0        0
      et             0x0        0
      ed             0x0        0
      sed            0x0        0
      kep            0xfff00400 -1047552
      ksp            0xfff00518 -1047272

      Thread 1 (tile[0] core[0]):

      ***** Call Stack *****
      #0  0xfff005b8 in ?? ()
      #1  0xfff00342 in ?? ()
      Backtrace stopped: previous frame identical to this frame (corrupt stack?)


      ***** Disassembly *****
      0xfff005b8:       stw (2rus)      r11, r4[0x0]
      0xfff005ba:       add (2rus)      r4, r4, 0x4
      0xfff005bc:       sub (2rus)      r5, r5, 0x1
      0xfff005be:       bt (ru6)        r5, -0x7
      0xfff005c0:       in (2r)         r11, res[r2] *

      ***** Registers *****
      r0             0x10100    65792
      r1             0x10000    65536
      r2             0x40100    262400
      r3             0x106      262
      r4             0x80000    524288
      r5             0xfffeffff -65537
      r6             0xedb88320 -306674912
      r7             0xe4caa974 -456480396
      r8             0x0        0
      r9             0x23       35
      r10            0x6        6
      r11            0xffffffff -1
      cp             0x0        0
      dp             0xfff01eb0 -1040720
      sp             0x7ff7c    524156
      lr             0xfff00342 -1047742
      pc             0xfff005b8 -1047112
      sr             0x51       81
      spc            0xfff005b8 -1047112
      ssr            0x0        0
      et             0x5        5
      ed             0x80000    524288
      sed            0x0        0
      kep            0xfff00400 -1047552
      ksp            0xfff00402 -1047550
ksp            0xfff00402       -1047550
henk
Respected Member
Posts: 346
Joined: Wed Jan 27, 2016 5:21 pm

Postby henk » Wed Aug 17, 2016 1:39 pm

Thanks;

The good news, the four cores come up as you would hope: 1, 2, and 3 are in the bootrom waiting to boot from link, number 0 tried and failed to boot from QSPI.

So - it looks less like a hardware issue; can you rerun xlreg on this empty system please? That should confirm that the correct link has been opened

Cheers,
Henk
LumiCore
Member++
Posts: 21
Joined: Fri Jul 01, 2016 6:36 am

Postby LumiCore » Tue Aug 23, 2016 11:21 am

Hi Henk,

Sorry for the delayed response:

Code: Select all

(gdb) attach

Program received signal ET_LOAD_STORE, Memory access exception.
0xfff005b8 in ?? ()
(gdb) source xlreg
(gdb) xlreg

Thread 1 (tile[0] core[0]):

Thread 2 (tile[1] core[0]):

Thread 3 (tile[2] core[0]):

Thread 4 (tile[3] core[0]):

Node 0x0000
  Routing ID 0x0000
    PLL reg 0x00803f00 [OD=1+1 F=(63+1)/2 R=0+1]
            ratio 16.000000 [320/384/400 @20/24/25 Mhz]
  Reference Clock Divider 0x0003
  BootMode : 0x0023
  Dirs: 0000000000000000
  Link 0  siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0 2w 199/199 d:0
snd:F rec:F
  Link 1  not enabled
  Link 2  not enabled
  Link 3  not enabled
  Link 4  not enabled
  Link 5  not enabled
  Link 6  not enabled
  Link 7  not enabled
  Link 8  not enabled
  Tile routing ID 0x0000
    PLL clock divider 99
    PLink 0 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
    PLink 1 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
    PLink 2 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
    PLink 3 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
  Tile routing ID 0x0001
    PLL clock divider 99
    PLink 0 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
    PLink 1 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
    PLink 2 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
    PLink 3 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0

Node 0x0001
  Routing ID 0x0000
    PLL reg 0x00803f00 [OD=1+1 F=(63+1)/2 R=0+1]
            ratio 16.000000 [320/384/400 @20/24/25 Mhz]
  Reference Clock Divider 0x0003
  BootMode : 0x0023
  Dirs: 0000000000000000
  Link 0  not enabled
  Link 1  not enabled
  Link 2  not enabled
  Link 3  not enabled
  Link 4  not enabled
  Link 5  not enabled
  Link 6  not enabled
  Link 7  not enabled
  Link 8  not enabled
  Tile routing ID 0x0000
    PLL clock divider 99
    PLink 0 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
    PLink 1 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
    PLink 2 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
    PLink 3 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
  Tile routing ID 0x0001
    PLL clock divider 99
    PLink 0 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
    PLink 1 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
    PLink 2 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
    PLink 3 siu:F diu:F junk:F net:0 srctargetid:0 srctargettype:0
(gdb)
LumiCore
Member++
Posts: 21
Joined: Fri Jul 01, 2016 6:36 am

Postby LumiCore » Mon Sep 12, 2016 4:40 pm

Hi Guys,

I was wondering if anyone would have another suggestion for me or review the provided results to try and find the root cause of this issue.

I'm building a second board now to make sure it is not hardware related.

Thanks in advance!
LumiCore
Member++
Posts: 21
Joined: Fri Jul 01, 2016 6:36 am

Postby LumiCore » Wed Sep 14, 2016 8:58 am

After building another board the result is exactly the same for all tests we did...
I have bought 168 of these XU232 chips , I hope we can get it sorted...Is there any unpublished reference design I can lean on?
colin
Experienced Member
Posts: 74
Joined: Mon Dec 16, 2013 12:14 pm

Postby colin » Wed Sep 14, 2016 1:21 pm

Hi LumiCore,

Would you be willing to share your schematic so we can have a more detailed look? Would be great to get to the bottom of this issue.
LumiCore
Member++
Posts: 21
Joined: Fri Jul 01, 2016 6:36 am

Postby LumiCore » Wed Sep 14, 2016 3:39 pm

Hi Colin,

I found the issue - my bad, should have spotted it.
I checked the VDD core voltage against the design checklist in the beginning of the debug process, obviously with an off-spec multimeter. Turns out VDD core was running at 1.07V. This will let the device boot normally from XTAG, but not flash.

I have now decreased it to 1.01V and measured it more accurately, and instant succes.

Thanks for all the help guys, really much appreciated and also the debug tips provided proved to be very useful.
colin
Experienced Member
Posts: 74
Joined: Mon Dec 16, 2013 12:14 pm

Postby colin » Wed Sep 14, 2016 3:55 pm

That's great news LumiCore, glad to hear you got it sorted.

Colin
User avatar
infiniteimprobability
XCore Legend
Posts: 1124
Joined: Thu May 27, 2010 10:08 am

Postby infiniteimprobability » Wed Sep 14, 2016 4:32 pm

I don't like to be a party pooper but...
VDD core was running at 1.07V. This will let the device boot normally from XTAG, but not flash.

I have now decreased it to 1.01V and measured it more accurately, and instant succes.
That doesn't feel right.. The static timing for the chip is closed at 1.1v for FF and the actual supply voltage will be a shade higher than that due to IR drop. So although out of datasheet spec (1.05V), I would expect it to work solidly at 1.07V, if a touch warmer than normal.

It feels like a timing marginality - the silicon will be faster at the higher core voltage so I'm wondering if bringing the voltage down has brought the flash data read into the valid window.

Have you tried slowing the flash down with an xflash argument to see if that made it more reliable when running at the higher voltage? The argument (extracted from xflash -h) is below. Try 20 to halve the speed.

Code: Select all

  --fast-spi-div arg (=10)   Set the FastQSPI clock divider for second stage
What are you QSPI lines like on the PCB layout? They need to be fairly carefully laid out with SI in mind and should be point to point if possible - especially on the clock line to avoid reflections and false clocking. Damping down the clock line with a small cap (scope probe!?) is worth a try too.

Who is online

Users browsing this forum: No registered users and 3 guests