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 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 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.
