• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 81 subscribers
  • Views 305 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28374D: The question of GS RAM

Luke Chen
Expert 4860 points
Part Number: TMS320F28374D

Hi all,

My customer uses F28374D for motor control applications and is facing one strange GS-RAM problem. The product is having field test at end customer site and fail to work, their field engineers dump memory contents for analysis and find that some data of GS-RAM are wrong.

We don’t find out root cause yet, but according to customer’s current report, the GS-RAMs are assigned to CPU1 and their software won’t modify those area, seems that CPU1 write incorrect data to wrong address.

My question is that is it possible any condition DSP internal address/data bus occupied cause this problem? Is it possible noise/spikes on peripherals or core power cause this problem? This is first time I encounter this kind of problem, please advise your idea if any so that we have a hint for debugging.

Thanks for your help,

Luke

  • 0
    TI__Guru** 109165 points

    Hi Luke,

    We don’t find out root cause yet, but according to customer’s current report, the GS-RAMs are assigned to CPU1 and their software won’t modify those area, seems that CPU1 write incorrect data to wrong address.

    Are they able to simulate this issue with CCS connected? If yes then they can use the watch point feature of CCS to halt the CPU when write happens to specific address location. 

    Also are they using DMA in their application? If yes, then that can be other source of the issue. To avoid that, we can ask customer to block the DMA write to GS RAM (configuration of GSxACCPROT register) and see if that helps.

    Regards,

    Vivek Singh

     

  • 0 in reply to Vivek Singh
    TI__Expert 4860 points

    Hi Vivek,

    No, they don't use DMA on CPU1, so DMA access is not the root cause. And, this is the GOLDEN sample at this moment, so they don't recycle this unit for further analysis purpose.

    From chip design point, customer wants to know is there any possibilities(noise/spikes on peripheral or core power) internal address/data bus occupied and cause this issue? they need some hints and help them to debug on correct direction. Any possibilities CPU1 writes incorrect data to wrong memory address you can imagine please?

    Regards,

    Luke

  • 0 in reply to Luke Chen
    TI__Expert 4860 points

    Vivek,

    Any suggestions please? Is it possible any conditions(ex, noise/spike on peripheral or unstable core power) cause internal address/data bus being occupied?

    Regards,

    Luke

  • 0 in reply to Luke Chen
    TI__Guru** 109165 points

    Hi Luke,

    Noise and unstable power supply can cause device to not work as expected and in that case different issues can occur but it is hard to say which issue. Issues like this also can happen. What is the difference between normal run and field test? Have they seeing this issue on all the boards or on some specific boards? If it's just on specific boards then it'll be good to compare the board schematic to find any difference.

    Regards,

    Vivek Singh  

  • 0 in reply to Vivek Singh
    TI__Expert 4860 points

    Vivek,

    It is said that not specific machine faces this problem, the end customer is in another country and the engineers traveled to that country for debugging. After engineer's evaluation, seems that root cause is noise on EMIF buses and cause unexpected behavior of their system.

    According to TRM, the input pins of EMIF bus should be configured with GPIO ASYNC option. Engineers are wondering is it possible to configure input pins to SYNC option and enhance noise immunity capability of EMIF bus just like we suggested to SDFM clock and data lines?

    The clock frequency of EMIF is 40MHz and SYSCLK of F28374D is 200MHz. Please advise your idea, can they configure EMIF input pins to GPIO SYNC option.

    Regards,

    Luke

  • 0 in reply to Luke Chen
    TI__Guru** 109165 points

    Hi Luke,

    So basically we are suspecting EMI issue here ? Do we know which EMIF pins are causing the issue. If just data pin then have we tried enabling the internal pulls on EMIF pins to see if that solves the issue ?

    What EMIF interface they are using, ASRAM or SDRAM ? If SDRAM then SYNC option will not work. For ASYNC it may be ok but customer have to test the timing parameter used and should have good margin on it but f it's EMI issue, enabling SYNC option may not really help.

    Regards,

    Vivek Singh