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>
help debugging runtime exception
-
- Experienced Member
- Posts: 79
- Joined: Thu Nov 17, 2016 11:24 pm
-
- XCore Addict
- Posts: 169
- Joined: Fri Oct 23, 2015 10:23 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
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
-
- Experienced Member
- Posts: 79
- Joined: Thu Nov 17, 2016 11:24 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
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);
}
}
}
-
- XCore Addict
- Posts: 169
- Joined: Fri Oct 23, 2015 10:23 am
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
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
-
- Experienced Member
- Posts: 79
- Joined: Thu Nov 17, 2016 11: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
What needs to be done to understand the issue better?
-Bill
-
- XCore Addict
- Posts: 169
- Joined: Fri Oct 23, 2015 10:23 am
Could you tell me what issues you had with 14.3 and which 14.3 version you were using?
-
- Experienced Member
- Posts: 79
- Joined: Thu Nov 17, 2016 11:24 pm
Sorry, don't know what issue was. It was back in May and I did not document.
14.3.0
cheers,
Bill
14.3.0
cheers,
Bill
-
- XCore Addict
- Posts: 169
- Joined: Fri Oct 23, 2015 10:23 am
There was an issue with 14.3.0 viz timers & predicated ports (as mentioned above).
14.3 is also more aggressive in self checking.
14.3 is also more aggressive in self checking.
-
- XCore Addict
- Posts: 169
- Joined: Fri Oct 23, 2015 10:23 am
p.s. internally we do not use 14.2 - we use the most recent release available.
-
- Experienced Member
- Posts: 79
- Joined: Thu Nov 17, 2016 11:24 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
Thanks,
Bill