• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 81 subscribers
  • Views 360 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28377D: EMIF and SDRAM conflicts

Aaron Spaete
Expert 4527 points
Part Number: TMS320F28377D

Team, 

My customer has the following question: 

I have a question dealing with TMS320F28377D and EMIF/SDRAM access.

Indeed, I want to communicate between DSP and an UART chip using EMIF bus and DMA.

I shall receive from outside a 32bytes frame composed of:

-          A start byte 0xE7,

-          An identifier: value increased at each cycle (ID),

-          28 bytes filled with 0x03,

-          A stop byte 0x7E,

-          2 CRC bytes (MSB + LSB).

-           

Example:

0xE7 0x92 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x7E 0xFD 0xA6

 

The UART chip sends interruption when 16 bytes are received, so after 2 interruptions, I have a full frame.

The interruptions are linked to DMA trigger which automatically takes data from UART chip and puts in a global shared memory.

 

Everything is OK, except when my software service tries to access in read mode to the same global shared memory when DMA/EMIF tries to write new values.

When this happens, I can see unexpected bytes in my frame, see example below with red bytes:

 

0xE7 0x91 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x7E 0xMSB 0xLSB 0xE7 0xE7 0xE7 0xE7 0xE7 0xE7 0xE7 0xE7 0xE7

 

 

To have a better view, I did same exercise changing 28 bytes filled with 0x03 with 28 bytes increasing from 0x02 to 0x1C, example:

 

0xE7 0x39 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1B 0x1C 0x7E 0x00 0xA9

 

When the problems occurs i see this frame:

0xE7 0x38 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1B 0x1C 0x7E 0xF0 0x4F 0xE7 0xE7 0xE7

 

This frame has some repetition of unexpected bytes I do not understand.

The number of unexpected bytes is equal to the DMA BURSTSIZE value which is set during DMA initialization.

 

I am actually trying to understand 25.3.5.10 SDRAM Write Operations in SPRUHM8H technical reference to see if something explains that.

 

Do you have any explanation for this behavior ?

 

Thanks,

Aaron 

 

  • 0
    TI__Guru 62975 points

    Aaron Spaete said:
    I have a question dealing with TMS320F28377D and EMIF/SDRAM access.

    Indeed, I want to communicate between DSP and an UART chip using EMIF bus and DMA.

    I am very lost here.  Can you elaborate on the bridging logic or device that is in place to convert the SDRAM protocol to UART activity?  These are very different interfaces that are not commonly used together.

    Aaron Spaete said:
    Everything is OK, except when my software service tries to access in read mode to the same global shared memory when DMA/EMIF tries to write new values.

    When this happens, I can see unexpected bytes in my frame, see example below with red bytes:

     0xE7 0x91 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x03 0x7E 0xMSB 0xLSB 0xE7 0xE7 0xE7 0xE7 0xE7 0xE7 0xE7 0xE7 0xE7

     To have a better view, I did same exercise changing 28 bytes filled with 0x03 with 28 bytes increasing from 0x02 to 0x1C, example:

     0xE7 0x39 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1B 0x1C 0x7E 0x00 0xA9

     When the problems occurs i see this frame:

    0xE7 0x38 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1B 0x1C 0x7E 0xF0 0x4F 0xE7 0xE7 0xE7

     This frame has some repetition of unexpected bytes I do not understand.

    The problem description is at too high of a system level for me to interpret.  Is there a way to isolate the problem to a specific low-level device function that is not working?

    Aaron Spaete said:
    I am actually trying to understand 25.3.5.10 SDRAM Write Operations in SPRUHM8H technical reference to see if something explains that.

    The SDRAM interface is fairly complex.  I would recommend looking at the JEDEC spec or an SDRAM memory datasheet for more detailed information.  The F2837x TRM is only meant to convey basic EMIF signal relationships.