help debugging runtime exception

If you have a simple question and just want an answer.
woodsb
Active Member
Posts: 58
Joined: Thu Nov 17, 2016 11:24 pm

help debugging runtime exception

Postby woodsb » Mon Dec 11, 2017 1:07 am

Hello All:

I have a program with the line "delay_milliseconds (1000);".

When the line is commented out the program executes fine. When the line is not commented out I get the following error:

xrun: Program received signal ET_ILLEGAL_RESOURCE, Resource exception.
[Switching to tile[0] core[1]]
0x000440e8 in __lock_recursive_acquire ()

I can run other programs with this line on the same hardware (XMOS mic array), from the same workspace, with the same makefile and .xn files, with no issue.

I have spent several hours trying to figure this out and am out of ideas.

Any help would be greatly appreciated!

sincerely,
Bill

p.s. I have the following includes:
#include <platform.h>
#include <xscope.h>
#include <string.h>
#include <stdio.h>
#include "MB.h"
#include <xs1.h>
#include <limits.h>
#include "mic_array_board_support.h"
#include <timer.h>
robertxmos
XCore Addict
Posts: 129
Joined: Fri Oct 23, 2015 10:23 am

Postby robertxmos » Mon Dec 11, 2017 11:52 am

May I ask what version of tools you are using?
Also, could you upload your par{} statement.

Could it be that you are using 14.3.0 and have the following:
If you have a select statement with more than one case-timeafter-timer and at least one case-predicated-port, you MUST place the timer cases above your port case.
Any timeafter cases placed below the port case will not fire.
If all timerafter cases are below the port case, you will get an undefined vectoring should the timer fire (Dependant upon previous settings... not nice to debug)
This bug is fixed int 14.3.1 & 14.3.2
woodsb
Active Member
Posts: 58
Joined: Thu Nov 17, 2016 11:24 pm

Postby woodsb » Mon Dec 11, 2017 3:58 pm

Hi Robert,

Thx for the response. I am using 14.2.4 for the tools. Full body of main is below. The problematic delay_milliseconds() call is in function ButtonTask(), at the top of the function before any other commands (to avoid acting on any button activity at startup).

cheers,
Bill

Code: Select all

    par {
        on tile[1]: {
            configure_clock_src(mclk, p_mclk_in1);
            start_clock(mclk);
            i2s_master(i_i2s, p_i2s_dout, 1, null, 0, p_bclk, p_lrclk, bclk, mclk);
        }

        on tile[1]:  [[distribute]]i2c_master_single_port(i_i2c, 1, p_i2c, 100, 0, 1, 0);
        on tile[1]:  [[distribute]]i2s_handler(i_i2s, i_i2c[0], bufget);
        on tile[1]:  output_audio_dbuf_handler(bufget, triple_buffer, c_audio, DbufBIF);
 
        on tile[1]:  TF(XtoTFVIF, TFVtoRWIF, FreqData2Buffer, TFVBIF);
        on tile[1] : URW(TFVtoRWIF, WtoFDPIF, LEDIF);

        on tile[0] : LEDTask(LEDIF, leds);
        on tile[0] : ButtonTask(BLIF, p_button);
        on tile[0] : ButtonLogic(BLIF, DbufBIF, TFVBIF);

        on tile[0]: {
            configure_clock_src_divide(pdmclk, p_mclk, 4);
            configure_port_clock_output(p_pdm_clk, pdmclk);
            configure_in_port(p_pdm_mics, pdmclk);
            start_clock(pdmclk);

            par {
                mic_array_pdm_rx(p_pdm_mics, c_4x_pdm_mic_0, c_4x_pdm_mic_1);
                mic_array_decimate_to_pcm_4ch(c_4x_pdm_mic_0, c_ds_output[0], MIC_ARRAY_NO_INTERNAL_CHANS);
                mic_array_decimate_to_pcm_4ch(c_4x_pdm_mic_1, c_ds_output[1], MIC_ARRAY_NO_INTERNAL_CHANS);
                FDP(c_ds_output, c_audio, XtoTFVIF, WtoFDPIF);
            }
        }
    }
robertxmos
XCore Addict
Posts: 129
Joined: Fri Oct 23, 2015 10:23 am

Postby robertxmos » Mon Dec 11, 2017 5:12 pm

Have you tried building with 14.3.2?
The 14.2 branch has been receiving only critical bug fixes for a while.
If you wish to continue using 14.2, there will be a trivial work around for your issue - once the issue is understood!
Most workarounds involve such things as reordering the par statements or flattening them.
robert
woodsb
Active Member
Posts: 58
Joined: Thu Nov 17, 2016 11:24 pm

Postby woodsb » Mon Dec 11, 2017 5:24 pm

I had trouble with the 14.3 release on something else - something that worked with 14.2.4 did not work with 14.3. So, at the moment I'd prefer to stay with 14.2.

What needs to be done to understand the issue better?

-Bill
robertxmos
XCore Addict
Posts: 129
Joined: Fri Oct 23, 2015 10:23 am

Postby robertxmos » Mon Dec 11, 2017 6:21 pm

Could you tell me what issues you had with 14.3 and which 14.3 version you were using?
woodsb
Active Member
Posts: 58
Joined: Thu Nov 17, 2016 11:24 pm

Postby woodsb » Mon Dec 11, 2017 6:26 pm

Sorry, don't know what issue was. It was back in May and I did not document.

14.3.0

cheers,
Bill
robertxmos
XCore Addict
Posts: 129
Joined: Fri Oct 23, 2015 10:23 am

Postby robertxmos » Mon Dec 11, 2017 7:04 pm

There was an issue with 14.3.0 viz timers & predicated ports (as mentioned above).
14.3 is also more aggressive in self checking.
robertxmos
XCore Addict
Posts: 129
Joined: Fri Oct 23, 2015 10:23 am

Postby robertxmos » Mon Dec 11, 2017 7:06 pm

p.s. internally we do not use 14.2 - we use the most recent release available.
woodsb
Active Member
Posts: 58
Joined: Thu Nov 17, 2016 11:24 pm

Postby woodsb » Mon Dec 11, 2017 7:08 pm

I'm a little unsure what to do. I'd like to stay with 14.2.4. Is support with my issue available if I use 14.2.4?

Thanks,
Bill

Who is online

Users browsing this forum: No registered users and 17 guests