Hello,
We have got from XMOS source codes for XVF3800 development board. We are making whole night audio recording tests, with an own slightly updated firmware (e.g. diff mic array size), but in the morning we are not able to receive audio from Mic Array, and i2c communication with XVF3800 is also not working. XVF_host application returns: Resource could not respond to the AEC_MIC_ARRAY_TYPE read command. Check the audio loop is active.
XVF3800 is able to work again, only after hardware reset.
We made same tests with linear mic array mode, square array mode, and also usb mode instead of i2s,i2c mode, always with same result.
When we run the hardware by xrun command over xflash, then in the morning we have got a message:
xrun: Program received signal ET_ECALL, Application exception.
0x000ba714 in do_security_check (frame_count=<optimized out>) at /jenkins/workspace/XMOS_sw_xvf3800_main/modules/fwk_xvf/modules/xshf/lib_xshf/wb/shf.c:20
p.s. When we have set SHF_BYPASS (disables AEC functionality), then hardware is working whole night without any problem.
XVF3800, stops audio transmitting, after some time
-
tilde7
- New User
- Posts: 3
- Joined: Thu Jul 06, 2023 10:32 am
-
upav
Verified - Active Member
- Posts: 37
- Joined: Wed May 22, 2024 3:30 pm
Hey tilde7,
I'm not a 3800 expert, but there are a couple of things that catch my eye.
I think you're seeing 2 things here:
1. Whatever you did to the mic array caused the audio loop to hang.
There could be various reasons for it, but as far as I remember mic array deadlocking used to be a common one.
There was a bug in mic array, where if you don't service it in real time, it would occasionally deadlock.
We just happened to fix this issue on the develop branch of lib_mic_array, so you can give it a quick check.
2. The SHF algorithm requires a licence and a special chip with some security built in.
Looks like the chip you have can only run an evaluation licence of SHF, which runs for 8 hours and needs a reboot after that.
As far as I remember, SQ66 would have an evaluation licence, so I'd expect it to assert if you run it overnight.
Could you tell what you mean by "different mic array size"?
I might not be able to help, but I can think about it.
Hope this helps :)
I'm not a 3800 expert, but there are a couple of things that catch my eye.
I think you're seeing 2 things here:
1. Whatever you did to the mic array caused the audio loop to hang.
There could be various reasons for it, but as far as I remember mic array deadlocking used to be a common one.
There was a bug in mic array, where if you don't service it in real time, it would occasionally deadlock.
We just happened to fix this issue on the develop branch of lib_mic_array, so you can give it a quick check.
2. The SHF algorithm requires a licence and a special chip with some security built in.
Looks like the chip you have can only run an evaluation licence of SHF, which runs for 8 hours and needs a reboot after that.
As far as I remember, SQ66 would have an evaluation licence, so I'd expect it to assert if you run it overnight.
Could you tell what you mean by "different mic array size"?
I might not be able to help, but I can think about it.
Hope this helps :)
Pavel
xmos software engineer
xmos software engineer
-
tilde7
- New User
- Posts: 3
- Joined: Thu Jul 06, 2023 10:32 am
"Could you tell what you mean by "different mic array size"?"
We have only changed the distances between mics in code for a test, because we are planning to use another mic array dimensions.
We have only changed the distances between mics in code for a test, because we are planning to use another mic array dimensions.
