• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 527 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.

RM48L952 EMIF chip select issue

Lukas Kuenzi
Intellectual 400 points
Other Parts Discussed in Thread: RM48L952, HALCOGEN, RM48L950

I have a problem with the RM48L952 (BGA version) on a custom hardware design. I can't access external devices thru the EMIF, because the chip selects are always high and therefore the external device is not selected. It doesn't matter if the SDRAM, or the async interfaces are used. It seems that the chip select signal is not routed/muxed to the pin.

To be sure that the connection on the pcb is correct, I used the CS pin as GPIO. And this worked fine -> connection on pcb is correct.m We took the RM48HDK as reference design. And the SDRAM is the same. We checked the schemes for differences. But we couldn't find any relevant things.

The same code/binary works fine on the RM48HDK with the RM48L950 (BGA version) and I can measure the CS signals with the scope. But on the RM48L952 the CS signals are always high. (Of course I adjusted the clock rate the appropriate version: L950 200MHz, L952 220MHz). We used the HALCoGen 03.06.

I thought there is no difference between the RM48L950 and RM48L952 apart from the speed?!

Did anyone of you have a similar problem or has anyone an idea to fix this?

  • 0
    TI__Guru 59540 points

    Hello Lukas,

    I have forwarded your question to one of experts on the RM48x devices. They should get back with your soon.

  • 0
    TI__Mastermind 49120 points

    Hi Lukas,

    Sorry for the trouble you are having. I think you are working with two different silicon revisions on the two HDKs. There was a change made to eight of the EMIF signals going from silicon rev A to silicon rev B.

    This additional control requires configuration of bit 31 of the system module register GPREG1 at address 0xFFFFFFA0.

    The TRM (SPNU503b) also includes a description on page 152 (pasted below).

    • Control for other EMIF Signals:
    Bit 31 of the system module control register GPREG1 at address 0xFFFFFFA0 is used to gate off the
    EMIF module outputs: EMIF_ADDR[0], EMIF_ADDR[1], EMIF_ADDR[6], EMIF_ADDR[7], EMIF_ADDR[8],
    EMIF_BA[1], EMIF_nCS[0], EMIF_nCS[3]. These 8 signals are multiplexed with NHET2 signals. By
    default, these terminals are tri-stated and pulled down. Any application that requires the EMIF functionality
    must set GPREG1[31]. This allows these 8 EMIF module outputs to be driven on to the assigned balls.

    Can you try setting the GPREG1[31] and see if you can get the EMIF outputs?

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Prodigy 90 points

    Hi Sunil

    Lukas is on holidays so I tested it on the target hardware. It works perfect. I can access the EMIF without any problem. I just have one final question. Can the bit be set using HALcogen? For testing I just set the bit like this:

    systemREG1->GPREG1 |= 0x80000000;

    Regards,

    Heinz

  • 0 in reply to Heinz Hotz
    TI__Mastermind 49120 points

    Hi Heinz,

    An update to HALCoGen will include the setup of the system module register as well. You can use the above statement in one of the "user code" sections so that it does not get overwritten the next time you generate code using HCG.

    Regards, Sunil