partout function issue?

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
Lele
Active Member
Posts: 52
Joined: Mon Oct 31, 2011 4:08 pm

partout function issue?

Post by Lele »

Hi,
I have a runtime exception using a variable as second parameter of partout function. May be a minor bug. Here is my code:

Code: Select all

#include <platform.h>
#include <xs1.h>
#include <xclib.h>

out buffered port:8 Clk = XS1_PORT_1M; // a buffered 1 bit port
clock ClkBlk1 = XS1_CLKBLK_1; // the clock for the buffered port

int main()
{
  unsigned int NumClk;

  // configure port and clock block
  configure_clock_ref(ClkBlk1, 64);
  configure_out_port(Clk, ClkBlk1, 0);
  start_clock(ClkBlk1);

  for(NumClk = 10; NumClk >= 4; NumClk -= 4)
      Clk <: 0x55; // load 4 clocks

  // load remaining clock
#if 1
  if(NumClk)
    partout(Clk, 2*NumClk, 0x55); // that's strange!! can't use a variable as second parameter
#else
  if(1 == NumClk)  // need to do in this way
    partout(Clk, 2, 0x55);
  else if(2 == NumClk)
    partout(Clk, 4, 0x55);
  else if(3 == NumClk)
    partout(Clk, 6, 0x55);
# endif
  sync(Clk); // wait clocks flushed
  return 0;
}
( using XDE 11.11.0beta1, debug or release


richard
Respected Member
Posts: 318
Joined: Tue Dec 15, 2009 12:46 am

Post by richard »

On the first loop iteration NumClk is 10 and so 2*NumClk is 20. You can't do a partial output greater than the transfer width of the port (in this case 8) and so you get a trap. You either need to increase the transfer width of the port, or decrease the widths of the partial outputs.
User avatar
paul
XCore Addict
Posts: 169
Joined: Fri Jan 08, 2010 12:13 am

Post by paul »

I have run this through the beta tools and the simulator and get the following trace -

Code: Select all

stdcore[0]@0- -A-.----000100f4 (main                + 48) : ldw     r1(0x2), sp[0x1] L[0x1fef4] @2990
stdcore[0]@0- -A-.----000100f6 (main                + 4a) : ldc     r0(0x2), 0x2 @2994
stdcore[0]@0- -A-.----000100f8 (main                + 4c) : mul     r0(0x4), r0(0x2), r1(0x2) @2998
stdcore[0]@0- -A-.----000100fc (main                + 50) : ldw     r1(0x10c00), dp[0x3] L[0x10340] @3002
stdcore[0]@0-P-A-.----00010100 (main                + 54) : setpsc  res[r1(0x10c00)], r0(0x4) @3010
stdcore[0]@0- -A-.----00010100 (main                + 54) : setpsc  res[r1(0x10c00)], r0(0x4) @7030
stdcore[0]@0- -A-.----00010102 (main                + 56) : ldc     r0(0x55), 0x55 @7034
stdcore[0]@0-*-A-.----00010106 (main                + 5a) : outpw   res[r1(0x10c00)], r0(0x55), 0x20 @7042
stdcore[0]@0 *00010106 : TRAP ET: 4, SPC: 00010106, SSR: 0, ED: 00010c00 (ILLEGAL_RESOURCE: Outpw on port in no buffers mode or width > transfer width)
stdcore[0]@0- -A-.--k-00010080 (_TrapHandler        +  0) : bu      0x48 @7046
stdcore[0]@0- -A-.--k-00010114 (_DoException        +  0) : clre     @7050
This seems to be a tools bug - the compiler correctly targets the SETPSC instruction to set the transfer width (in this case 4 - as you exit the loop with NumClk=2). However the tools then try and use OUTPW with a transfer width of 32, which causes an exception - it should be doing a SETPSC and an OUT instruction.

I would recommend putting a ticket in that will get pushed to an internal tools bug - there doesn't seem to be a nice work around apart from what you are doing. That isn't an ideal solution in a time critical situation though - you might need to resort to inline ASM.

Hope that helps and thanks for taking the time to test the beta tools (though this problem is in the previous tools as well)!
Paul

On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
User avatar
Lele
Active Member
Posts: 52
Joined: Mon Oct 31, 2011 4:08 pm

Post by Lele »

Thanks for fast replay and analysis.
I've submitted a tiket.