Bonjour,
J'utilise un PIC18F25K42 et la DMA qui fonctionne parfaitement en mode FREE MODE.
L'exemple TB3164 est utilisé (A-2 page 9).
Quand je compile en PRO MODE, ça ne fonctionne plus ... je suis obligé de décoché la case " Optimize asm code generated from C."
et ça fonctionne alors ....
Avez vous une idée ?
Je désactive Generated Assembler Code pour que ça fonctionne ...!!!
Merci,
Question bête : tu as payé la licence, la durée d'essai n'est pas dépassée ?
Oui, j'ai une licence pro.
J'ai comparer les deux codes ... je pense a un bug de compilation.
Quand je compile sans optimisation le compilateur place un MOVLB 0x3B avant la mise a 1 de DMA1EN et DMA1DGO !!!
Quand je compile avec l'optimisation le compilateur ne place un MOVLB 0x3B avant la mise a 1 de DMA1EN et DMA1DGO
Donc pour solution en mode optimisation j'ai rajouter avant la mise a 1 des bits avec cette instruction asm ("MOVLB 0x3B") et ça fonctionne !!!
En gros
1°) code qui BUG avec l'optimisation
2°) code qui fonctionne avec l'optimisationCode:asm ("BANKSEL PRLOCK"); asm ("MOVLW 0x55"); asm ("MOVWF PRLOCK"); asm ("MOVLW 0xAA"); asm ("MOVWF PRLOCK"); asm ("BSF PRLOCK, 0"); DMA1CON0bits.DMA1EN = 1; //Enable DMA DMA1CON0bits.DMA1DGO = 1; //Start Transfer
Code:asm ("BANKSEL PRLOCK"); asm ("MOVLW 0x55"); asm ("MOVWF PRLOCK"); asm ("MOVLW 0xAA"); asm ("MOVWF PRLOCK"); asm ("BSF PRLOCK, 0"); asm ("MOVLB 0x3B"); DMA1CON0bits.DMA1EN = 1; //Enable DMA DMA1CON0bits.DMA1DGO = 1; //Start Transfer
Les bug, erreurs et omissions chez Microchip . . .
Je n'ai pas encore eu l'occasion de jouer avec la DMA, elle fonctionne sur interruption? si oui vérifie la déclaration de tes variables. En mode gratuit il n'y a pas d'optimisation, donc même si tu ne déclares pas tes variables appelées dans l'ISR en "volatile" en général ça fonctionne. Par contre avec l'optimisation il se peut que le compiler vire ce qui lui semble "inutile", et donc il y a des choses qui ne s'exécutent plus dans l'ISR.
J'ai bien la version PRO
Dans mon 1° test je n'utilise aucune intérruption
LA DMA copie simplement une zone mémoire dans une autre zone mémoire.
Après recherche je pense que c'est a cause d'utiliser du code assembleur ..
car quand je place ce code au début du programme ( pour verrouiller la priorité DMA)
Alors plus aucun problème de compilation en mode optimisation ou pas.Code:asm ("BANKSEL PRLOCK"); asm ("MOVLW 0x55"); asm ("MOVWF PRLOCK"); asm ("MOVLW 0xAA"); asm ("MOVWF PRLOCK"); asm ("BSF PRLOCK, 0");
Je pense qu'il faut faire attention avec le SFR en optimisation , quand il est manipulé en ASM
Voila... voila ...
Salut,
Je pense que le PB vient du code assembleur inséré dans le C...
Un compilateur C "saute" les lignes assembleur et ne voit pas que ces lignes affectent (potentiellement) des registres qu'il manipule. Extrait du manuel du compilateur XC8 section 5.7 :
Au début de la partie assembleur, le registre de sélection de banque est écrasé (SANS ETRE SAUVEGARDE) avec le No de la banque ou se trouve le registre PRLOCK.Code:MPLAB XC8 is unable to interpret the register usage of in-line assembly code that is encountered in C code. Nor does it associate a variable mapped over an SFR to the actual register itself. Writing to an SFR register using either of these two methods will not flag the register as having changed and can lead to code failure.
(C'est d'ailleurs vrai aussi pour d'autres registres)
Logiquement, la séquence d'assembleur devrait à mon avis sauver la valeur du registre BSR (Bank Select Register) et la restituer à la fin
Si le compilateur était déjà dans la bonne banque il se peut qu'il ne réinitialise pas le registre de sélection de banque.
Normalement, les lignes d'inline assembly devraient toujours être déclarées en volatile. Je ne sais pas si cela est possible avec XC8.
Certains compilateurs refusent d'optimiser tout fichier C qui contient de l'assembleur pour éviter ce genre de PB.
a+
Dernière modification par RISC ; 22/04/2017 à 00h35.
Yes, Merci
