Part Number: LAUNCHXL-CC2650
Other Parts Discussed in Thread: CC2650
I use the LAUNCHXL-CC2650 launchpad together with the CC320AUBOOST. I use a combination of the i2secho demo program (for the I2S transfer) and the project_zero (for Bluetooth).
I created an infinite transaction list. Each transaction is pointing to one of two audio buffers (A, B) of 64 bytes, each. The successor of each transaction is pointing to the other transaction.
When I start the program, sometimes the I2S starts correctly and stays running without any problem. But in many cases, the I2S starts correctly but stops after a short random time period.
I tried to make sure, the issue doesn't come from any interference of the BLE tasks with the i2secho tasks: I set the I2S int-priority to 1 to ensure the bluetooth stack is not stealing the time needed for the I2S interrupt. I also tried to comment out the BLE Service initialization in the ProjectZero_init() function to disable the BLE. Both measures don't change the situation.
To see what is going wrong, I put pin-togglers into these functions: I2SCC26XX.c: I2S_hwiIntFxn(): D0, D1, D2; i2secho.c: *echoThread(): D3
In the plots shown below, I output pin togglers under these circumstances:
D0: I2S_INT_DMA_OUT occurred
D1: I2S_INT_PTR_ERR occurred
D2: H when entering the I2S int-routine (pin set on first line of the int function), L when exiting the int-routine (pin reset on last line of the int function)
D3: H before I2S_startWrite(i2sHandle) is called, L directly after it was called
D4: bit clock
D5: word clock
D7: test-data sent from the MCU to the codec (0xFF, 0x00, 0xFF, 0x00, ...)
Figure 1:
In Figure 1 you can see, that the I2S is started nicely (D3) and the stream starts as expected (Data D7 is sent). After a random time (not deterministic!), the stream stops. No interrupt occurs for a very long time. When it occurs (much too late), a I2S_INT_PTR_ERR is given (which is correct, then).
Figure 2:
Figure 2 shows the timing at the end of the I2S stream. Clocks and data are OK, but the next interrupt is missing for some unknown reason.
Is there any known hardware issue, either with the evaluation boards (e.g. power supply drops during/after startup/settling of the clocks/I2S), or with the CC2650 that could explain this behavior? Is there any known weakness in the I2secho demo program, that could lead to such behavior (e.g. missing reset/initialization of some registers before starting the I2S stream)?
