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

xRM48L950 and RM48L952 -> EMIF Bugs Again

stomp
Genius 4675 points
Other Parts Discussed in Thread: RM48L952, HALCOGEN

Hi,

**VERY URGENT ISSUE**

We have just had RM48L952 Rev C chips mounted to production boards.  We did our testing using XRM48L950 parts.


With the RM48L952 parts we have lost access to RMIF Chip Select 3.  I.E. Any write to address 0x64000000 or higher does not cause a chip select pulse on nCS3 ball K17 of the ZWT package.

The assembly code for a write looks like:

E3A00319 MOV             R0, #1677721600
E59DC000 LDR             R12, [R13]
E580C000 STR             R12, [R0]


We have enabled N2HET2 PIN09 as a GPIO pin and we can toggle the pin just fine, meaning that the K17 ball is electrically connected.

Our test routines work well on XRM48L950 devices, but not on the RM48L952 (even though we have both devices running at 200MHZ). Note: nCS2 and nCS4 work as expected.

Can anyone confirm if this is an issue with Errata DEVICE #B064 or something else that has changed in silicon that would stop nCS3 from toggling.

**Edit Update:
Please also note that the value presented on the data bus (alternating patterns of 0xAA55 and 0x55AA) write correctly, its just that there is no nCS3.

Thanks

Stomp!

  • 0
    Genius 4675 points

    Dear All,

    Just found the issue.

    Hidden in the bottom of the pinmux code on HalCoGen 3.08.01 is this little line of code:

    /* Bit 31 of register GPREG1 is used to gate off the
EMIF module outputs */
systemREG1->GPREG1 |= 0x80000000U;

    We have never set this bit and on XRM84L950 parts the EMIF interface works OK.  However on RM48L952 parts the EMIF does not work unless the MSB of GPREG1 is set to 1 (which is as per the data sheet).

    So problem solved.

    Thanks

    Stomp!

  • 0 in reply to stomp
    TI__Mastermind 49120 points

    Hi Stomp,

    There was a change made from silicon rev B to silicon rev C that affects eight EMIF signals that are multiplexed with N2HET2 signals. See the below extract from the technical reference manual (SPNU503b), page 223 from the "Control of Special Multiplexed Functions" section.

    • 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.

    -Sunil