• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 274 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.

DM365 Crash (SW lock-up)

Jamie Maxwell
Expert 1530 points

We are struggling with a DM365 design. During first prototype run, things looked good and we're able to run Linux and run many tests. Only very minor changes were made to the PCB and on the current spin we are seeing issues where the system will run for a short while and then lock up. Only a HW reset will bring the board back.

To date the first run of prototypes do not see this issue, only boards from the second run. The issue appears to be easier to reproduce when we've set the DM365 to record out to USB.

We have followed all DDR2 routing guidelines and this section of the board had no changes from rev1 to rev2. All boards being tested are running the same SW.

We have looked at the power rails and 1V8, 3v3 look clean. 1V35 has a 10Hz noise due to the video recording (processing 10 frame per second), ripple Vp-p=140mV. Tried to increase 1V35 to 1V4 that didn’t help.

Reviewed \TRST and added a pull down to make sure it's set properly.

Looking for some help and suggestions?

Thanks

j

  • 0
    TI__Genius 13045 points

    J,

    It seems from your description that same software on rev 1 and 2 of the boards and only rev 2 shows problem.  Can you detail HW changes between rev 1 and 2 since this seems the most like root cause?  Did you use one of the DM368 development boards as the basis for your design?  If so, which one.

    Also, can you provide more details on what you mean by lock up?  Do you have the terminal logs available to show what was happening when the board stopped working? 

    Regards.

  • 0 in reply to TommyG
    Expert 1530 points

    We think we have identified the issue. 

    We did not use any termination for DDR2 interface on the board but we missed the comment regarding the drive strength. Reading through the datasheet in Table 6-32 it mentions that if no terminations are used then it must be programmed in 60% strength mode.

    To set the strength mode it its described in the DDR2 memory controller UG (http://www.ti.com/lit/ug/sprufi2/sprufi2.pdf)

    Table 24: SDCR (SDRAM Config Reg): Bit 18 (DDRDRIVE0)

    Since this was an issue we saw on various boards and was difficult to repeat we knew it must be an edge case. It makes sense that this could be the root cause. By changing this parameter we think we've solved the problem. Still testing but fingers crossed.

    Thanks

    J