AnsweredAssumed Answered

BF532 spurious EBIU writes while SPORT transmit enabled

Question asked by yl3 on Jul 17, 2016
Latest reply on Jul 25, 2016 by PrasanthR

I'm using the BF532 to run an audio recorder, with A/D and D/A on the SPORT channels in I2S and SD card over SPI for storage, using FatFS.

 

A few details:

- SPI words are 8-bit; SD data packets are 512-byte

- SPORT words are 24-bit; TFS is ~ 8kHZ

- CCLK is 200 MHz; System peripheral clock is 20 MHz.

- SPI clock is 5MHz.

- In playback, data is read from SD to one of two external 16-bit SRAM buffers; the other is used for SPORT transmit.

 

I've encountered an issue I /can/ seem to get rid of, but can't explain; when the SPORT transmit is enabled simultaneous to SD reads, there's frequent incorrect data written to external memory. Using a test raw audio data file, I can see that the spurious bytes are always duplicates of the next bit;

 

e.g: 0x11 0x22 0x33 gets occassionally written as 0x11 0x33 0x33.

 

The error/duplicate pair sometimes sit at different address offsets, too, so it seems unlikely to be caused by solely a glitch in the BHE/BLE lines. I'm fairly confident that the SPI reads are being performed accurately; I can verify that the CRC16 on each data packet read from my test file is expected. So it does seem to happen in the writing to memory.

 

A variety of code changes make the problem disappear If there's a little extra code or delay in the spi_transfer function, or within the SD_read_packets loop, the problem seems to go away entirely. It also disappears if interrupts are disabled during parts of spi_transfer, so that had me thinking I have some critical code. But it also goes away if I slow the CCLK down to VCO/8 (25MHz) in PLL_DIV -- or if I use a function call to write to SRAM instead of writing directly from the loop (i.e, I introduce a little overhead). So this seems more like a timing issue. But I don't have an explanation for how the problem appeared in the first place, so I'm hesitant to use any of these as "fixes".

 

I'm inclined to think there is something I'm doing incorrectly here, perhaps simply not accounting for a silicon anomaly. But I've run out of ideas for the moment and would appreciate any help! Let me know if there's any other information I can provide. I tried not to be too verbose. Thanks!

Outcomes