channel swapping even when using mic input?

[Arjen]

Hi VLSI,

We have a product that uses the VS1063a to encode audio from a microphone and pass it on to a MCU which stores the compressed audio together with other sensor data to a SDcard. We let the system do a self-check on the audio chain by running in PCM mode and let the MCU check for a certain audio level to make sure the microphone and pre-amp work correctly. After a successful self-check we switch to encoding mode to actually start storing audio.

Every now and then (really not very often, we haven't at all been able to reproduce this in the lab) we end up with no audio (just tiny bit of noise) when it did pass the self-check and as we ran it again (full power cycle of the system) all works fine.

We did not load the firmware patch before and I feel it might have something to do with the ADmixer-channel-swapping bugs even though we run it in mono mode and using the mic input. Does that make sense or is there no way this bug is related? (looking for some confidence here since we cannot reproduce this problem in the lab)

Also we noticed our battery life is reduced by about 10% after we started loading the patch. Could it be that the VS1063a is consuming a few milli amps more with the patch loaded?

Thanks a lot for any help!
Arjen

[pasi]

It is the same channel swap issue. The Analog to Digital Converter is always stereo whether you use just one channel or not.

You can avoid the channel swap by using the patches package or by giving a hardware reset before starting (or after ending) encoding. For example the vs1063 standalone recorder performs a watchdog reset after creating the file so that it is ready for the next encoding. This may not be very practical in your use case though.

With the patch the encoding mode (always) uses the clock adder field from SCI_CLOCKF. This is done to allow higher clocks for mp3 and ogg vorbis encoding when you want to use the "exact rate" feature. If you have a non-zero value in CLOCKA, it could explain slightly higher power consumption. I don't think any of the patches themselves would measurably increase the power consumption (unless you use some new features).

[Aidan]

For the workarounds to this channel swap bug, is it possible to do a watchdog reset command over the SCI? Or is this only possible if running code directly on the chip?

I have checked the SC_ADD field under SCI_CLOCKF and I indeed set it to 0. I guess next step is to see if anything else in the patch could unexpectedly enable something.

[pasi]

If you can't control xRESET, you should be able to do Watchdog reset through SCI.
1. write 0 to CLOCKF to drop to 1.0x
2. write 0xC020 to WRAMADDR, 0x0002 to WRAM, then 0xC021 to WRAMADDR and 0x4ea9 to WRAM
3. wait a bit.
You should see DREQ going down and then up. Let me know if you don't get it to work and I'll try it here.

The vs1063a standalone recorder doesn't want to waste code space for the channel swap workaround, so it uses watchdog when it finishes recording.

Code: Select all

        /* Use wdog-resert to prevent DECIM-restart-bug (channel swap)
           in our next recording start.
           Watchdog reset will also clear the recording indicator.
        */
        clockX = 2;
        SetRate(10); /* Need 1x clock for watchdog to work properly! */
        USEX(WDOG_CONFIG) = 2;
        USEX(WDOG_RESET) = WDOG_RESET_VAL;
        while (1)
          ;