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.

TMS570LS1224: SPI Emulation Register (SPIEMU) Bits 31-16

Part Number: TMS570LS1224
Other Parts Discussed in Thread: TMS570LC4357

Tool/software:

With reference to SPNU515C

The field description for SPI Emulation Register (SPIEMU) states the following:

Value             8000h

Description    Reads return 0. Writes have no effect.

1. The value and description contradict one another.

2. The value that I am actually seeing when reading the upper 16 bits is 8037h

What is the expected value when reading bits 31-16 of the SPI Emulation Register (SPIEMU)?

  • Hi Paulo,

    Actually, as those are reserved bits, we don't know exact expected value and significance of those bits.

    I verified in other TRM and found this:

    Here they just mentioned the "reserved" and didn't give any particular value for reading.

    Maybe they should mention similar description in TMS570LS1224 TRM as well. I will note down it as a typo for future revision corrections.

    --

    Thanks & regards,
    Jagadish.

  • Although the other TRM gives 'Reserved' as the Description it still quotes a value of 8000h in both the Figure and the Table, which is almost as misleading.

    If it is the case that the 'value after reset' cannot be predicted then it looks like the correct designation in the Figure ought to be R-X where X=Undefined

    An example of the designation as described above can be found elsewhere in SPNU515C.

    Similarly, if the read value cannot be predicted then the Value in the Table ought to be 'Undefined' and the corresponding Description should state 'Reads are undefined'.

    An example of the designation for Value and Description as described above can be found elsewhere in SPNU515C.

    Please confirm that the designations I have described above are how TI suggest that I should proceed?

  • Hi Paulo,

    Although the other TRM gives 'Reserved' as the Description it still quotes a value of 8000h in both the Figure and the Table, which is almost as misleading.

    I don't have TMS570LS1224 board with me, and i tested this on my TMS570LC4357:

    Here it is as per the TRM value of this device only, the reserved data is 0x8000.

    If it is the case that the 'value after reset' cannot be predicted then it looks like the correct designation in the Figure ought to be R-X where X=Undefined

    Agreed with you!

    Similarly, if the read value cannot be predicted then the Value in the Table ought to be 'Undefined' and the corresponding Description should state 'Reads are undefined'.

    You are correct!

    As i don't have this device, please share your screenshot of this register value then i will note down this observation for correction of TRM.

    --
    Thanks & regards,
    Jagadish.

  • I have now taken a couple of screenshots ...

    It would appear that the 'value after reset' is 8000h as documented, see below:

    The issue is its value later after SPI transactions have taken place, see below:

    As you can see, the read value of bits 31-16 of the SPI Emulation Register is 8037h.

    Given that bits 15-0 of the SPI Emulation Register are a mirror of the SPI Receive Buffer Register (SPIBUF), it is my suspicion that bits 31-0 are actually being mirrored, both registers have the same value 80370001.

    Please confirm how TI suggest that I should proceed:

    • Are bits 31-16 of the SPI Emulation Register a mirror of bits 31-16 of the SPI Receive Buffer Register?

    or:

    • Are 'Reads are undefined' after the SPI has been enabled (via bit 24 of Global Control Register 1)?
  • Hi Paluo,

    Are bits 31-16 of the SPI Emulation Register a mirror of bits 31-16 of the SPI Receive Buffer Register?

    I tested on my other board as well; you are right the higher 16bits also mirror as SPI receive buffer register.

    Maybe it would be better to proceed as SPIEMU is emulating entire SPI receive buffer register.

    --
    Thanks & regards,
    Jagadish.