configure_clock_rate() fails "non-standard" base frequency

[landon]

With the XK-1, I created some ADC clocked ports using the configure_clock_rate() function

Code: Select all

configure_clock_rate( clk, 100, 130 );   // clock, base frequency (100MHz), divisor in MHz)

got everything working fine on XK-1. Now I'm porting code over to the Sparkfun board (different thread - needed more 1-bit ports). I'm using the SFE.xn file which defines the system rates as:

Code: Select all

    <Node Id="0" Type="XS1-L1A" Oscillator="13MHz" SystemFrequency="399750kHz" ReferenceFrequency="99937500Hz">

The problem I'm having is that though I can compile my code fine, I always get an exception on the configure_clock_rate() call. The error in the console is:

mi_cmd_var_create: unable to create variable object

The code window shows:

Code: Select all

No source available for "configure_clock_rate.coersed..f.7b0.7d.28ui.2cui.2cui.29() " 

The thread stack window shows:

Code: Select all

"Suspended: Signal 'ET_ECALL' received.  Description: Application exception.)"

Their example code doesn't do anything with clocked ports, so there's no example for how to configure the clock rate on the SFE XMOS board.

The configure_clock_rate() takes an integer MHz frequency and since the SFE reference frequency was defined to be:

Code: Select all

ReferenceFrequency="99937500Hz"

I can't give configure_clock_rate a base frequency that it will accept. 99.9375 MHz is not an acceptable parameter for it.

I can't figure out how to configure a clocked port with the SFE board definition SFE.xn without generating a run-time exception.

Any hints for how to deal with the SFE XMOS board in particular related to the limitation that the .xn definition doesn't have a 100MHz base frequency?

The Sparkfun SFE.xn file looks like this:

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>Board</Type>
  <Name>SparkFun XS1-L1-64 Development Board</Name>

  <Declarations>
    <Declaration>core stdcore[1]</Declaration>
  </Declarations>

  <Nodes>
    <Node Id="0" Type="XS1-L1A" Oscillator="13MHz" SystemFrequency="399750kHz" ReferenceFrequency="99937500Hz">
      <Boot>
        <Source Location="SPI:bootFlash"/>
      </Boot>
      <Core Number="0" Reference="stdcore[0]">
        <Port Location="XS1_PORT_1A" Name="PORT_SPI_MISO"/>
        <Port Location="XS1_PORT_1B" Name="PORT_SPI_SS"/>
        <Port Location="XS1_PORT_1C" Name="PORT_SPI_CLK"/>
        <Port Location="XS1_PORT_1D" Name="PORT_SPI_MOSI"/>
        
        <Port Location="XS1_PORT_1E" Name="RED_LED"/>
        <Port Location="XS1_PORT_1F" Name="GREEN_LED"/>

        <Port Location="XS1_PORT_1H" Name="PORT_UART_TX"/>
        <Port Location="XS1_PORT_1I" Name="PORT_UART_RX"/>

      </Core>
    </Node>
  </Nodes>

  <Packages>
    <Package id="0" Type="XS1-L1A-LQ64">
      <Component NodeId="0" InPackage="0"/>
    </Package>
  </Packages>

  <ExternalDevices>
    <Device NodeId="0" Core="0" Class="SPIFlash" Name="bootFlash" Type="AT25DF041A">
      <Attribute Name="PORT_SPI_MISO" Value="PORT_SPI_MISO"/>
      <Attribute Name="PORT_SPI_SS"   Value="PORT_SPI_SS"/>
      <Attribute Name="PORT_SPI_CLK"  Value="PORT_SPI_CLK"/>
      <Attribute Name="PORT_SPI_MOSI" Value="PORT_SPI_MOSI"/>
    </Device>
  </ExternalDevices>

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

Landon

[landon]

One odd discovery - I got around the runtime exception I was getting by changing:

Code: Select all

configure_clock_rate( clk, 100, 138 );

to

Code: Select all

configure_clock_rate_at_least( clk, 100, 138 );

I don't know exactly what rate this 'at least' translates to once the clk is configured or quite how to figure it out. All the supported rates seem to be 100 MHz or divisors of 50/n where n is 1-255.

So, if the actual reference frequency of the sparkfun board is 99937500Hz, and I put in at-least params like this, I don't quite know where that leaves me.

The other odd thing is a documentation error, I think. The "Programming XC on XMOS Devices" shows the prototype for the at least function being:

Code: Select all

void configure_clock_at_least( clock clk, unsigned char divide );

For consistency, I had just tried:

Code: Select all

configure_clock_rate_at_least( clock clk, unsigned a, unsigned b);

The latter is not documented in the programming guide in C.2.1. but it compiled and seems to work so far.

[bearcat]

From my experince, if you don't have a clock frequency that will divide equally to the desired frequency, you will have to use the built in's:

configure_clock_rate_at_least ( clock clk, unsigned a, unsigned b )
configure_clock_rate_at_most ( clock clk, unsigned a, unsigned b )

The correct syntax is shown in the XC Libraries help files included with the XDE install.
Looks like a typo in the XC programming manual.

[N8B]

Any hints for how to deal with the SFE XMOS board in particular related to the limitation that the .xn definition doesn't have a 100MHz base frequency?

Landon

Hi Landon,

Sorry about that. I originally had the SFE.xn file written with:

Code: Select all

<Node Id="0" Type="XS1-L1A" Oscillator="13MHz" SystemFrequency="400MHz" ReferenceFrequency="100MHz">

I was successful in implementing the SFE.xn file on the XS1-L1-64 SFE Dev Board with the System Frequency and Reference Frequency as specified above.

However, as stated on page 8 of the XS1-l1-64 datasheet, if the PLL Ref Clk is between 13MHz and 4.22MHz, the boot frequency MUST be between 130MHz and 399.75MHz. So I followed the datasheet when writing the .xn file. I assume that the only risk in setting the System and Reference Frequencies too high is the PLL can become unstable and cause the system clock and ref clk (the one for timing, not the one for the PLL) to stop ticking. If I'm wrong about this, please, someone more knowledgeable correct me.

So I wanted to go by the book. It looks like that just got me more trouble in the long run.

So I assume there is no harm in tweaking the System and Reference frequency by just a little bit so you don't get any compile time errors. Again, if I'm wrong about this, someone please correct me.

So Landon, try changing the System and Reference frequency. I don't think it will damage the silicone, it will just make the board stop working until you power cycle it IF the PLL becomes unstable.

[landon]

Thanks, Nathan. I will run with the changed settings and see how it goes. I'll report back when I think I have something to report (even if it runs stable.)