0

I'm using an NXP LH79525, ARM7TDMI based processor. There is an EEPROM connected via SPI bus to the SSP port.

The objective is to read the EEPROM into SRAM for faster accessing.

The present working code sends a read command to the EEPROM, the reads the data byte per byte, which takes a long time.

I want to use the DMA to read EEPROM on the SPI bus directly, without intervention from the CPU.

Here is my code snippet: 

// Initialize the DMA for use with SPI bus.
// Source is the EEPROM on the SPI bus.
// Destination is "buffer".

p_dma_stream_2->source_low = 0U;
p_dma_stream_2->source_high = 0U;
const uint32_t dest_addr = (uint32_t) buffer;

p_dma_stream_2->dest_low = (dest_addr & 0xFFFFU);
p_dma_stream_2->dest_high = (dest_addr >> 16U);

p_dma_stream_2->max_count = bytesToRead;

*p_dma_intr_mask = 0U;  // Disable all dma interrupts.
*p_dma_intr_clear = 0xFF;   // Clear the interrupts.

SSP->dmacr = 0x01;  // Enable reading with DMA

p_dma_stream_2->control = 0x06U; // + 0x01 to enable transfer.

// 0x400 - status of stream 2. 1 == stream is active.

uint32_t status = *p_dma_status;
while ((status & 0x400U) != 0U)
{
    OSTimeDelay(10U); // 10 milliseconds
    status = *p_dma_status;
}

I'm reading incorrect values from the EEPROM when using the above example.
The DMA registers are counting correctly. The SSP is already initialized before this code fragment, for reading bytes.

I'm looking for a working code example snippet, but haven't found any on the web.

Thomas Matthews
  • 56,849
  • 17
  • 98
  • 154
  • 1
    While this is a software problem, it would help if you can monitor the data to figure out if the EEPROM is providing valid data which your processor is not collecting, or if the bulk operation is improper and the EEPROM is not giving you the correct data. You could consider something like a logic analyzer (perhaps a simple CYC68013A board with `sigrok`, or if it's not too fast a `bus pirate`), or you can pour over the data sheet and double check your assumptions, or perhaps you can program a clever pattern into the EEPROM and just look at the reads with a scope. – Chris Stratton Mar 20 '14 at 20:46
  • I'm comparing data read using direct SSP access with reading data via DMA. This is how I know that the data is not corrrect. – Thomas Matthews Mar 20 '14 at 20:48
  • Yes, but you don't know if a problem with your faster read operation is causing the EEPROM to emit bad data, or if a problem with your DMA or SPI peripheral setup is causing the DMA engine not to collect & store valid data which the EEPROM is emitting. Another thing you could do would be to substitute a counter for the EEPROM and connect MISO to various counter output bits, which should give you data that changes through the buffer in a predictable pattern, *if* the DMA & SPI setup is proper. – Chris Stratton Mar 20 '14 at 20:50
  • I assume you are flushing CPU caches before you verify the data? – mfro Mar 20 '14 at 20:53

1 Answers1

0

According to this User's Guide table 5-1 it seems as SSPRX is assigned to Stream 0 and supports only half-word source data width (table 5-15).

Your code seems to use Stream 2 and byte adressing.

user3443267
  • 1
  • 2