XUF232-1024-FB374-C40A Not Booting

Technical questions regarding the XTC tools and programming with XMOS.
Post Reply
radii
Junior Member
Posts: 6
Joined: Thu Aug 12, 2021 12:38 pm

XUF232-1024-FB374-C40A Not Booting

Post by radii »

Hi All

I have a problem with the XUF232 A version not booting. I have developed a digital audio talkback mixer for a high end video production application over the last 6 months, using xrun the code runs which I have used for dev and debug, I have configurable lipsync delays across all tiles using channels, multichannel USB2, and all works perfectly via xrun. I received some sample-stock devices from EPS Global that do not have the full markings and are marked KR which I assume to be Korean, but due to being from EPS I am certain they are genuine. These are the A version so have the IS25LP016D flash devices. I followed the design advisory at the start of the project in order to use the new flash devices and due to uncertainties with the design advisory and tools version I implemented all of the required changes in code, but attempted to flash 3 boards with tools 14.3.3 without the --spi-spec file sent with the xflash command, so figured I had stuffed the devices.

Since completing the code development I made a few minor improvements to the hardware and had 3 new boards made. I was careful to only use 14.4.1 or 15.0.6 (to include support for programming the new internal flash device) and the issue was still the same. Due to the design advisory I had assumed the devices were not flashing, even though from the start I could interrogate the flash devices using --spi-read-id. I then made a flash tool and have written hello world and read back from a data partition, and this works on the previous boards too. This led me to try flashing my code, did a full read back of the flash and compared with the generated binary (using notepad++ which ignores the unprogrammed nulls) and this matches. So the devices are programming.

xrun --dump-state looks healthy if the XMOS was already running when dumpstate invoked, if the XMOS is not running the dumpstate shows halted PC and suggested corrupt stack. I do not understand the detail of what dumpstate is showing and couldn't find this in the manuals :)

My mixer code is fairly complex being based on the MCA, so I made a ground up project with no modules that toggles a pin every 1ms. This works like a dream using xrun but still does not boot. This has been used for all of the dump state and verbose file attachments:

Code: Select all


#include <xs1.h>

#include <xccompat.h>
#include "gpio.h"

unsigned get_tile_id(tileref);

extern tileref tile[];


//on tile[0] : out port p_gpio_ADC_DAC = XS1_PORT_4F;     // Original Core PCB
on tile[0] : out port p_gpio_ADC_DAC = XS1_PORT_4C;     // Revised Core PCB

void timer_xms (int x)
{
    timer t;
    unsigned time;
    t :> time;
    time += (x * 100000);         // 100MHz click is 10ns
    t when timerafter(time) :> int _;
}

int main(void)
    {

    while(1){
    set_gpio_ADC_DAC(P_GPIO_DAC_MUTE_N, 1);      /*********    lcode_debug     *******/
    timer_xms(1);
    set_gpio_ADC_DAC(P_GPIO_DAC_MUTE_N, 0);      /*********    lcode_debug     *******/
    timer_xms(1);
    }

return 0;

}       // main program

Code: Select all


#include "gpio.h"
#include <xs1.h>

void p_gpio_lock()
{
}

void p_gpio_unlock()
{
}

unsigned p_gpio_ADC_DAC_peek()
{
    unsigned portId, x;


    asm("ldw %0, dp[p_gpio_ADC_DAC]":"=r"(portId));
    asm volatile("peek %0, res[%1]":"=r"(x):"r"(portId));

    return x;
}

void p_gpio_ADC_DAC_out(unsigned x)
{
    unsigned portId;

    asm("ldw %0, dp[p_gpio_ADC_DAC]":"=r"(portId));
    asm volatile("out res[%0], %1"::"r"(portId),"r"(x));

}

void set_gpio_ADC_DAC(unsigned bit, unsigned value)
{
    unsigned port_shadow;
    port_shadow = p_gpio_ADC_DAC_peek();         // Read port pin value
    if (value == 0) port_shadow &= ~bit; // If writing a 0, generate mask and AND with current val
    else port_shadow |= bit;             // Else use mask and OR to set bit
    p_gpio_ADC_DAC_out(port_shadow);             // Write back to port. Will make port an output if not already
}

I have tried --pll-no-reset (and without this switch) at every stage of attempted programming with no success.

I took a look at the hardware. I noticed that as soon as the core voltage come up the XUF232 seems to go into reset and stays there (with a 10k PU on a GPIO the port pin sits at about 2.7V in reset due to the internal PD when in reset). I tweaked the power supply timings to closely follow the MCA so the 3V3 comes up at the same time as MCLK, then after 5ms the 1V comes up cleanly and is tightly within spec, then after 30ms the reset comes up, although the XMOS gpio pins seem to stay in a pulled down state from as soon as the 1V comes up - as if the XMOS stays in reset. The MCA board reset has a 100us delay linked to the 1V although I figured the reset line was unlikely to be critically timed to the boot sequence, as the reset is an external signal. I changed the clock to come up mid way between the 1V and the reset (after 15ms) and this had no effect on the booting issue.

I have been through Xcore and followed several threads that outline problems with XUF232 not booting, and they don't seem to be resolved in a satisfactory way. I must be close to being a master of the xn file now :). I used a newly generated xn for the XUF232, added Oscillator = "24MHz" to both the USB node references, OscillatorSrc set to 1 or 3, along with PageSize, SectorSize, NumPages, QE REGISTER and QE_BIT attributes all to the External Devices section. I have tried changing the wires to 2 across all links with no difference. The only warning I get in when flashing in Xtime 14.4.1 is xflash: Warning: F03148 --quad-spi-clock not given, using default 15.62MHz, tools 15.0.6 has no warnings.

Code: Select all


<?xml version="1.0" encoding="UTF-8"?>
<Network xmlns="http://www.xmos.com"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.xmos.com http://www.xmos.com">
  <Type>Device</Type>
  <Name>XUF232-1024-FB374-C40 Device</Name>

  <Declarations>
    <Declaration>tileref tile[4]</Declaration>
    <Declaration>tileref usb_tile[2]</Declaration>
  </Declarations>

  <Packages>
    <Package id="0" Type="XS2-UFnA-1024-FB374">
      <Nodes>
        <Node Id="0" InPackageId="0" Type="XS2-L16A-512" SystemFrequency="500MHz" OscillatorSrc="1" ReferenceFrequency="100MHz">
          <Boot>
            <Source Location="bootFlash"/>
            <Bootee NodeId="2"/>
          </Boot>
          <Tile Number="0" Reference="tile[0]">
            <Port Location="XS1_PORT_1B" Name="PORT_SQI_CS"/>
            <Port Location="XS1_PORT_1C" Name="PORT_SQI_SCLK"/>
            <Port Location="XS1_PORT_4B" Name="PORT_SQI_SIO"/>
          </Tile>
          <Tile Number="1" Reference="tile[1]"/>
        </Node>
        <Node Id="2" InPackageId="2" Type="XS2-L16A-512" SystemFrequency="500MHz" OscillatorSrc="3" ReferenceFrequency="100MHz">
          <Boot>
            <Source Location="LINK" BootMode="4"/>
          </Boot>
          <Tile Number="0" Reference="tile[2]"/>
          <Tile Number="1" Reference="tile[3]"/>
        </Node>
        <Node Id="1" InPackageId="1" Type="periph:XS1-SU" Reference="usb_tile[0]" Oscillator="24MHz">
        </Node>
        <Node Id="3" InPackageId="3" Type="periph:XS1-SU" Reference="usb_tile[1]" Oscillator="24MHz">
        </Node>
      </Nodes>
      <Links>
        <Link Encoding="5wire" Delays="3clk">
          <LinkEndpoint NodeId="0" Link="7"/>
          <LinkEndpoint NodeId="2" Link="0"/>
        </Link>
        <Link Encoding="5wire" Delays="3clk">
          <LinkEndpoint NodeId="0" Link="4"/>
          <LinkEndpoint NodeId="2" Link="3"/>
        </Link>
        <Link Encoding="5wire" Delays="3clk">
          <LinkEndpoint NodeId="0" Link="6"/>
          <LinkEndpoint NodeId="2" Link="1"/>
        </Link>
        <Link Encoding="5wire" Delays="3clk">
          <LinkEndpoint NodeId="0" Link="5"/>
          <LinkEndpoint NodeId="2" Link="2"/>
        </Link>
        <Link Encoding="5wire">
          <LinkEndpoint NodeId="0" Link="8" Delays="52clk,52clk"/>
          <LinkEndpoint NodeId="1" Link="XL0" Delays="1clk,1clk"/>
        </Link>
        <Link Encoding="5wire">
          <LinkEndpoint NodeId="2" Link="8" Delays="52clk,52clk"/>
          <LinkEndpoint NodeId="3" Link="XL0" Delays="1clk,1clk"/>
        </Link>
      </Links>
    </Package>
  </Packages>

  <ExternalDevices>
    <Device NodeId="0" Tile="0" Class="SQIFlash" Name="bootFlash" Type="IS25LP016D" PageSize="256" SectorSize="4096" NumPages="8192">
      <Attribute Name="PORT_SQI_CS" Value="PORT_SQI_CS"/>
      <Attribute Name="PORT_SQI_SCLK" Value="PORT_SQI_SCLK"/>
      <Attribute Name="PORT_SQI_SIO" Value="PORT_SQI_SIO"/>
      <Attribute Name="QE_REGISTER" Value="flash_qe_location_status_reg_0"/>
      <Attribute Name="QE_BIT" Value="flash_qe_bit_6"/>
    </Device>
  </ExternalDevices>

  <JTAGChain>
    <JTAGDevice NodeId="0"/>
    <JTAGDevice NodeId="2"/>
  </JTAGChain>

</Network>


I have tried changing the bootmode under node 2 of the xn and found what seems to be an obvious bug in the xn file, if I changed bootmode from default of 4 to 5 I receive a flash time error message 'spanning-xn-v0-cafe6830: Error: XN11188 Network is not fully connected (no route from node "0" to node "2")', this is the same in tools 14.4.1 and 15.0.6 and happens a few lines into the flash process after xgdb has run, even without the XTAG connected to the XMOS board to be programmed. I have tried boot modes 4,6,7 in conjunction with changing the tile 2 boot mode config pins 4 to 7 which have made no difference to booting, but all flash without warnings or errors.

I have access to the CS and QSPI data lines 0 and 1 and upon power on of the XMOS there is no activity on these lines. There are other devices hanging off these lines (all inputs or PUs) although there is no sign of data to be affected, and I have tried without the other boards connected when trying the pin toggle code. The flash operation runs at default of 15.62MHz and due to the usages of these pins the frequency could benefit from being slowed down a little but the logic levels are there and the code flashes reliably.

I have a few questions with the xn, do the External devices name and type have to match up with anything outside of the xn file? In the MCA board device name is bootFlash (prefixed with SPI: ), whereas the XUF232 xn defaults to bootFlash0. Also is the XUF preconfigured to know it has to boot from SPI (mode0) as again the default xn config just states name as bootFlash0 with no mention of bootmode. If the flash is external to the XMOS device such as on the MCA, the name is SPI:bootflash. Is SPI required if the XMOS is to boot from internal flash. Also flash type in the xn is stated as IS25LP016D, although this doesn't seem to match code references of the flash part, does this matter? I have to say the manuals are really not very good with details and examples of all of this, it only takes 1 detail to stop the device working yet the combinations are many. I have tried all options but without a reference point of a working system it is not possible to know which way these should be set.

Also I saw John Edwards post regarding connecting two explorer boards and he uses XMOSLINK under second note boot source instead of LINK that is stated in the tools manuals. Is there a difference between these?

I have used XMOS devices a few times in the past and these units have gone out to production, dev and flash programming has been seamless. I have certainly learned a lot about XMOS throughout this process, which I had avoided before, although now can I have the answer please. My customer is starting to jump up and down just a little bit and I have a whole brand to develop around XMOS devices, can anyone shine a light on this?

All and any help will be appreciated, thank you.
xflash pin toggle verbose.txt
(6.76 KiB) Downloaded 188 times
xflash pin toggle verbose.txt
(6.76 KiB) Downloaded 188 times
Pin toggle dump state from POR.txt
(6.38 KiB) Downloaded 178 times
Pin toggle dump state from POR.txt
(6.38 KiB) Downloaded 178 times
Pin toggle dump state after xrun.txt
(4.83 KiB) Downloaded 172 times
Pin toggle dump state after xrun.txt
(4.83 KiB) Downloaded 172 times


Precisely
New User
Posts: 3
Joined: Fri Nov 03, 2017 6:39 pm

Post by Precisely »

It sounds like I'm in the same boat. I'm flashing some new boards with XUF216 devices and they won't boot at power up. The program is indeed stored on the flash and I can run it through XTAG using the xrun command, but it won't run when the device powers up or is reset.
These new boards are using the new A version of the chips. I have already programmed a dozen or so devices using the previous version of the chips and everything worked well (no changes to the power supplies or RST_N handling were made between board revisions). I have made the code changes as recommended in the Design Advisory for the new A versions, but that hasn't proven to have any effect on this boot problem.
If I reset the XMOS chip from the command line, or by manually pulling the RST_N pin to ground, the code still doesn't run.
To complicate matters, 2 of the 6 boards are working, but I haven't yet figured out why some work and others don't. I recently moved to the version 15.x XTC tools (on macOS 11), from xTimeComposer version 14.4.1 on macOS 10.15. The 2 boards that are working were programmed with the older tools. One of them was programmed with the newer tools and failed. It started working when I went back and programmed it with the older tools. Whether or why that mattered I do not know, but the other (failing) devices have not responded in the same way.
It would be great to get to the bottom of this. Any help would be appreciated.
User avatar
CousinItt
Respected Member
Posts: 360
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

Have you tried "ISSI_IS25LP016D"? This is the constant defined in the newer Quad SPI headers. I don't know if there's some behind-the-scenes conversion for compatibility with earlier definitions.

Just a thought.
radii
Junior Member
Posts: 6
Joined: Thu Aug 12, 2021 12:38 pm

Post by radii »

Hi CousinItt thanks, I have already tried some options that I pulled from the code but reverted to just IS25LP016D, I noticed with the MCA the xn name doesn't seem to match the names used in code. I have just tried ISSI_IS25LP016D and it seems to make no difference, still doesn't boot.

I saw a post from you back in January in regards to flashing issues after included latest tools changes of PageSize, SectorSize, Numpages https://xcore.com/viewtopic.php?f=26&t= ... ble#p38453. Did you find out what the problem was?
User avatar
CousinItt
Respected Member
Posts: 360
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

Ah, that's embarrassing. I'm sure I fixed it somehow but I can't remember the details. I'll do some digging and let you know.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Try to stabilize each of the assembled boards to behave properly.

Start with a known good reference ip like a led blinky or better yet, the XMOS usb HID mouse project. This project will move the mouse pointer in a square pattern till stopped.

Does this IP work on every assembled board?

If not, review the bill of materials and confirm the soldering process. A common issue was the metal belly under the device was a point of failure. If not soldered properly, the board would not work.

No idea if there are issues with the tool chain but review the hardware as well.
User avatar
Sebastian
Active Member
Posts: 39
Joined: Wed Jul 20, 2016 9:15 am

Post by Sebastian »

Hi every one,

I stepped into the same issue.

So far, we have successfully commissioned about 1000 boards with the "old" non-A types.
Unfortunately, we now also have a "failure rate" of about 20%. What means the processor does not want to boot.

Timing of the power supply and clock fit so far.
Regarding non-booting processors, we haven't had any problems so far.
BGA errors can of course not be ruled out. However, the behavior can be observed with two batches of different PCB-assambler.

Unfortunately xTag locks are locked and I can't access the processors anymore.

My next step would be to commission the next boards without lock and AES until another one does not boot.

Has anyone here by chance already come further? would be happy about any tip

Code: Select all

  <ExternalDevices>
    <Device NodeId="0" Tile="0" Class="SQIFlash" Name="bootFlash0" Type="IS25LP016D" PageSize="256" SectorSize="4096" NumPages="8192">
      <Attribute Name="PORT_SQI_CS" Value="PORT_SQI_CS_0"/>
      <Attribute Name="PORT_SQI_SCLK" Value="PORT_SQI_SCLK_0"/>
      <Attribute Name="PORT_SQI_SIO" Value="PORT_SQI_SIO_0"/>
    </Device>
  </ExternalDevices>

  <JTAGChain>
    <JTAGDevice NodeId="0"/>
    <JTAGDevice NodeId="2"/>
  </JTAGChain>

</Network>
Attachments
tile_2.PNG
tile_2.PNG (7.33 KiB) Viewed 61884 times
tile_2.PNG
tile_2.PNG (7.33 KiB) Viewed 61884 times
tile_0.PNG
tile_0.PNG (8.96 KiB) Viewed 61884 times
tile_0.PNG
tile_0.PNG (8.96 KiB) Viewed 61884 times
mmar
Experienced Member
Posts: 122
Joined: Fri Jul 05, 2013 5:55 pm

Post by mmar »

We have simmilar problem and my result is xburn code is buggy and dont verify otp before lockit = locked is failed OTP. Result is unusable brick.
I create own verify script , that handle burn in more phases write - read - compare - lock or if compare fail write repeat. That help XUF216,208 .
User avatar
Sebastian
Active Member
Posts: 39
Joined: Wed Jul 20, 2016 9:15 am

Post by Sebastian »

You are my hero :)
seems that it now works.

moreover, i can now check whether the flash or otp is wrong. I have already tried a few years ago to lock the otp after burning, but this went wrong.
So I always did it in one step.

Thanks
User avatar
Sebastian
Active Member
Posts: 39
Joined: Wed Jul 20, 2016 9:15 am

Post by Sebastian »

Hello all,

unfortunately, this way was also not purposeful for me.

The only solution that works reliably for us now is:

xflash with version 14.4.1
xburn with version 14.3.3

The xburn version 14.4.1 has unfortunately written again and again nonsense in the OTP. I have deleted this after writing. Only after a successful boot, a master lock was executed.
This happened about every 7th board.

The write speed of JTAG was limited with --jtag-speed 11 to 500kHz.

The change to the above variant with two different versions was verified up to now with approx. 150 boards without failures.
Even if xburn (14.3.3) can't do anything with PageSize, SectorSize and NumPages.


I would also like to use XTC 15.2.1, but unfortunately for xburn the arguments --mac-address and --serial were removed.
Here I have not yet found a suitable solution.


Thanks
Post Reply