WIP and ADL low level interrupts

Legacy Open AT
1

Hi there!

I can’t seem to get WIP (wip_writeOpts and wip_readOpts accross UDP) working correctly when using low level interrupts (TCU service, as well as adl_audioStreamPlay and adl_audioStreamListen).

More specifically, I’m trying to stream real time audio to the Q2687 module I’m using. This entails recording/playing and receiving/transmitting 33 byte packets (GSM 06.10 codec) every 20 ms. I’m currently testing upload and download separately, and not having a lot of success.

It seems that when the underlying WIP library is writing or reading data to or from the bearer channel, the moment a low level interrupt occurs, WIP fails to read any data correctly (or simply stops functioning).

  • Recording: When using the ADL adl_audioStreamListen interface (low level interrupt that triggers every 20 ms), and I try write any data to the UDP channel, wip_writeOpts fail with the error code -39. The only processing that is occurring in my low level interrupt is copying the data passed to the interrupt to another buffer, and raising a ADL event with adl_eventSet (where I then try and transmit data in the task waiting for the event to occur).

Eventually, what I tried was starting / stopping the adl_audioStreamListen interface, and only then transmitting the data. This works, but the audio quality suffers due to missing incoming PCM frames. To try and localize the problem, I also used a 20 ms TCU timer (replacing the adl_audioStreamListen low level interrupt), and I got precisely the same errors.

  • Playing: Similarly, when I use the adl_audioStreamPlay interface (low level interrupt that triggers every 20 ms), the incoming UDP packets causes both the play interface (the low level interrupt stops triggering), as well as the wip_eventHandler_f function waiting for UDP events to “stall” (the embedded module does not reset and no backtraces are generated).

My GPRS bearer gets initialized on the main task (as well as the adl_audioStreamListen / adl_audioStreamPlay interfaces). I am currently trying to move my wip_UDPCreateOpts() call to a task of its own (it’s also currently spawned from the main task), but can’t seem to get it right. wip_UDPCreateOpts returns 0 when trying to spawn from another task. I read on another forum post that I should pass the assigned IP (received during bearer creation) to wip_UDPCreateOpts when spawning from another task, but it doesn’t seem to make a difference.

I also used the variSpeed interface to boost up the clock rate. This delayed the write errors, as well as the receive errors, but they still occurred eventually.

In summary, will spawning the wip_UDPCreateOpts from another task than the main task make a difference when working with low level interrupts?

I would really appreciate any help, thanks in advance.

My current setup:

  • Sierra Q2687 module.
  • Developer studio: 2.1.0.201108081252
  • Open AT software suite: 2.35.0.201103111042
  • Firware package: 7.45.0.201102220653
  • Open AT OS package: 6.35.0.201102280758
  • WIP: 5.41.0.201102280815
  • ARM EABI GCC toolchain
  • eddy.
2

[Update]

I got the wip_UDPCreateOpts() call running on a separate task (I forgot to call wip_netInit), and I can transmit and receive data correctly. The conflicts between the low level interrupts, and WIP, is still there though.

-eddy

3

Hi again,

I still havn’t been able to get WIP and low level IRQ’s working. When I try to write data to WIP while a low level IRQ is continuously triggering, I get the following errors:

‘-39’ is returned from wip_writeOpts(…) when I’m trying to write data (and it doesn’t seem like ‘-39’ is part of the wip_error_t enum).

also, the following text output is written to the active console (UART1):

ERRLOG …/src/ch_udp.c:831: returned res

I’ve attached a demo project that illustrates the problem. The project basically connects to GPRS, creates a UDP socket, and uses a TCU timer to continuously transmit 33 bytes every 20 ms (via events, not from within the IRQ itself). If you don’t get the errors immediately, try and increase the transmission buffer size.

I’m unsure of how to proceed from here. The problem goes away when you choose a higher TCU period (works perfectly at around 80 ms instead of 20 ms), but this defeats the purpose, since I’m trying to emulate the audio record IRQ (as far as I can tell it’s not possible to change the IRQ trigger rate of adl_audioStreamListen(…) - it’s statically defined as 20 ms).

In summary: is the basic idea of what I’m trying to do practically unfeasible to implement on the Q2687 through the use of WIP? (in other words, is it impossible to reliably transmit approx. 33 bytes every 20 ms via a low level interrupt that triggers a transmission event).

Thanks again,

eddy.
UdpIrqTestProject.zip (13.7 KB)