[fpc-devel] Problem with bitpacked records and STM32F107 Controller

[Michael Ring]

Hi, while playing arround I found a strange behaviour that seems to have 
to do with the fact that writes to bitpacked records are byte aligned.

Here are the details:

I have create a bitpacked record set for the GPIO Registers of the 
processor. On Port D of the processor I have 16 LED's, one for each bit.

   TGPIO_ODR_bits = bitpacked record
     ODR0  : 0..1;
     ODR1  : 0..1;
     ODR2  : 0..1;
     ODR3  : 0..1;
     ODR4  : 0..1;
     ODR5  : 0..1;
     ODR6  : 0..1;
     ODR7  : 0..1;
     ODR8  : 0..1;
     ODR9  : 0..1;
     ODR10 : 0..1;
     ODR11 : 0..1;
     ODR12 : 0..1;
     ODR13 : 0..1;
     ODR14 : 0..1;
     ODR15 : 0..1;
     RESERVED : 0..65535;
   end;

When I now access the bits via:

     GPIOD_B.ODR.ODR0 := 0;
     GPIOD_B.ODR.ODR0 := 1;

not only the LED for ODR0 lights up, also the one connected to ODR8 !!??!!

When I access the Port without the bitset:
     GPIOD.ODR := 0;
     GPIOD.ODR := 1;
only the LED attached to ODR0 lights up.

Looking at the assembler code I see the following:

.Ll5:
         ldr     r0,.Lj19         //Code for GPIOD_B.ODR.ODR0 := 0;
*ldrb*    r0,[r0]
         bic     r0,r0,#1
         and     r0,r0,#255
         ldr     r1,.Lj19
*strb*    r0,[r1]
.Ll6:
         ldr     r0,.Lj19       //Code for GPIOD_B.ODR.ODR0 := 1;
*ldrb*    r0,[r0]
         orr     r0,r0,#1
         and     r0,r0,#255
         ldr     r1,.Lj19
*strb*    r0,[r1]
.Ll7:
         mov     r0,#0           //Code for GPIOD.ODR := 0;
         ldr     r1,.Lj19
*str*     r0,[r1]
.Ll8:
         mov     r0,#1           //Code for GPIOD.ODR := 1;
         ldr     r1,.Lj19
*str*     r0,[r1]


The strb command seems to be the problem, documentation from STM states:

Each I/O port bit is freely programmable, however the I/O port registers 
have to be accessed as 32-bit words (half-word or byte accesses are not 
allowed).

So, is there some way to make the bitset operations word-aligned? Are 
there any good reasons for not doing so?


Michael

STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx and STM32F107xx 
advanced ARM-based 32-b



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20131211/9fc41583/attachment.html>