• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 32 subscribers
  • Views 367 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.

TMS570LS3137 HALCOGEN Vs. iotms570LS3137zwt.h

David Schoen
Prodigy 20 points

Other Parts Discussed in Thread: TMS570LS3137, HALCOGEN

Hello,

I´m using HALCOGEN to create Drivers for the internal devices of the TMS570LS3137.

But we want to change this to use the iotms570LS3137zwt.h Header.

Now the problem is, when I use the HALCOGEN File for controlling the I2C device I get the following assembler output when I want to put the device out of reset:

C-Code: ((i2cBASE_t *)0xFFF7D400U)->MDR |= I2C_RESET_OUT;

Assembler Code:
   
      0x2d67c: 0xe59f01e8      LDR         R0, ??DataTable16       ; I2CMDR
      0x2d680: 0xe5900000     LDR         R0, [R0]
      0x2d684: 0xe3900020     ORRS      R0, R0, #32                   ; 0x20
      0x2d688: 0xe59f11dc      LDR         R1, ??DataTable16       ; I2CMDR
      0x2d68c: 0xe5810000     STR         R0, [R1]
  

So, now when I use the iotms570LS3137zwt.h Header I use the following Command:

C-Code: I2CMDR |= I2C_RESET_OUT;

Assembler Code:


      0x2d690: 0xe59f01d4      LDR         R0, ??DataTable16       ; I2CMDR
      0x2d694: 0xe1d000b0     LDRH       R0, [R0]
      0x2d698: 0xe3900020     ORRS      R0, R0, #32                   ; 0x20
      0x2d69c: 0xe59f11c8       LDR         R1, ??DataTable16       ; I2CMDR
      0x2d6a0: 0xe1c100b0     STRH       R0, [R1]

Now, can you please tell me why the 2 Assembler outputs are different?

When I use HALCOGEN => it works.

When I use the Header => it doesn´t work.

PS: I´m using HALCOGEN Version 3.05.00, Header Revision Nr.  57770

Thanks.

David


  

  • 0
    TI__Prodigy 710 points

    Thank you for using the Hercules forum. One of our engineers will be with you shortly. 

  • 0
    TI__Guru 69070 points

    David,

    I don't have the header that you're referencing (iotms570LS3137zwt.h) handy - actually not sure which package this came from. 

    But looking at the generated code, I see that the 2nd example is using LDRH and STRH instructions to access the I2CMDR register.  These are 16-bit reads and writes (which might make some sense as I belive the I2C peripheral is natively a 16-bit peripheral).   On the other hand, the HalCoGen header has this address declared as a 32-bit register.

    Let me know where to find the iomtms...h file and we can check it or if you want to check it, I suspect it could be an issue of endian.   The address 0x24 which is 32-bit aligned in the header file from HalCoGen is endian independent.  But if you use a 16-bit aligned address, I'm pretty sure it would need to change to 0x26 because the bits of the register appear to be on the lower 16-bits of the word which is offset +2 for a big endian device.  (for a little endian part like RM48 I think it would be still ok as 0x24...)

     

  • 0 in reply to Anthony F. Seely
    Prodigy 20 points

    Hi Anthony,

    Thanks for your reply.

    I´ve attached the header file in this post now (It´s out of the IAR Workbench).

    So, what is the right way to work with a 16Bit register in this machine. Should I use 16Bit or 32Bit values with this Registers?

    1411.iotms570LS3137zwt.h

    Greetings

    David

  • 0 in reply to David Schoen
    TI__Guru 69070 points

    David,

    You can use either.  The problem I believe is that the address is wrong for the big endian TMS570, in this line of code (Line 15344)

    __IO_REG16_BIT(I2CMDR,          0xFFF7D424,__READ_WRITE ,__i2cmdr_bits);

    The TMS570 is big endian (BE-32).   So the lower 16 bits of a 32-bit bus are address +0x2 and the upper are address +0x00.

    Try adding +2 to the addresses in your header that are _IO_REG16_BIT and see if this helps.  They all look wrong to me.

    If these were changed to 32-bit entities, then the addresses would be fine.