• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 31 subscribers
  • Views 2902 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.

TM4C1233H6PM Bit Band failed on PD0,PD1,PB6,PB7

Kevin Chen4
Prodigy 105 points
Other Parts Discussed in Thread: TM4C1233H6PM

Hello,

I use Stellaris LaunchPad(LM4F120H5QRFIGA3, datecode: 28A2LVW), so mapping to tiva part no. is TM4C1233H6PM .

I found an new GPIO issue which is not listed on Tiva TM4C12x Silicon errata(http://www.ti.com/lit/er/spmz849/spmz849.pdf) and Old LM4F120H5QR errata.

This issue is Bit-banding failed on GPIO: PD0,PD1,PB6,and PB7 pins, below is the bit-band address:

PB6: 0x420A0018

PB7: 0x420A001C

PD0: 0x420E0000

PD1: 0x420E0004

I did use the same bit-band function to control all GPIO pins, and all pins work fine, except PB6,PB7,PD0,PD1.

Workaround: Use GPIO->DATA register + mask offset Address[9:2] for controlling PB6, PB7, PD0, PD1.

 

So, would you please clarify this issue? or give me some advice?

Thank you very much.

 

Kevin

 

 

 

  • 0
    Guru 26105 points

    Hi,

    Look a little bit on launchpad schematic - resistors R9 and R10 connect these pins  - so you must remove them first before to use them for any purpose (or take care about this).

    Petrei

  • 0 in reply to Petrei
    Prodigy 105 points

    Dear Petrei,

    Thank you very much for your reply.

    I did remove the R9 and R10 resistor, and made this testing.

    If I used GPIOB->DATA and GPIOD->DATA registers to control PB6, PB7, PD0, PD1, the output signal are correct, and individual pin control is correct too.

    Is any other reason that may cause this issue?

     

    Best regards,

    Kevin

  • 0 in reply to Kevin Chen4
    Guru 117855 points

    Believe we past tried similar on our LX4F (not your device) and did not so note.

    Had your tests included both "bit-band" writes & reads?  Did both fail? 

    Were tests conducted w/ports @ both AHB and APB?

    Some description of the, "failure" may be helpful...

  • 0 in reply to cb1_mobile
    Prodigy 105 points

    Thank you for your advice.

    I found when I use Bit-Banding with GPIO DATA register, this method failed.

    Ex: HWREGBITW(GPIO_PORTD_BASE + GPIO_O_DATA, 3) = 0;

     

    But if I use Bit-Banding with GPIO DATA register + Mask Offset address, then this method works.

    Ex: HWREGBITW(GPIO_PORTD_BASE + GPIO_O_DATA + ((1<<3) << 2), 3) = 0;

    I don't know why?

     

  • 0 in reply to Kevin Chen4
    TI__Prodigy 240 points

     

     

     

     GPIO_O_DATA register is virtually mapped to 256 locations in the address space. To facilitate the reading and writing of data to these registers by independent drivers, the data read from and written to the registers are masked by the eight address lines [9:2]. The following operation is wrong.

    HWREGBITW(GPIO_PORTD_BASE + GPIO_O_DATA, 3) = 0;

  • 0 in reply to Triton Zhang
    TI__Intellectual 2615 points

    In other words, Kevin, bit-banding is not necessary as the GPIO data register gives you a means of masking which bits you want to change.

  • 0 in reply to Triton Zhang
    Prodigy 105 points

    Dear Triton,

    Thank you very for your answer.

    Now, I understand.

     

    Kevin

  • 0 in reply to Stellaris Miles
    Prodigy 105 points

    Dear Miles,

    Thank you very much for your answer.

     

    Kevin