ARM, gcc, 8bit pristup do 32bit promenne

[Jan Smrz]

Dekuji za odpoved. Ja jsem si s tim pak jeste dlouho hral a nakonec jsem 
zjistil, ze to zpusoboval parametr -mno-unaligned-access, ktery tam 
nedopatrenim zustal pri kopirovani makefile z projektu pouzivajici 
Cortex M0.
Pote uz se to prelozilo spravne, ale stejne mi neni jasne proc, protoze 
se pristupuje na zarovnanou adresu, tak neni duvod na nejake upravy. 
Problemy bych cekal obracene, t.j. pri vynechani na M0, ale ne pri 
pouziti na M3.

btw.  -O0 pouzivam pro debugovani, kdy je snazsi krokovani programu

J.S.



On 23.6.2017 2:14, Jan Waclawek wrote:
>> Pokud ale kompiluji s nastavenim -o0, tak se prelozi takto:
> -o0? snad -O0, nie?
>
> S nicim podobnym som sa este nestretol, mozno preto, lebo -O0 by ma v
> zivote nenapadlo pouzit, mozno s vynimkou nejakeho takehoto testovania;
> nevidim ziadny racionalny dovod ho pouzivat v praxi. Tiez je fakt, ze roky
> pouzivam tu istu verziu gcc 4.volakolko, bytostne nenavidim update niecoho
> osvedceneho, ak na to nevidim nejaky velmi konkretny a padny dovod.
>
> Skuste ako prve vypustit vsetko co by sa mohlo tykat problemov s
> preprocesorom, cestami atd., t.j. prelozte priamo subor s tymto obsahom:
>
> #include <stdint.h>
> typedef struct {
>    volatile uint32_t ACR;
> } FLASH_TypeDef;
> volatile uint32_t a;
> int main(void) {
>    a = ((FLASH_TypeDef *)0x40022000)->ACR;
> }
>
>
> Ake ine prepinace su nastavene? Skuste spustit preklad  s pridanim -v ,
> pozrite si s akymi prepinacmi spusta samotny prekladac, popozerajte sa v
> dokumentacii, co ten-ktory pouzity prepinac vlastne znamena.
>
> wek
>
>
> ----- Original Message ---------------
>
> Subject: ARM, gcc, 8bit pristup do 32bit promenne
>     From: Jan Smrz <jan.smrz na email.cz>
>     Date: Thu, 22 Jun 2017 22:55:27 +0200
>       To: hw-list na list.hw.cz
>
>> Zdravim,
>>
>> prosim o pomoc s problemem. Mam pocit, ze jsem dokonce podobny problem
>> uz videl nekde resit, ale nemohu to najit.
>>
>> Kompiluji kod pro STM32F1, pouzivam arm-none-eabi-gcc 5.4.1, ale zkousel
>> jsem i 6.2 a problem je tam stejny.
>>
>> V kodu mam uint32_t i = FLASH->ACR, t.j. ctu 32bitovy FLASH registr.
>>
>> Pokud kompiluji s optimalizaci 1 a vyse, radka se prelozi nasledovne:
>>
>> 08000340    ldr    r2, [r3, #0]
>>
>> Coz funguje bez problemu.
>>
>>
>> Pokud ale kompiluji s nastavenim -o0, tak se prelozi takto:
>>
>> 08000340    ldrb    r2, [r3, #0]
>>
>> t.j. jen 8-bitovy pristup, coz pak vyvola bus-fault.
>>
>> Neresil nekdo neco podobneho? Pro uplnost pridam i definice registru (z
>> core_cm3.h a stm32f103xe.h):
>>
>>
>> #define     __IO    volatile
>>
>> typedef struct
>> {
>>    __IO uint32_t ACR;
>>    __IO uint32_t KEYR;
>>    __IO uint32_t OPTKEYR;
>>    __IO uint32_t SR;
>>    __IO uint32_t CR;
>>    __IO uint32_t AR;
>>    __IO uint32_t RESERVED;
>>    __IO uint32_t OBR;
>>    __IO uint32_t WRPR;
>> } FLASH_TypeDef;
>>
>> #define PERIPH_BASE           ((uint32_t)0x40000000)
>> #define AHBPERIPH_BASE        (PERIPH_BASE + 0x20000)
>> #define FLASH_R_BASE          (AHBPERIPH_BASE + 0x2000) /*!< Flash
>> registers base address */
>>
>> #define FLASH               ((FLASH_TypeDef *) FLASH_R_BASE)
>>
>>
>> J.S.
>>
>>
>> ---
>> Tato zpráva byla zkontrolována na viry programem Avast Antivirus.
>> https://www.avast.com/antivirus
>>
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list