• State Accepted Answer
  • Locked Locked
  • Replies 18 replies
  • Subscribers 349 subscribers
  • Views 21233 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex M3 peripheral Bit Banding limit?

H van Rooyen

Is there an intrinsic limit to the width of the bit banding for peripherals for the

Cortex M3?

EFM32 Giant Gecko seems to have a limit of eight bits - bits 8 to 31 does not seem to work.

Is this normal?

Parents
  • 0 in reply to H van Rooyen

    Hello Hendrik,

    It makes no sense, it has to be peculiar to the EFM32 register bit band implementation, as char accesseswork for the bit banding in the ram.

    I don't think so.
    It should be thought differently to access peripheral registers and SRAM.
    Commonly speaking, the peripheral registers are assumed by what access size can be accessible.
    In EFM32 case, the access size for the peripheral registers seems to have to be 32bit width.

    This would not be a restriction but a specification.
    Therefore, the accesses for the bit band alias area of the peripheral registers would be 32bit width. That is, LDR/STR should be used.
    From the discussion till now, I have become a confident that actual register or SRAM area access size (i.e. 8. 16, 32bit) would be the same as the size for the bit band alias area.

    For example,

    case 1:
    #define tim0_icbof0_ie *((volatile unsigned int *)(BITBAND_PERI(TIMER0->IEN,8)))
    tim0_icbof0_ie = 1
    will act as
    1) LDR r0,[r1] // r1 contains TIMER0->IER address
    2) ORR r0,r0,#(1<<8)
    3) STR r0,[r1]
    and case 2:
    #define tim0_icbof0_ie *((volatile unsigned short *)(BITBAND_PERI(TIMER0->IEN,8)))
    tim0_icbof0_ie = 1
    will act as
    1) LDRH r0,[r1] // r1 contains TIMER0->IER address
    2) ORR r0,r0,#(1<<8)
    3) STRH r0,[r1]
    and case 3:
    #define tim0_icbof0_ie *((volatile unsigned char *)(BITBAND_PERI(TIMER0->IEN,8)))
    tim0_icbof0_ie = 1
    will act as
    1) LDRB r0,[r1] // r1 contains TIMER0->IER address
    2) ORR r0,r0,#(1<<8)
    3) STRB r0,[r1]

    I think I have completely understood the phenomenon.
    Also I have no further question.

    Best regards,
    Yasuhiko Koumoto.

Reply
  • 0 in reply to H van Rooyen

    Hello Hendrik,

    It makes no sense, it has to be peculiar to the EFM32 register bit band implementation, as char accesseswork for the bit banding in the ram.

    I don't think so.
    It should be thought differently to access peripheral registers and SRAM.
    Commonly speaking, the peripheral registers are assumed by what access size can be accessible.
    In EFM32 case, the access size for the peripheral registers seems to have to be 32bit width.

    This would not be a restriction but a specification.
    Therefore, the accesses for the bit band alias area of the peripheral registers would be 32bit width. That is, LDR/STR should be used.
    From the discussion till now, I have become a confident that actual register or SRAM area access size (i.e. 8. 16, 32bit) would be the same as the size for the bit band alias area.

    For example,

    case 1:
    #define tim0_icbof0_ie *((volatile unsigned int *)(BITBAND_PERI(TIMER0->IEN,8)))
    tim0_icbof0_ie = 1
    will act as
    1) LDR r0,[r1] // r1 contains TIMER0->IER address
    2) ORR r0,r0,#(1<<8)
    3) STR r0,[r1]
    and case 2:
    #define tim0_icbof0_ie *((volatile unsigned short *)(BITBAND_PERI(TIMER0->IEN,8)))
    tim0_icbof0_ie = 1
    will act as
    1) LDRH r0,[r1] // r1 contains TIMER0->IER address
    2) ORR r0,r0,#(1<<8)
    3) STRH r0,[r1]
    and case 3:
    #define tim0_icbof0_ie *((volatile unsigned char *)(BITBAND_PERI(TIMER0->IEN,8)))
    tim0_icbof0_ie = 1
    will act as
    1) LDRB r0,[r1] // r1 contains TIMER0->IER address
    2) ORR r0,r0,#(1<<8)
    3) STRB r0,[r1]

    I think I have completely understood the phenomenon.
    Also I have no further question.

    Best regards,
    Yasuhiko Koumoto.

Children
No data